本文做者琚致遠,Apache APISIX PMC,支流科技企業產品與大前端技術負責人。經過閱讀本文,您能夠了解 Apache APISIX 與基本使用場景,以及在低代碼潮流下,Apache APISIX 是如何集成「拖拽」的插件編排能力的。前端
Apache APISIX 是一個生產可用的七層全流量處理平臺,可做爲 API 網關處理業務入口流量,具備極高性能、超低延遲的顯著特性。它內置了 50 多種插件,覆蓋身份驗證、安全防禦、流量控制、Serverless、可觀測性等多個方面,可知足企業客戶常見的使用場景。node
以下方架構圖所示,Apache APISIX 分爲數據面(左側)與控制面(右側)兩部分:經過控制面下發配置到 ETCD,數據面藉助豐富的插件處理內外流量。git
Apache APISIX 暴露了一組接口,方便咱們爲 API 綁定插件。若是咱們但願爲 API 增長限速能力,只需爲 API 綁定 limit-req
插件:github
curl -X PUT http://127.0.0.1:9080/apisix/admin/routes/1 -d '
{
"uri": "/get",
"methods": ["GET"],
"upstream": {
"type": "roundrobin",
"nodes": {
"httpbin.org:80": 1
}
},
"plugins": {
"limit-req": {
"rate": 1,
"burst": 2,
"rejected_code": 503,
"key": "remote_addr"
}
}
}’
複製代碼
調用成功後,當請求到達該 API 時將進行限速管控。 該示例使用 limit-req
實現 API 限速(特定功能),若針對「根據某個插件的處理結果,決定後續的請求處理邏輯」這種場景化需求,該怎麼作呢?當前,現有的插件機制沒法知足這種需求,這時便引伸出插件編排的能力來解決這個問題。apache
插件編排是低代碼的一種表現形式,它能夠幫助企業下降使用成本、增長運維效率,是企業數字化轉型過程當中不可或缺的能力。藉助低代碼 API 網關 Apache APISIX 中插件編排能力,咱們能夠輕鬆地將 50+ 插件經過「拖拽」的方式進行組合編排,被編排的插件也可以共享上下文信息,最終實現場景化需求。api
擴展上述 API 限速的場景:請求使用 key-auth
插件進行身份認證,若認證經過,將由kafka-logger
插件接管並進行日誌記錄;若認證失敗(插件返回 401 狀態碼),將使用limit-req
插件進行限速。安全
見以下操做視頻:
www.bilibili.com/video/BV1J5…markdown
該視頻中,Web 界面列出了目前已有的插件與畫板,咱們能夠將插件拖拽到畫板上進行編排,並填寫插件綁定的數據,而後便完成了整個流程。在整個過程當中:數據結構
那麼 Apache APISIX 是如何與低代碼能力結合的呢?這須要數據面 Apache APISIX 與控制面 Apache APISIX Dashboard 共同配合完成。總體流程以下:架構
在 Apache APISIX 中,咱們在 Route 實體中新增了 script
執行邏輯(PR:github.com/apache/apis…),可用於接收 Dashboard 生成的 Lua 函數並執行,它支持調用已有插件以複用代碼。另外,它也做用於 HTTP 請求的生命週期中的各個階段,如 access
、header_filer
、body_filter
等,系統會在相應階段自動執行 script
函數對應階段代碼,見以下 script
示例:
{
"script": "local _M = {} \n function _M.access(api_ctx) \n ngx.log(ngx.INFO,"hit access phase") \n end \nreturn _M"
}
複製代碼
在 Dashboard 中,它包含了 Web 與 ManagerAPI 共兩個子組件:Web 用於提供可視化界面,方便咱們配置 API 網關;ManagerAPI 用於提供 RESTful API,供 Web 或其它客戶端調用以便操做配置中心(默認爲 ETCD),進而間接地控制 Apache APISIX。
爲了生成合法、有效的 script 函數,ManagerAPI 選擇了 DAG 有向無環圖的數據結構進行底層設計,並自主研發了 dag-to-lua
項目(GitHub:github.com/api7/dag-to…):它將根節點做爲開始節點,根據判斷條件決定下一個流轉插件,這將有效避免邏輯死循環。以下爲 DAG 數據結構的示意圖:
對應到 ManagerAPI 接收的 script
參數上,示例以下:
{
"conf": {
"1-2-3": {
"name": "plugin-a",
"conf": {
...
}
},
"4-5-6": {
"name": "plugin-b",
"conf": {
...
}
},
"7-8-9": {
"name": "plugin-c",
"conf": {
...
}
}
},
"rule": {
"root": "1-2-3", // 起始節點 ID
"1-2-3": [
[
"code == 200",
"4-5-6"
], [
"",
"7-8-9"
]
]
}
}
複製代碼
即客戶端將最終編排後的數據轉換爲上述格式後,ManagerAPI 會藉助 dag-to-lua
項目生成 Lua 函數,並交給 Apache APISIX 執行。
在 Web 側,通過挑選、對比與項目驗證,咱們選擇了螞蟻金服開源的 X6 圖編輯引擎做爲插件編排 Web 部分的底層框架,除了完善、清晰的文檔外,一系列開箱即用的交互組件以及節點可定製化能力也是咱們選擇它的緣由。
在編排實現過程當中,咱們抽象出了通用元件與插件元件的概念:通用元件是指開始節點、結束節點與條件判斷節點,插件元件則是每個可用的 Apache APISIX 插件,經過將這些元件拖拽到畫板中來完成插件編排的流程。如圖所示:
在拖拽過程當中,咱們須要限制一系列的邊界條件,這裏有幾個例子:
當插件未配置時,系統將出現「存在未配置的元件」的錯誤提示,能夠直觀地看到哪一個插件沒有配置數據:
當編輯某條 API 時,若該 API 已經綁定了插件數據,當使用插件編排模式時,系統在檢測後將出現警告信息,只有用戶明確確認但願使用編排模式時,系統才能繼續進行。這能夠有效避免 API 數據被誤操做的狀況。
此外,還存在諸如開始元件只能有一個輸出、條件判斷元件只能有一個輸入等狀況。試想:若是系統不加限制地讓用戶操做,不合理的插件組合既無心義,又會產生沒法預料的錯誤,所以不斷豐富邊界條件,也是在設計插件編排時須要着重考慮的問題。
當咱們完成編排後,將使用 X6 暴露的 API 生成流程圖的 JSON 數據,而後轉換爲系統須要的 DAG 數據,最終生成 Lua 函數。
經過拖拽的方式,可使得使用人員更方便地組合插件來知足不一樣的場景,以提高 API 網關可擴展能力與運維體驗。在實際使用過程當中,存在以下能夠繼續優化的問題:
local _M = {
version = 0.1,
priority = 2500,
type = 'auth',
name = plugin_name,
schema = schema,
# 新增的 result 字段,可存儲插件運行結果,並傳遞到下個插件。
result = {
code = {
type = "int"
}
}
}
複製代碼
Apache APISIX 是一個動態、實時、高性能的開源 API 網關,提供負載均衡、動態上游、灰度發佈、服務熔斷、身份認證、可觀測性等豐富的流量管理功能。Apache APISIX 能夠幫忙企業快速、安全的處理 API 和微服務流量,包括網關、Kubernetes Ingress 和服務網格等。
全球已有數百家企業使用 Apache APISIX 處理關鍵業務流量,涵蓋金融、互聯網、製造、零售、運營商等等,好比美國航空航天局(NASA)、歐盟的數字工廠、中國航信、中國移動、騰訊、華爲、微博、網易、貝殼找房、360、泰康、奈雪的茶等。
200 餘位貢獻者,一同締造了 Apache APISIX 這個世界上最活躍的開源網關項目。聰明的開發者們!快來加入這個活躍而多樣化的社區,一塊兒來給這個世界帶來更多美好的東西吧!