APISIX 王院生:再談 APISIX 高性能實踐

百家 作者:又拍云 2019-10-23 10:46:31 閱讀:20

2019 年 8 月 31 日,OpenResty 社區聯合又拍云,舉辦 OpenResty × Open Talk 全國巡回沙龍·成都站,APISIX 主要作者王院生在活動上做了《APISIX 高性能實踐》的分享。

OpenResty × Open Talk 全國巡回沙龍是由 OpenResty 社區、又拍云發起,邀請業內資深的 OpenResty 技術專家,分享 OpenResty 實戰經驗,增進 OpenResty 使用者的交流與學習,推動 OpenResty 開源項目的發展。

王院生,APISIX 項目發起人和主要作者,OpenResty 社區、OpenResty 軟件基金會發起人,《OpenResty 最佳實踐》主要作者。

?

以下是分享全文:

首先做下自我介紹,我大學畢業后在傳統金融行業工作九年,2014 年加入奇虎 360,期間撰寫了《OpenResty 最佳實踐》。我個人比較喜歡研究技術和開源,可能是受老羅影響,喜歡嘗試理想化的事情。今年 3 月份與志同道合的伙伴一起創辦了深圳支流科技公司,這是一家以開源方式創業的科技公司,在國內屈指可數,APISIX 是我們目前的主要項目。

APISIX 是微服務 API 網關產品,今年 7 月份我在上海做過一次關于“ APISIX 高性能實踐”的分享,這次的內容是在上次分享的基礎上,并會將最近的新積累分享給大家。


什么是 API 網關

API 網關的地位越來越重要,它是所有流量的出入口,從圖中可以看到請求方可能來自于瀏覽器、loT 設備以及移動設備等,API 網關作為中間管控層需要做安全控制、流量以及日志記錄等。越來越多的企業采用了微服務的方式,以此完成內部解耦、靈活部署、彈性伸縮等技術特性從而滿足業務需求。微服務的數量和復雜度也都隨之水漲船高,通過 API 網關來完成統一的流量管理調度就非常必要,并對 API 網關提出了更高要求。


APISIX 概述

上圖是 APISIX 的基本構架,由于要支持集群和高可用,所以在任何一個節點都需要包含 adminAPI 或 APISIX 內核,使用時可以只啟用其中一部分或都啟用。admin API 主要用于接收管理員的提交信息,通過 json schema 完成參數的校驗,防止非法參數落到存儲的配置中心。APISIX 內部部分處理外部請求,根據請求特征,匹配到具體路由規則,執行插件,然后把流量轉發到指定上游服務。

APISIX 每個月會發布一個版本,在 0.7 版本支持了路由插件化,很自豪地說這是目前唯一允許自定義路由的 API 網關實現。除了之前已有的 r3 路由,APISIX 新增了專門高性能的前綴匹配 radixtree,radixtree 是由 Redix 的作者開源出來的。radixtree 代碼的匹配效率是 r3 的 10 倍甚至更高,一些生產用戶升級 radixtree 后 CPU 使用率確實下降明顯。

上圖顯示的是兩個月前 APISIX 已有的功能。

最近的兩個月,APISIX 增加了以上新功能,每個月大概都會有 5、6 個大的新特性,如果我只準備 APISIX 里的一些新特性與大家分享,各位受益可能會比較小,所以今天我給大家分享一些通用的 OpenResty 編程技巧。?

APISIX 主打的是高性能,我們與 OpenResty 對比性能,這樣更能突出 APISIX 性能的極致。首先用 APISIX 完整服務來壓測,對比一個沒有任何功能的空 OpenResty 服務,發現 APISIX 在加載了所有功能的情況下只下降了 15% 的性能。換言之,你如果能接受 15% 的性能下降,就可以直接享受上圖的所有功能。???


OpenResty 優化技巧

路由:radixtree vs r3

既然已經有了 r3 ,為什么我們還要繼續用 resty-radixtree 實現新的路由呢?

