在 360基礎運維平臺項目中的實踐
API 網關選型
2019 年 10 月，我們團隊計劃改造 360 基礎運維平臺的網關層，當時我們主要調研了社區幾個比較活躍的網關，如 Kong，Orange，Apache APISIX，最終選擇了 Apache APISIX 當時主要是考慮到 Apache APISIX 的存儲選型 etcd 比較符合我們的使用場景。
線上運行情況
目前我們添加到網關的 API 數量接近 900 個，日均 PV 1000 萬左右，從監控系統來看，網關以及我們各個微服務均運行良好。
- 日均 PV
- 網關 POD 監控
- 微服務負載監控圖
基礎運維平臺架構圖
下圖是我們運維平臺項目最終的架構圖，網關服務我們部署在公司的容器云上，etcd 服務我們是在 3 臺虛機上部署了一套集群。
容器化開發和部署
接下來我具體介紹一下我們是如何使用 Apache APISIX 搭建網關服務的，首先先給大家看下我們網關項目的代碼結構
之前我給王院生(Apache APISIX PMC 之一 )看我們的項目代碼結構時，他驚訝的問我，說怎么沒有看到 Apache APISIX 的 core 代碼。
實際上這是我們在使用容器安裝 Apache APISIX 時探索出來的一條道路。它給我們帶來最大的好處是，我們業務的代碼和 Apache APISIX 的核心代碼完全分開，方便 Apache APISIX 升級，也方便我們的業務代碼迭代。
插件化開發
1、項目插件介紹
正如在上面代碼結構圖中所看到的，我們項目的 apisix 目錄里面有兩個目錄，libs 和 plugins，libs 里面我們放一些常用的類庫，plugins 里面存放我們自定義的業務插件，我們所有的業務都采用插件機制來開發。 下圖是我們項目中目前使用到的插件。
稍微解釋一下，我們項目的入口域名有兩個，一個是提供給 openApi 訪問的，認證插件使用的是 Basic Auth，一個是提供給 web 瀏覽器訪問的，認證插件使用的是 web auth(cookie 認證)。
對應 OpenResty 的請求處理流程，我們的插件主要集中在 access 和 log 階段
| 插件 | 階段 | 描述 |
|---|---|---|
| ip-restriction | access_by_lua | ip 限流，使用 apisix 原生插件 |
| basic-auth | access_by_lua | 對 openApi 請求用戶鑒權，自研插件 |
| web-auth | access_by_lua | 對 webApi 請求用戶鑒權，自研插件 |
| limit-rate | access_by_lua | 對請求實現用戶級別和用戶+請求參數級別的限流，自研插件 |
| proxy-rewrite | access_by_lua,balancer_by_lua | 對請求進行轉發，設置接口級別的超時時間，自研插件 |
| log | log_by_lua | 將請求日志記錄到 kafka，再通過 logstash 讀到 es 中，自研插件 |
| alarm | log_by_lua | 根據響應的 statusCode 來報警，自研插件 |
2、Etcd 緩存對象
etcd 緩存對象的原理是利用 etcd 的 watch 功能，將數據從 etcd 緩存到內存對象中，業務使用的時候直接從內存中讀取，避免網絡 io 消耗，etcd 的 watch 功能又保障了數據的實時性，Apache APISIX 的這一特性，簡直是讓人拍案叫絕。
上線后遇到的問題
crontab 清理日結
由于我們網關部署在容器，運行一段時間之后，日志文件超過了默認的配額 50G，后來我們在鏡像里面默認安裝了 cron 和 logrotate，然后在容器 entrypoint 里面開啟了 cron 用來解決這個問題。
感謝
最后特別感謝一下 Apache APISIX 的貢獻者們，貼出 Apache APISIX 官網[2] 和 Apache APISIX Github 地址[3]
References
[1] etcd 官方文檔: https://doczhcn.gitbook.io/etcd/index
[2] Apache APISIX 官網: https://apisix.apache.org/
[3] Apache APISIX Github 地址: https://github.com/apache/apisix
以上就是本次分享的內容~
如果有什么建議，也可以在我們評論區留言，供大家參考學習。
