社群貢獻的外掛程式在 下，一般以 fizz-plugin-* 或 fizz-*-plugin 命名，下面介紹一些常用的外掛程式。
用例：若閘道器**的後端介面響應 json 資料 ，然後需要對手機號作掩碼處理，則可為介面的路由配置外掛程式：
配置後，請求介面時帶 sourcetype 請求頭，其值為 ch1，收到響應為 。
用例：為路由配置外掛程式：
如此配置後，路由的後端介面收到的請求頭中，將會有 hdr2=val2。
用法同請求頭外掛程式。
用例：為路由配置外掛程式：
配置後，請求介面時帶 x-forwarded-for 請求頭，其值為 2.4.6.9，收到響應為 。
用例：設請求為 外掛程式是以整個 uri 為快取 key，使用本地快取：
配置後，首次請求 時，請求會到後端服務，後續請求將命中快取
官網：github:
碼雲：入門教程：/fizz/guide/gettingstarted/
高階教程：/fizz/guide/advanced/
微服務API閘道器
微服務api閘道器 api閘道器是乙個伺服器，是系統的唯一入口。從物件導向設計的角度看，它與外觀模式類似。api閘道器封裝了系統內部架構，為每個客戶端提供乙個定製的api。它可能還具有其它職責，如身份驗證 監控 負載均衡 快取 請求分片與管理 靜態響應處理。api閘道器方式的核心要點是，所有的客戶端...
企業級API設計
最近對service的api設計，在team內有些討論，主要集中在api是足夠抽象 通用好呢，還是具體 易用好？其實這個是要折衷的，通用的好處是以後更改api的可能性小，但壞處是想要通用，裡面的字段就不能定義太死，不定義死，極端的例子是全部用name value pair，最通用，但client面對...
微服務 API閘道器 限流
我們在api閘道器中已經介紹了，限流是保護閘道器的手段之一，和身份認證以及鑑權一起組成安全防禦大閘。其目的是對併發請求進行限速或限制乙個時間視窗內請求的數量，一旦達到閾值就排隊等待或降級甚至拒絕服務。根據上面列出的原因，我們自然知道限流該怎麼限制法，但是具體要怎麼實現呢？也就是該怎麼設計演算法來實現...