先介紹 r3 的問題:r3 的學習復雜度比較高(正則本身就有學習難度),并且不支持通過迭代器的方式迭代匹配結果,效率相比前綴樹實現低不少。相反這些問題在 resty-radixtree 上都有完美解決方案,性能、穩定性自然也就提升很多。目前的 resty-radixtree 是基于 antirez/rax 實現的,也是 Redis 的作者寫的,站在巨人肩膀可以讓我們少走不少彎路。

從數據結構上看,前綴樹理論上是比哈希算法更快,原因是哈希算法的真正復雜度是O(K),K 是指查詢的 Key 的長度,Key 越長哈希算法把字符串變成整數就越復雜,而前綴樹是層層遞進,最壞的復雜度就是 O(K),因此前綴樹的最壞效率與哈希算法是一樣的。

當然這只是原理上的,經過專門測試發現 Lua table 的哈希查找速度秒殺前綴樹,這是因為在編譯 LuaJIT 的時候,它使用了 CPU 指令集來計算哈希值,這樣可以完美的做到 O(1),所以 LuaJIT table 的哈希是效率是最高的,其次才是前綴樹。?

在 LuaJIT 世界匹配效率最高,永遠都是先優先使用 Lua table 的哈希匹配。我們最終也沒直接使用前綴樹(trietree),因為它比較消耗內存,而是采用了基數樹(radixtree),在性能相差不多的情況下,內存占用更小。

OpenResty VS Golang、HTTP VS?gRPC

2015 年我沒有選擇 Golang 而選擇 OpenResty,原因是我認為 OpenResty 可以思考地更深入,而 Golang 只能站在應用層去解決問題,出于這個原因我選擇了 OpenResty。

APISIX 支持了這樣一個場景:HTTP(s) -> APISIX -> gRPC server,把 REST API 轉成 gRPC 請求。完成該功能后,需要做些壓力測試驗證效果。為了方便對比,用 Golang 的方式也寫了一個協議轉換網關。測試發現?APISIX 的版本比 Golang 的版本性能略還好一點,我的電腦上都是單核 1 萬左右的 QPS。本以為在 gRPC 領域 Golang 的性能應當是最好的,沒想到 APISIX 有機會略勝一籌。

我們之前粗淺地認為 HTTP 的性能一定沒有 gRPC 的性能好,現在看有點武斷。gRPC 的很多優勢是 HTTP 不具備的,比如它的體積更小且內置 schema 檢查等。但如果你的請求體比較小,在 HTTP 上使用 json 加 json schema,它們倆的性能幾乎相同,尤其是在內網環境下相差還是非常小的。如果請求體比較大編碼復雜,那么 gRPC 會有明顯優勢。

ngx.var?的加速

對獲取 Nginx 變量的加速,最簡單的就是用 iresty/lua-var-nginx-module 倉庫,把它作為一個 lua module 編譯到 OpenResty 項目里。當我們提取對應的 ngx.var 的時,使用庫里提供的方法來獲取,可以讓 APISIX 整體有 5% 的性能提升,單純某個變量性能對比,至少有 10 倍差別。當然也可以把這個模塊編譯成動態庫,然后用動態方式加載,這樣就不用重新編譯 OpenResty。

APISIX 網關會從 ngx.var 里獲取大量變量信息,比如 host 地址等變量更是可能會被反復獲取,每次都與 Nginx 交互效率會比較低。因此我們在 APISIX/core 里加了一層 ctx 緩存,也就是第一次與 Nginx 交互獲取變量,后面將直接使用緩存。

題外篇:再次推薦大家多參考借鑒 APISIX/core 中的代碼,這些代碼是通用的,對大多數項目都應該有借鑒意義。

fail to json encode

當我們用 json 的方式去 encode 一個 table時,可能會失敗。失敗原因有以下幾種:比如 table 中包含 cdata 或者 userdata 無法 encode ,又或者包含 function 等,但實際上我們做 encode 并不是想要一個可以完美支持序列化/反序列化的結果,有時候只是為了調試。

