項目背景

2019 年底，因為公司在業(yè)務(wù)研發(fā)的過程中，遇到了一些業(yè)務(wù)痛點，比如：公司的開發(fā)技術(shù)棧是 Java 相關(guān)的，而運維工程師擅長的則是 Shell 和 Python 腳本，無法直接對接；公司本身正處于快速增長期，開發(fā)工程師人力不足，無法支援日常的運維工作及運維平臺的開發(fā)；在現(xiàn)有的運維平臺中，使用了多種開源工具，而且沒有整合，較難管理。因此我發(fā)起了自動化運維平臺的項目，希望通過該運維平臺實現(xiàn)快速上手的開發(fā)模型，可以實現(xiàn)運維工程師自己開發(fā)業(yè)務(wù)，并進行快速的迭代服務(wù)。

基于 Spring Boot + MyBatis Plus + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

為什么選擇 Apache APISIX

在進行網(wǎng)關(guān)選型時，我們進行了實際的測試。相對于其他網(wǎng)關(guān)，APISIX 基本上可以達到 NGINX 90% 的功能，并且支持了多種負載均衡策略以及支持多語言插件的機制，同時支持了軟 WAF，可以覆蓋我們95% 的安全業(yè)務(wù)場景。作為云原生 API 網(wǎng)關(guān)，APISIX 也提供了強大的日志功能，支持自定義日志格式，因此可以直接讓 access log 對接 ELK。由于 APISIX 也支持自定義插件的開發(fā)，可以根據(jù)我們的需求靈活擴展。得益于 APISIX 的基礎(chǔ)功能和強大的插件體系，可以有效降低開發(fā)成本。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

自動化運維平臺架構(gòu)

自動化運維平臺整體架構(gòu)圖如下：

存儲層：核心是 CMDB，主要功能是記錄和管理組織業(yè)務(wù)和 IT 資源的屬性，以及其它們之間的關(guān)系。不但負責所有業(yè)務(wù)變更的起始狀態(tài)查詢，而且所有的業(yè)務(wù)資源的變更都要反饋記錄在其中，實現(xiàn)業(yè)務(wù)標準規(guī)范的管控。存儲層也包含一些權(quán)限管理的數(shù)據(jù)、業(yè)務(wù)工單的流轉(zhuǎn)數(shù)據(jù)以及監(jiān)控告警的時序數(shù)據(jù)；

公共基礎(chǔ)服務(wù)層：提供原子業(yè)務(wù)的 API，也可以認為是基礎(chǔ)中臺，復(fù)用了大量的開源工具；

業(yè)務(wù)編排層：需要根據(jù)實際業(yè)務(wù)進行設(shè)計，工程師的工作就是把原子業(yè)務(wù) API 按需求進行報文適配、流程組合、數(shù)據(jù)讀寫，并打包成為接口供前端調(diào)用；

網(wǎng)關(guān)層：APISIX 所在的層，是后臺服務(wù)的業(yè)務(wù)邊界，負責負載均衡、服務(wù)注冊與發(fā)現(xiàn)、用戶鑒權(quán)、基礎(chǔ)網(wǎng)絡(luò)報文數(shù)據(jù)轉(zhuǎn)碼、內(nèi)外交互日志的統(tǒng)一記錄、部分安全管控等等。與業(yè)務(wù)無關(guān)并且通用的服務(wù)統(tǒng)一放置到本層；

展示層：從用戶角度出發(fā)，設(shè)計便利的交互界面。此處使用了一個開源的前端全響應(yīng)式 admin 網(wǎng)頁模板，即使開發(fā)者（運維）不熟悉 JavaScript ，也可以自己實現(xiàn)基本的表單和報表。

平臺使用的組件

核心網(wǎng)關(guān) Apache APISIX：主要負責日志記錄、網(wǎng)絡(luò)安全以及負載均衡。另外我們不但通過自定義插件實現(xiàn)了高級業(yè)務(wù)網(wǎng)關(guān)的部分功能，而且還通過 API 能方便的和其他服務(wù)整合，快速實現(xiàn)各種指定功能，有效降低開發(fā)成本；

API 管理工具 YAPI：負責對接口的規(guī)范定義，測試用例編寫和作為 ACL 的數(shù)據(jù)源；

訪問控制組件 Casbin：輕量級、多模式、強范式的跨語言開源訪問控制框架，我們使用的是基于RESTful 的 PyCasbin；

數(shù)據(jù)存儲：MySQL 5.7；

自研 Web 框架 mug-skeleton：使用自研的 Web 框架，主要是為了更深層次的技術(shù)控制能力。

對接的第三方平臺相關(guān)組件

CMDB（自研）：在開源的 CMDBuild 外包了一層 RESTful 的 API，方便交互；

OpenLDAP：用于用戶的賬號驗證，不負責鑒權(quán)；

工作流 Activiti：使用官方的 RestAPI 服務(wù)，由于是處于在網(wǎng)關(guān)后方，因此不需要考慮安全問題。

業(yè)務(wù)場景

用戶登錄及權(quán)限驗證

對于所有的 Web 框架，用戶登錄是一個必選項，接下來我將為大家介紹此場景。

