Apache APISIX 助力有贊雲原生 PaaS 平臺，實現全面微服務治理

有贊是一家主要從事零售科技 SaaS 服務的企業，幫助商家進行網上開店、社交營銷、提高留存復購，拓展全渠道新零售業務。在今年，有贊技術中臺開始設計實現新的雲原生 PaaS 平臺，希望通過一套通用模型來進行各種應用的發佈管理和微服務相關治理。而 Apache APISIX 在其中起到了非常關鍵的作用。

爲什麼需要流量網關

有贊 OPS 平臺

在傳統架構中是沒有網關的，那麼通用功能該如何複用？這裏的通用功能指業務無關的一些特性，比

有贊 OPS 平臺是前期基於 FLASK 的單體應用，主要以支持業務爲主。後來逐漸上線了很多業務，部署了很多業務端代碼，進入容器化階段。網關在當時只是內部 FLASK 應用的一部分功能，且沒有一個明確的網關概念，僅作爲業務應用的流量轉發功能使用。下圖展示的就是當時的網關 1.0 業務結構。

圖片

由於前期整個體系主要着重於業務方向，所以沒有產生太多的動力去進行改造。從 2018 年開始，通過內部交流我們發現，如果沒有一個很好的網關層治理，對後續產品功能的實現和業務接入度上會帶來越來越明顯的瓶頸。

沒有網關層治理出現的問題

** 問題一：性能方面**

1. 每次新增後端服務，都需要進行編碼變更

2. 流量轉發的代碼用 Python 簡單實現，未按 “網關” 要求進行設計

3. Flask 框架的性能限制，單機 QPS 範圍侷限在 120-150

4. 重複造輪子：不同的業務需求都生產一套對應入口

5. 管理麻煩，運維複雜

基於這個問題，我們的行動方向是：專業的工作交給專業的系統去做。

** 問題二：內部業務方面**

圖片

1. 需要管理的內部服務數量非常多（上百）

2. 部分服務未對接 CAS 實現鑑權

3. 新的服務對接 CAS 存在對接成本，重複開發耗時耗力

4. 所有服務直接配置在接入層，沒有內部服務的規範及最佳實踐

帶着以上這兩方面問題，我們就開始對網關類產品進行了相關的調研。

爲什麼選擇了 Apache APISIX

圖片

考慮到產品成熟度和可拓展性，最終我們在 Kong 和 Apache APISIX 中進行對比選擇。

圖片

從上圖對比中可以發現，兩者在很多方面基本不相上下，所以存儲端成爲我們重點考慮的一點。因爲 etcd 在我們公司內部的運維體系上已經比較成熟，所以 Apache APISIX 相較 Kong 則略勝一籌。

同時考慮到在開源項目層面，Apache APISIX 的國內交流與跟進處理速度上都非常優秀，項目的插件體系比較豐富全面，對各個階段的使用類型都比較契合。

所以在 2020 年調研之後，最終選擇了 Apache APISIX 作爲有贊即將推出雲原生 PaaS 平臺的流量網關。

使用 Apache APISIX 後的產品新貌

當我們開始接入 Apache APISIX 後，前文提到的兩方面問題逐一得到了解決。

效果一：優化了架構性能

Apache APISIX 作爲入口網關部署在內部服務區域邊緣，前端的所有請求都會經過它。同時我們通過 Apache APISIX 的插件功能實現了與公司內部 CAS 單點登錄系統的對接，之前負責流量轉發的賬號變爲純業務系統。同時在前端我們提供了一個負責鑑權的 SDK 與 Apache APISIX 鑑權接口進行對接，達成一套完整又自動化的流程體系。

圖片

於是問題得到了解決：

1. 每次增加新的後端服務，只需調用 Apache APISIX 接口，將新的服務配置寫入

2. 流量轉發通過 Apache APISIX 完成，在網關該做的事情上，它完成得十分優秀

3. 網關不再是架構中的性能瓶頸

4. 對不同的業務需求，可以統一使用同一個網關來實現；業務細節有差異，可以通過插件實現

** 效果二：內部服務接入標準化**

