項(xiàng)目背景

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

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

為什么選擇 Apache APISIX

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

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

自動(dòng)化運(yùn)維平臺(tái)架構(gòu)

自動(dòng)化運(yùn)維平臺(tái)整體架構(gòu)圖如下：

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

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

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

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

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

平臺(tái)使用的組件

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

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

訪問(wèn)控制組件 Casbin：輕量級(jí)、多模式、強(qiáng)范式的跨語(yǔ)言開源訪問(wèn)控制框架，我們使用的是基于RESTful 的 PyCasbin；

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

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

對(duì)接的第三方平臺(tái)相關(guān)組件

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

OpenLDAP：用于用戶的賬號(hào)驗(yàn)證，不負(fù)責(zé)鑒權(quán)；

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

業(yè)務(wù)場(chǎng)景

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

對(duì)于所有的 Web 框架，用戶登錄是一個(gè)必選項(xiàng)，接下來(lái)我將為大家介紹此場(chǎng)景。

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

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

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

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

在這里，我們使用了 APISIX 的 consumer-restriction 插件，上述所講的權(quán)限認(rèn)證，實(shí)際上就是通過(guò) consumer-restriction 插件來(lái)完成的，不需要我們?cè)诤笈_(tái)多次反復(fù)認(rèn)證。

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

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

在日常工作，我們經(jīng)常會(huì)上線一些微服務(wù)，那么如何讓這個(gè)微服務(wù)接入自動(dòng)化運(yùn)維平臺(tái)呢？

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

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

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

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

通過(guò)上述的場(chǎng)景描述，相信大家已經(jīng)對(duì)整套體系有了大概的認(rèn)識(shí)，接下來(lái)為大家介紹下部分技術(shù)細(xì)節(jié)。

因?yàn)?APISIX 是基于 NGINX + Lua 實(shí)現(xiàn)的，所以部分功能需要通過(guò) NGINX 的庫(kù)來(lái)實(shí)現(xiàn)。從上圖中，我們可以看到各種 Lua 腳本可以在哪些點(diǎn)切入到 NGINX 當(dāng)中。在本文中，主要是為大家介紹 Rewrite/Access 以及 Content 階段可以進(jìn)行的操作。

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

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

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

自定義插件 acl-plugin.lua

acl-plugin.lua 插件的實(shí)現(xiàn)非常簡(jiǎn)單。首先當(dāng)用戶在請(qǐng)求的過(guò)程中，我們會(huì)給用戶添加相關(guān)的 JWT token 存儲(chǔ)在 cookie 里面，之后該用戶會(huì)從訪問(wèn)的 cookie 中提取 JWT token，然后對(duì)該 token進(jìn)行解碼并獲取用戶信息。

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

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

Auth 服務(wù)

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

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

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

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

總結(jié)

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

審核編輯：郭婷