首先，我們需要了解下場景中，我們的使用的相關(guān)組件，第一個就是訪問的前端，這個是在網(wǎng)關(guān)之外的，其次使用 APISIX 云原生 API 網(wǎng)關(guān)作為業(yè)務(wù)邊界。再之后的 Auth 服務(wù)，它是自定義開發(fā)的微服務(wù)，作用是校驗前端的 URL 請求和用戶登錄請求，并對通過認證的用戶發(fā)放 Token。LDAP 中存放的是公司內(nèi)部的密碼信息。CMDB 存儲的是一些業(yè)務(wù)的相關(guān)信息，包括組織結(jié)構(gòu)，可以訪問的權(quán)限的一些組織信息，最后是前端需要訪問的頁面。

了解完以上組件后，接下來，為大家介紹整體流程：

用戶登錄的時候，首先需要通過網(wǎng)關(guān)查詢，訪問的頁面是否在白名單中。因為部分頁面是不需要權(quán)限驗證的，比如：默認頁面或者一些錯誤頁面。如果訪問的頁面是需要驗證登錄的，那么這些請求就會通過相關(guān)插件，轉(zhuǎn)發(fā)到權(quán)限認證服務(wù)。

在權(quán)限認證中，鑒權(quán)服務(wù)會根據(jù)傳入的“用戶名”和“密碼”，從 LDAP 中查詢賬號是否正確。如果正確，就會通過 CMDB 查詢該用戶是屬于哪個組織、可以查看哪些功能模塊；得到結(jié)果后，使用 APISIX 的 JWT 插件，根據(jù)用戶信息生成一個 Token，并添加過期時間，返回給前端；用戶通過 Cookie 的方式進行Token存儲。該用戶后續(xù)如果繼續(xù)訪問，網(wǎng)關(guān)會從 Cookie 中把之前存儲的 Token 調(diào)出來，驗證當前用戶是否可以繼續(xù)訪問后面的頁面。

在這里，我們使用了 APISIX 的 consumer-restriction 插件，上述所講的權(quán)限認證，實際上就是通過 consumer-restriction 插件來完成的，不需要我們在后臺多次反復(fù)認證。

通過上述的描述，相信大家已經(jīng)對正常的請求流程有了一定的理解，接下來將為大家介紹下如何判斷這些用戶權(quán)限不足的場景。在運維平臺中，如果有涉及到數(shù)據(jù)變更的操作，必須要攜帶 Token，當這個 Token 被 ACL 的接口驗證無權(quán)訪問后，就會直接返回一個禁止訪問的頁面，讓前端進行處理。以下是用戶登錄及權(quán)限驗證場景的具體流程和其中更使用的相關(guān)組件。

新業(yè)務(wù)微服務(wù)接入

在日常工作，我們經(jīng)常會上線一些微服務(wù)，那么如何讓這個微服務(wù)接入自動化運維平臺呢？

我們內(nèi)部會規(guī)定無論工程師使用哪種語言開發(fā)微服務(wù)，都需要使用 YAPI 對 API 進行定義。因此 YAPI 對我們所有可訪問的那些 URL 進行管控，統(tǒng)一一個入口在這邊。因為 YAPI 支持定義各種環(huán)境，所以我們在 YAPI 中定義了不同運行環(huán)境。最典型的示例就是：在生產(chǎn)環(huán)境中，我們會使用域名訪問；而在開發(fā)環(huán)境，就直接使用 127.0.0.1 進行訪問。完成 YAPI 的定義后，它就可以通過 mock 的方式，生成一系列請求用例，非常有利于后續(xù)進行生產(chǎn)環(huán)境的測試。所有的微服務(wù)接口，都可以通過 HTTP 請求的方式進行 mock 調(diào)用。

接下來，就是權(quán)限管理服務(wù)，這里所有的操作都是自動的：它會從 YAPI 中讀取 API 的定義，然后生成一系列的 ACL 規(guī)則。對于權(quán)限的管理，我們在平臺中使用了一個管理頁面：管理員可以通過該頁面管理 URL 的訪問規(guī)則，設(shè)置完成后，表單數(shù)據(jù)就會變更為一系列的 ACL 權(quán)限定義，存入數(shù)據(jù)庫中。在服務(wù)啟動的過程中，平臺使用的 cachebin 的訪問模型就會直接從數(shù)據(jù)庫中，把這些規(guī)則加載到內(nèi)存里，然后生成一系列 APISIX 的 Consumer 的定義及路由表，寫入 APISIX 的 etcd 中。完成上述操作后，當用戶訪問的時候，平臺就可以直接通過 APISIX 進行一個權(quán)限管理。

該模型不但適用于自動化運維平臺，也同樣適用于各種中小型業(yè)務(wù)體系。

技術(shù)細節(jié)

通過上述的場景描述，相信大家已經(jīng)對整套體系有了大概的認識，接下來為大家介紹下部分技術(shù)細節(jié)。