接入 Apache APISIX 後，公司新的內部服務接入時將自帶鑑權功能，接入成本極低，業務方可以直接開始開發業務代碼。同時在新服務接入時，按內部服務的規範進行相關路由配置，後端服務可以統一拿到鑑權後的用戶身份，省時省力。

具體關於內部服務的一些調整細節這裏簡單介紹一下。

** 鑑權插件 OPS-JWT-Auth**

鑑權插件是基於 JWT-Auth 協議去開發的，用戶訪問前端時，前端會先去調用 SDK，去前端本地獲取可用的 JWT-Token。然後通過下圖的路徑獲得用戶有效信息，放在前端的某個存儲裏，完成登錄鑑權。

圖片

** 部署配置升級**

在部署層面，我們從簡單版本經歷三次迭代後實現了目前的多集羣配置部署。

• 版本一：雙機房 4 個獨立節點，管理程序分別寫入每個節點的 etcd

• 版本二: 雙機房 4 個獨立節點，主機房三節點 etcd 集羣

• 版本三: 三機房 6 個獨立節點，三機房 etcd 集羣

目前我們還是計算與存儲混合部署在一起，後續我們會去部署一個真正高可用的 etcd 集羣，這樣在管控平面 Apache APISIX 運行時就可以分離出來，以無狀態模式部署。

** 新增鑑權插件 PAT-Auth**

在今年我們又新增了 Person Access Token（PAT）的鑑權插件，這個功能類似於在 GitHub 上去調用 Open API 一樣，會生成一個個人 Token，可以以個人身份去調用 Open API。

因爲我們自己的運維平臺也有一些這樣的需求，比如本地的一些開發插件需要以個人身份去訪問雲平臺上的接口時，這種情況下個人 Token 方式就比較方便，允許開發自己給自己授權。

目前 Apache APISIX 2.2 版本後已支持多個 Auth 插件使用，現在可以支持一個 Consumer 運行多個 Auth 插件的場景實現。

更多玩法待開發

** 升級運維自動化**

在使用 Apache APISIX 的過程中，我們也經歷了幾次版本變動。但每次升級，都或多或少出現因爲兼容性而導致改造開發，完成後進行線上變更，運維效率效率較低。所以後續我們會嘗試在存儲面部署三機房 etcd 集羣的同時，將 Apache APISIX 運行面容器化實現自動發佈。

traffic split 插件使用

traffic split 是 Apache APISIX 在最近幾個版本中引入的插件，主要功能是進行流量分離。有了這個插件後，我們可以根據一些流量頭上的特徵，利用它去自動完成相關操作。

圖片

如上圖在路由配置上引入 traffic split 插件，如果當有 Region=Region1 的情況，便將其路由到 Upstream1。通過這樣的規則配置，完成流量管控的操作。

東西向流量管理

我們的使用場景中更多是涉及到在內網多個服務之間去做服務，調用鑑權時可以依靠 Apache APISIX 做流量管理。服務 A、服務 B 都可以通過它去調用服務 C，中間還可以加入鑑權的插件，設定其調用對象範圍、環境範圍或者速率和熔斷限流等，做出類似這樣的流量管控。

圖片

內部權限系統對接

之後我們也打算將公司的權限系統與 Apache APISIX 進行對接，鑑權通過後，判定用戶是否有權限去訪問後端的某個資源，權限的管理員只需在管控平面上做統一配置即可。

圖片

這樣帶來的一個好處就是後端的所有服務不需要各自去實現權限管控，因爲當下所有流量都是經過網關層處理。

Go Plugin 開發

目前 Apache APISIX 在計算語言層面已支持多計算語言，比如 Java、Go 以及 Python。剛好我們最近實現的雲原生 PaaS 平臺，也開始把技術棧從 Python 往 Go 上轉移。

希望後續在使用 Apache APISIX 的過程中，可以用 Go 去更新一些我們已經實現了的插件，期待在後續的迭代中給有贊產品帶來更多的好處。

**技術瑣話 **

以分佈式設計、架構、體系思想爲基礎，兼論研發相關的點點滴滴，不限於代碼、質量體系和研發管理。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/QT1alX7vF6ZhuHHIK1ZnOg