所以我在 APISIX 的 core/json_encode 增加了一個布爾參數,表示是否進行強制轉碼,這樣當遇到不能轉碼時就把強制它變成一個字符串。此外 table 套 table 是一個常見的情況,即有一個 table A,在 A 的 table 里面的內部又引用了A 自身,形成了一個循環嵌套。這個問題的解決比較簡單,在發生嵌套時,到達某一個位置點后就不要再往里嵌了。這兩個場景下允許強制 table encode 對我們開發調試非常有用。

在調試時,如果需要打一下 table 結果,當日志級別不夠時,不應該觸發無意義的 jsonencode 行為,這時候推薦使用 delay_encode 來調試日志,只有當日志真正需要寫到磁盤上時,才會觸發 json encode,避免那些不需要 encode 。這個問題在APISIX 里面效果非常好,終于不需要注釋代碼就可以完成不同級別日志的測試,有點 C 語言中宏定義的味道,對性能和易用是個極好的平衡。

靜態代碼檢測工具

目前 APISIX 進行 CI 回歸,都會運行代碼檢查工具進行檢查:Lua -check 和 lj-releng。對當前代碼目錄的內容做靜態檢測,比如有沒有加全局的變量,代碼行的長度是不是超了等。

rapid json?的生命周期

調試過程中發現的一個特別有意思的關于 rapid json 聲明周期的 bug。關于這個周期的原因可以看一下上圖的最后一行,我們真正使用的是 validator,而且只調用了validator 的一個驗證,它是從上邊的 create-validator 得來的。這里值得注意的是,為什么用一個數組緩存住另一個叫 sd 的對象呢?

因為 validator 是個 cdata ,內部有對 sd 對象的指針引用依賴,他們兩個也就必須要有相同的聲明周期,不能有某一項提前釋放的情況。如果我們需要讓兩個對象有相同的生命周期,那么把它們放到同一個 table 中是最簡單的方法。

第三方庫使用 ?pcre

如果你選擇效率最高的 C 庫,而這個 C 庫里還引用了 pcre 這個庫,那就需要考慮到一個問題,這個對象的跨請求就會有非常大的風險,為此必須要單獨給這個庫創建獨立的內存池,決不能使用當前請求的內存池,因為當前請求很快就被釋放。

怎么解決這個問題呢?如果現在 OpenResty 有相關的 API,那么直接去申請內存池是最好的,但是可惜 OpenResty 并不具備。看看 Ningx 源碼,可以看到創建 Nginx 的內存池函數定義是 ngx_create_pool(size_tsize, void *log) ,只要能獲取到全局日志句柄即可。

我們選擇從全局的 ngx_cycle 獲取 log 對象,這里我定義了一個虛假的 fake_ngx_cycle 結構體,這個結構體和 Nginx 的 ngx_cycle 構體的前三項是一樣的,但是截掉了后面的部分,然后我們做內存拷貝,從而得到了 log 對象指針位置。

開啟 prometheus 插件

我當時在研究 Kong 的 prometheus 插件時粗略看了一下它的代碼,發現他的實現邏輯是有問題的,會非常影響性能。所以沒有直接使用 Kong 的方式,在 APISIX 中開啟這個 插件,性能只會下降5% 左右。這個插件我們比 Kong 高近 10 倍性能。我也和 Kong 的技術負責人聊過這里,后續會把 APISIX 的一些做法貢獻給 Kong,相互學習一起成長。

?

以上是我今天的全部分享,謝謝大家!

?


快 來 找 又 小 拍



推?薦 閱 讀




?告 訴 大 家 你 “在 看” 這 篇 文 章???

關注公眾號:mcbang_com 了解更多精彩內容

[廣告]贊助鏈接:

選擇AiDeep,讓人工智能為你工作:http://www.aideep.com/
四季很好,只要有你,文娛排行榜:http://www.yaopaiming.com/
讓資訊觸達的更精準有趣:https://www.0xu.cn/

關注網絡尖刀微信公眾號
隨時掌握互聯網精彩
湖南体彩排三论坛专区