因為 APISIX 是基于 NGINX + Lua 實現(xiàn)的，所以部分功能需要通過 NGINX 的庫來實現(xiàn)。從上圖中，我們可以看到各種 Lua 腳本可以在哪些點切入到 NGINX 當中。在本文中，主要是為大家介紹 Rewrite/Access 以及 Content 階段可以進行的操作。

因為在 Rewrite/Access 階段，報文還沒有轉(zhuǎn)給 Upstream，所以可以在該階段進行各種各樣的數(shù)據(jù)預(yù)處理。從上圖中我們可以看到有個 access_by_lua，在該階段，可以使用 deny 命令進行權(quán)限的管理，包括接口權(quán)限以及 IP 準入白名單都可以在該階段實現(xiàn)。后文所介紹的 acl_plugin.lua 的插件就是在該階段實現(xiàn)的。

其次在 header_filter_by_lua 這個階段，常用于在請求訪問時，額外的在 HTTP 請求頭插入一些 key:value，供后續(xù)使用。例如，當需要我們線上灰度發(fā)布時，就可以在用戶的請求頭中加入標志位，通過這些標志位，就可以控制這些請求轉(zhuǎn)發(fā)哪些后端服務(wù)，從而實現(xiàn)灰度發(fā)布。當然我們也可以使用 APISIX 的 traffic-split 插件實現(xiàn)灰度發(fā)布。

最后就是 log_by_lua 階段，在該階段，我們可以把一些 trace 信息或者一些故障信息可以直接輸入到 log 文件中。同樣的，針對 Loggers，APISIX 也提供了非常多的插件，包括 skywalking-logger、kafka-logger、rocketmq-logger 等等。

自定義插件 acl-plugin.lua

acl-plugin.lua 插件的實現(xiàn)非常簡單。首先當用戶在請求的過程中，我們會給用戶添加相關(guān)的 JWT token 存儲在 cookie 里面，之后該用戶會從訪問的 cookie 中提取 JWT token，然后對該 token進行解碼并獲取用戶信息。

在 Rewrite 階段，通過使用用戶 ID、method及 URI，向后臺 ACL 接口發(fā)起請求進行權(quán)限驗證。如果通過了，就會把相關(guān)信息記錄到 log 中，供以后的安全認證使用。如果失敗了，就直接返回一個錯誤狀態(tài)碼并記錄到 error log 中。

在 APISIX 1.1 版本中，當時 cors 插件還沒有發(fā)布，因此對于跨域請求，我們也是通過該插件進行實現(xiàn)，當請求使用 GET 和 POST 的請求方法時，會進行相關(guān)的處理。如果是其他請求，則會直接通過，而現(xiàn)在可以直接使用 APISIX 的 cors 插件實現(xiàn)。APISIX 現(xiàn)在也可以使用多種語言進行插件的開發(fā)， 不僅僅是 Lua，詳細信息可參考：https://apisix.apache.org/zh/docs/apisix/plugin-develop%E3%80%82

Auth 服務(wù)

Auth 服務(wù)是與 acl-plugin.lua 插件配套的認證服務(wù)。該服務(wù)實現(xiàn)的功能非常簡單，主要是讀取請求報文中的信息，然后解碼出所需的認證元素，之后再把它轉(zhuǎn)發(fā)到相關(guān)的服務(wù)接口中。服務(wù)接口會根據(jù)認證信息返回相應(yīng)的結(jié)果，APISIX 會根據(jù)結(jié)果拒絕或通過該請求。

Auth 服務(wù)中最核心的功能就是從數(shù)據(jù)庫中把 ACL 規(guī)則加載到內(nèi)存里面。主要功能分為兩部分：

首先 account 接口。該接口主要作用就是：用戶訪問的時候，如果需要權(quán)限認證，則會通過向 LDAP 服務(wù)發(fā)送用戶的相關(guān)信息，進行認證。如果認證通過，則會從 CMDB 中查詢出用戶可訪問的相關(guān)信息，然后和用戶角色、過期時間等元素，一起組成 JWT Token，并生成一個 Cookie 返回給用戶，并且同時把該用戶信息在 APISIX 中注冊一個 Consumer 。該接口還實現(xiàn)了一個 acl_check 的功能，負責對用戶認證信息驗證，判斷該認證是成功還是失敗。

其次是 yapi 接口。該接口的主要作用是與 YAPI 進行交互。因為 YAPI 中有一個是供項目訪問的token，帶著這個 token，就可以讀取到這個項目所有的 API定義。因此該接口的主要功能，就是從 YAPI 中讀取 API 的 HTTP 接口定義，存儲到數(shù)據(jù)庫中，然后和權(quán)限管理的頁面進行一個表單交互，組合成 ACL 表，最后生成一系列 Casbin 的規(guī)則存到數(shù)據(jù)庫中。

總結(jié)

以上就是同程數(shù)科基于 Apache APISIX 的自動化運維平臺的架構(gòu)及部分場景的介紹。現(xiàn)在，APISIX 的功能越來越強大，已經(jīng)支持使用 Wasm 和 Python 進行插件開發(fā)。Apache APISIX 的生態(tài)也非常強大，如果大家有任何問題歡迎到社區(qū)中進行交流討論。

審核編輯：郭婷