2019 年 7 月 6 日，OpenResty 社區(qū)聯(lián)合又拍云，舉辦 OpenResty × Open Talk 全國(guó)巡回沙龍·上海站，OpenResty 軟件基金會(huì)聯(lián)合創(chuàng)始人王院生在活動(dòng)上做了《ApacheAPISIX 的高性能實(shí)踐》的分享。OpenResty x Open Talk 全國(guó)巡回沙龍是由 OpenResty 社區(qū)、又拍云發(fā)起，邀請(qǐng)業(yè)內(nèi)資深的 OpenResty 技術(shù)專家，分享 OpenResty 實(shí)戰(zhàn)經(jīng)驗(yàn)，增進(jìn) OpenResty 使用者的交流與學(xué)習(xí)，推動(dòng) OpenResty 開(kāi)源項(xiàng)目的發(fā)展。活動(dòng)將陸續(xù)在深圳、北京、武漢、上海、成都、廣州、杭州等城市巡回舉辦。

王院生，OpenResty 社區(qū)、OpenResty 軟件基金會(huì)聯(lián)合創(chuàng)始人，《OpenResty jiao佳實(shí)踐》主要作者，ApacheAPISIX 項(xiàng)目發(fā)起人和主要作者。

以下是分享全文：

大家好，我是王院生，很高興來(lái)到上海。首先做下自我介紹，我于 2014 年加入奇虎360，在那時(shí)認(rèn)識(shí)了 OpenResty，此前我是一個(gè)純粹的 C/C++語(yǔ)言開(kāi)發(fā)者。在 360 工作期間，利用工作閑暇時(shí)間寫了《OpenResty jiao佳實(shí)踐》，希望能影響更多的人正確掌握 OpenResty 入門。2017 年我作為技術(shù)合伙人和春哥(章亦春，agentzh)一起創(chuàng)業(yè)。今年我個(gè)人的重心有所調(diào)整并在今年三月份離職，準(zhǔn)備將更多精力投入到開(kāi)源上，于是發(fā)起了Apache APISIX 這個(gè)項(xiàng)目，企業(yè)宗旨是依托開(kāi)源社區(qū)，致力于微服務(wù) API 相關(guān)技術(shù)的創(chuàng)新和實(shí)現(xiàn)。

什么是 API 網(wǎng)關(guān)

API 網(wǎng)關(guān)的地位越來(lái)越重要，它幾乎劫持了所有流量，內(nèi)外之間完成了用戶的安全控制、審計(jì)，通過(guò)自定義插件的方式滿足企業(yè)自身特定需求，jiao常見(jiàn)的自由身份認(rèn)證等。隨著服務(wù)在數(shù)量和復(fù)雜度上的不斷增長(zhǎng)，更多的企業(yè)采用了微服務(wù)的方式，這時(shí)通過(guò) API 網(wǎng)關(guān)來(lái)完成統(tǒng)一的流量管理和調(diào)度就非常有必要。

微服務(wù)網(wǎng)關(guān)和傳統(tǒng)意義上的 API 網(wǎng)關(guān)有一些不同，主要包括下面幾點(diǎn)：動(dòng)態(tài)更新：在微服務(wù)之前，服務(wù)不像現(xiàn)在這樣經(jīng)常來(lái)回地變化。比如微服務(wù)需要做橫向擴(kuò)充，或者故障恢復(fù)、熱備、切換等，IP、節(jié)點(diǎn)等變動(dòng)更加頻繁。舉例如微博上一旦出現(xiàn)了爆點(diǎn)事件，就急速擴(kuò)充計(jì)算點(diǎn)，必須要非常快地?cái)U(kuò)充新機(jī)器來(lái)扛壓。波峰波谷變化明顯，分鐘級(jí)別的機(jī)器動(dòng)態(tài)管理，已經(jīng)越發(fā)是常態(tài)。

更低延遲：通常動(dòng)態(tài)就意味著可能會(huì)做一些延遲(復(fù)雜度增加)，在微服務(wù)里面，對(duì)于延遲要求比較高，尤其對(duì)于現(xiàn)在的用戶體驗(yàn)，超過(guò) 1 秒以上的延遲是完全不可接受的。

用戶自定義插件：API網(wǎng)關(guān)是給企業(yè)用戶使用的，它一定存在私有邏輯(比如特殊的認(rèn)證授權(quán)等)，所以微服務(wù)網(wǎng)關(guān)必須能夠支持企業(yè)用戶自定義插件。

更集中的管理 API：如前面所說(shuō) API 網(wǎng)關(guān)劫持了用戶的所有流量，所以用網(wǎng)關(guān)來(lái)做統(tǒng)一的 API 管理是非常必要的。在網(wǎng)關(guān)角度可以看到 API 是如何設(shè)計(jì)，是否存在延遲、安全問(wèn)題，以及響應(yīng)速度和健康信息等。

我們要做的微服務(wù) API 網(wǎng)關(guān)產(chǎn)品，除了上面的基本要求，還有一些是我們區(qū)別于其他人的：通過(guò)社區(qū)聚焦：通過(guò)開(kāi)源方式聚焦有共同需求的人群，讓更多不同公司的人可以一起協(xié)作，共同打磨更好的產(chǎn)品，減少冗余開(kāi)發(fā)。

簡(jiǎn)潔的 core：產(chǎn)品的內(nèi)核必須是非常簡(jiǎn)潔的，如果內(nèi)核復(fù)雜，會(huì)使得大家的上手成本高很多，望而卻步肯定不是我們期望的。

可擴(kuò)展性、頂級(jí)性能、低延遲：這幾項(xiàng)都是要同時(shí)嚴(yán)格保障的，也是我們會(huì)花主要精力保證的。目前 APISIX 項(xiàng)目的性能比空跑 OpenResty 只低 15%，這點(diǎn)還是非常值得傲嬌的。

Apache APISIX 高性能微服務(wù)網(wǎng)關(guān)

Apache APISIX 架構(gòu)與功能

△ ApacheAPISIX 的基本架構(gòu)

上圖是 ApacheAPISIX 的基本架構(gòu)，羅列用到的幾個(gè)基本組件。其中包括 ETCD 可以完成配置存儲(chǔ)，由于 ETCD 可以走集群，所以我們可以借用它完成動(dòng)態(tài)伸縮、高可用集群等。ETCD 數(shù)據(jù)支持通過(guò) watch 的方式增量獲取，使得 ApacheAPISIX 節(jié)點(diǎn)規(guī)則更新可以做到毫秒級(jí)，甚至更低。ApacheAPISIX 自身是無(wú)服務(wù)狀態(tài)的，所以方便橫向擴(kuò)充。

另一個(gè)組件是 JSON Schema，它是一個(gè)標(biāo)準(zhǔn)協(xié)議，主要用來(lái)驗(yàn)證數(shù)據(jù)的有效性。JSON Schema 目前對(duì)外公開(kāi)有四個(gè)不同版本，我們jiao終選用 RapidJSON，因?yàn)樗麑?duì)這四個(gè)版本都有相對(duì)完整的支持。

圖中的 Admin API 和 ApacheAPISIX 可以放在一起，也可以分開(kāi)。Admin API 接收用戶提交的請(qǐng)求，在請(qǐng)求參數(shù)保存到 ETCD 之前，會(huì)使用 JSON Schema 做一次完整校驗(yàn)，有了校驗(yàn)可以確定到 ETCD 里的都是有效數(shù)據(jù)。

上圖右側(cè)是接收外部用戶的真實(shí)流量，ApacheAPISIX 從 ETCD 中訂閱所有配置規(guī)則，拿到配置規(guī)則后給到下面的路由引擎(libr3)，目前默認(rèn)使用的路由引擎是 libr3，我之前在武漢的分享中進(jìn)行過(guò)詳細(xì)介紹(https://www.upyun.com/opentalk/428.html)。 libr3 是一個(gè)路由引擎實(shí)現(xiàn)，基于前綴樹(shù)，由于他還支持正則，所以效率非常高的，同時(shí)功能也很強(qiáng)大。

ApacheAPISIX 的 v0.5 版本具備以下功能：

△ ApacheAPISIX 已有功能

Apache APISIX 的性能

△ 性能對(duì)比

通常來(lái)說(shuō)，引入了前面提到的十幾項(xiàng)功能，會(huì)伴隨著性能的下降，那么究竟下降了多少呢？這里我做了一個(gè)性能的測(cè)試對(duì)比。如上圖，右側(cè)是我為了測(cè)試寫的一個(gè)虛假的服務(wù)，這個(gè)服務(wù)里面空空如也，只是把 ngx_lua 里的一些變量拿出來(lái)，然后傳給了什么都不做的 fake_fetch，后面的 http filter、log 階段等一樣，沒(méi)有任何計(jì)算量。

然后對(duì) ApacheAPISIX 和右邊的虛假服務(wù)分別跑壓力測(cè)定，對(duì)比結(jié)果發(fā)現(xiàn) ApacheAPISIX 的性能僅僅下降了 15%，也就是說(shuō)在接受了 15% 的性能下降的同時(shí)，就可以享受前面提到的所有功能。

說(shuō)一下具體數(shù)值，這里使用的是阿里云的計(jì)算平臺(tái)，單 worker 下可以跑到 23-24k QPS，4 worker 可以跑到 68k 的 QPS。

Apache APISIX 目前的狀態(tài)

目前jiao新版本是 v0.5，架構(gòu)是基于 ETCD+libr3+RapidJSON。這個(gè)版本加的jiao多的是代碼覆蓋率，v0.4 版本代碼覆蓋率不超過(guò) 5%，但jiao新版本中代碼覆蓋率達(dá)到 70%，這其中 95% 是核心代碼，周邊的代碼覆蓋率相對(duì)較低，主要是插件的相關(guān)測(cè)試有所欠缺。

原本計(jì)劃在 0.5 版本上線管理界面功能，這樣可以降低入門門檻，但是遺憾的是目前還沒(méi)開(kāi)發(fā)完成，這與我們自身專業(yè)有關(guān)系，不擅長(zhǎng)做前端界面，需要借助前端的專家?guī)臀覀儗?shí)現(xiàn)，我們計(jì)劃會(huì)在 0.6 的版本上線(注：目前已經(jīng)發(fā)布了 v0.6 版本：https://github.com/iresty/apisix/blob/master/CHANGELOG_CN.md#060)。

OpenResty 編程哲學(xué)與優(yōu)化技巧

我從 2014 年開(kāi)始做 OpenResty 開(kāi)發(fā)，至今已經(jīng)有六年了。在 OpenResty 的領(lǐng)域里，它的哲學(xué)是要學(xué)會(huì)大事化小，小事化了，因?yàn)?Nginx 的內(nèi)存管理方式是把所有的請(qǐng)求內(nèi)存默認(rèn)放到一個(gè)內(nèi)存池里，請(qǐng)求退出的時(shí)再把內(nèi)存池銷毀。如果不能很快地一進(jìn)一出，它就會(huì)不停申請(qǐng)，jiao后釋放時(shí)資源損耗很大，這是 Nginx 不擅長(zhǎng)的。所以用 OpenResty 做長(zhǎng)連接就需要非常小心，避免把內(nèi)存池搞大。

此外，要盡可能少地創(chuàng)建臨時(shí)對(duì)象。這里所指的臨時(shí)對(duì)象有兩類，一類是 table 類，一類是字符串拼接，比如某兩個(gè)變量拼接產(chǎn)生新的字符串，這個(gè)看似在其他很多語(yǔ)言都沒(méi)有問(wèn)題，但在 OpenResty 里需要盡量少做這種操作。Lua 語(yǔ)言雖然簡(jiǎn)單，但也是門高級(jí)語(yǔ)言，攜帶了優(yōu)良的 GC ，讓我們無(wú)需關(guān)心所有變量的生命周期，只負(fù)責(zé)申請(qǐng)就好了，但如果濫用臨時(shí)變量等，會(huì)讓 GC 比較忙碌，付出代價(jià)是整體運(yùn)行效能不高。Lua 擅長(zhǎng)動(dòng)態(tài)和流程控制，如果遇到硬核的 CPU 運(yùn)算任務(wù)，還是推薦交給 C/C++ 實(shí)現(xiàn)。

今天和大家分享優(yōu)化技巧，主要還是如何寫好 Lua，畢竟他的受眾群體更多。在 ApacheAPISIX 的 core 中，我們使用了一些比較特別的優(yōu)化技巧，下面逐一給大家介紹。

技巧一：delay_json

△ delay_json

先說(shuō)一下場(chǎng)景：比如上面的這行日志調(diào)用，如果當(dāng)前日志級(jí)別是 info ，我們期望會(huì)正常 json encode；而當(dāng)是 error 級(jí)別，我們就不期望發(fā)生 json encode 操作，如果能自動(dòng)跳過(guò)是jiao完美了。那我們?nèi)绾谓频膶?shí)現(xiàn)這個(gè)目的呢？

我們看一下 delay_encode 的實(shí)現(xiàn)源碼，首先用元方法重載了 tostring ，下面 delay_encode 只是對(duì) delay_tab 的兩個(gè)對(duì)象 data 和 force 做了賦值，然后沒(méi)有做其他的事情，這與大家平時(shí)看到的 json encode 方法都不一樣。因?yàn)檎嬲趯懭罩緯r(shí)，如果給定的參數(shù)是 table，在 OpenResty 里會(huì)把他轉(zhuǎn)成 string 的，過(guò)程是檢查是否有 tostring 的元方法注冊(cè)，如果有就調(diào)這個(gè)方法把它轉(zhuǎn)換成字符串。有了上面的封裝，我們就在高性能和易用性上做了很好的平衡。

技巧二：HASH vs 前綴樹(shù) vs 遍歷Lua table 的 HASH：性能jiao好的匹配方式，缺點(diǎn)是只能做全量匹配。

前綴樹(shù)：借助 libr3 完成前綴等高級(jí)匹配(支持正則)。

遍歷：永遠(yuǎn)是jiao糟糕的。

在Apache APISIX 的世界里，我把 HASH 和前綴樹(shù)做了融合，如果你的請(qǐng)求和路由規(guī)則不包含高級(jí)規(guī)則匹配，會(huì)默認(rèn)走 HASH 來(lái)保證效率；但如果有模糊匹配邏輯，則使用前綴樹(shù)。

技巧三：ngx.log 是 NYI

△ngx.log

因?yàn)?ngx.log 是 NYI，所以我們要盡量減少下面這段代碼的觸發(fā)頻率：return ngx_log(log_level，…)

要降到j(luò)iao低，需要判斷當(dāng)前日志級(jí)別，如果當(dāng)前的日志級(jí)別和你輸入的日志級(jí)別存在大小比值關(guān)系，發(fā)現(xiàn)不需要輸入就直接 return。避免出現(xiàn)日志處理完，傳到 Nginx 內(nèi)核后再發(fā)現(xiàn)不需要寫日志，這樣就會(huì)浪費(fèi)非常多的資源。

前面提到的壓力測(cè)試，都是把日志打到 error 級(jí)別，加了非常多的調(diào)試代碼并且保留不刪，這些測(cè)試代碼的存在完全不會(huì)影響性能結(jié)果。

技巧四：gc for cdata and table

場(chǎng)景：當(dāng)某個(gè) table 對(duì)象被系統(tǒng)回收時(shí)，希望觸發(fā)特定邏輯以釋放關(guān)聯(lián)資源。那么我們?nèi)绾谓o table 注冊(cè) gc 呢？請(qǐng)參考下圖示例：

當(dāng)我們無(wú)法控制 Lua table 的整個(gè)生命周期，可以用上圖的方法去注冊(cè)一個(gè) GC，當(dāng) table 對(duì)象沒(méi)有任何引用時(shí)會(huì)觸發(fā) GC，釋放關(guān)聯(lián)資源。

技巧五：如何保護(hù)常駐內(nèi)存的 cdata 對(duì)象

我們?cè)谑褂?r3 這個(gè) C 庫(kù)時(shí)遇到這么一個(gè)問(wèn)題：我們給 r3 添加很多路由規(guī)則，然后生成 r3 tree，如果規(guī)則沒(méi)有變化 r3 將被反復(fù)使用，由于 r3 內(nèi)部沒(méi)有申請(qǐng)額外的內(nèi)存存儲(chǔ)，只是引用指針地址。但外面?zhèn)魅氲?Lua 變量可能是臨時(shí)變量，引用計(jì)數(shù)為 0 后會(huì)被 Lua GC 自動(dòng)回收。導(dǎo)致的現(xiàn)象是 r3 內(nèi)部引用的原有內(nèi)存地址內(nèi)容突然發(fā)生變化，jiao后致使路由匹配失敗。

知道了問(wèn)題原因，解決方法就比較簡(jiǎn)單了，只需要避免變量 A 提前釋放，讓 Lua 里面變量 A 的生命周期和 r3 對(duì)象的生命周期保持一致即可。

技巧六：ngx.var.* 是比較慢的

大家知道 C 是不支持動(dòng)態(tài)的，它是編譯性語(yǔ)言。ngx.var.* 的內(nèi)部實(shí)現(xiàn)可以查看 Nginx 源代碼，或者通過(guò)火焰圖的方式可以看到他內(nèi)部的實(shí)現(xiàn)方式。為了完成動(dòng)態(tài)獲取變量，內(nèi)部必須通過(guò)一次 hash 查找，到后用內(nèi)部的規(guī)則把變量值讀出。

解決方案是用上圖這個(gè)庫(kù)(github.com/iresty/lua-var-nginx-module)，非常簡(jiǎn)單沒(méi)有技術(shù)含量的辦法。比如要獲取客戶端的 IP，在 C 里面直接把代碼摘出來(lái)，然后通過(guò) Lua FFI 方式讀取變量的值，就是這么一段小代碼可以讓 ApacheAPISIX 性能有 5% 提升。這么做缺點(diǎn)是必須要對(duì) OpenResty 編譯時(shí)添加這個(gè)第三方模塊，上手成本略高。

技巧七：減少每請(qǐng)求的垃圾對(duì)象

我們要盡可能降低每請(qǐng)求產(chǎn)生的垃圾對(duì)象的數(shù)量，作為 OpenResty 開(kāi)發(fā)者，如果把這句話理解透徹，基本上可以進(jìn)階到前 50% 的行列。

減少不必要的字符串的拼接，并非意味著在需要做拼接字符串的時(shí)候不要拼接，而是需要在腦子里一直有這個(gè)意識(shí)，把無(wú)效的拼接降低下來(lái)，當(dāng)這些小細(xì)節(jié)累積下來(lái)，性能提升就會(huì)非常大。

技巧八：重用 table

△ 請(qǐng)求之間可以共享 table

首先介紹下初級(jí)版的 table.clear。當(dāng)需要使用一個(gè)臨時(shí) table，大家習(xí)慣性的寫法是local t ={}

我們來(lái)聊聊這么做的缺點(diǎn)，如果在開(kāi)頭創(chuàng)建了一個(gè)臨時(shí)的 table t，當(dāng)函數(shù)退出的時(shí)候，t 會(huì)被回收；下次再進(jìn)來(lái)這個(gè)函數(shù)，又會(huì)產(chǎn)生一個(gè)臨時(shí)的 table t。在 Lua 世界，table 的產(chǎn)生和銷毀是非常耗資源的，因?yàn)?table 是一個(gè)復(fù)雜對(duì)象，它不像 number、字符串等簡(jiǎn)單對(duì)象，申請(qǐng)和釋放可以用一個(gè)結(jié)構(gòu)體搞定，它會(huì)讓你的 GC 一下子變得非常忙碌。

如果 worker 里只需要一個(gè)唯一實(shí)例 table 對(duì)象，那么就可以使用 table.clear 方式來(lái)反復(fù)使用這個(gè)臨時(shí)表，比如上圖的臨時(shí)表 local_plugins_hash。

重用 table ：進(jìn)階版 table.pool

△ 請(qǐng)求不能共享 table

有些 Lua table 的生命周期是每請(qǐng)求的，通常是請(qǐng)求進(jìn)入申請(qǐng)對(duì)象，請(qǐng)求退出釋放對(duì)象，這時(shí)候使用 table.pool 會(huì)非常合適。tablepool 中文翻譯過(guò)來(lái)是表池，里面放的是可以重用的 table。官方文檔可以到 https://github.com/openresty/lua-tablepool#synopsis 查看，結(jié)合 ApacheAPISIX 的業(yè)務(wù)使用代碼，更容易理解。

在 ApacheAPISIX 中jiao集中使用的是兩個(gè)地方，除了上圖這里做回收，還有是申請(qǐng)的地方。在回收之后，這些 table 可以被其他請(qǐng)求所復(fù)用，由 tablepool 做統(tǒng)一控制，在 pool 里維持的對(duì)象可能就固定的幾十、幾百個(gè)，會(huì)反復(fù)使用，不存在銷毀的情況。這個(gè)技巧的正確使用，性能至少可以提升 20%，提升效果非常明顯。

技巧九：Irucache 的正確姿勢(shì)

簡(jiǎn)單介紹下 Irucache，Irucache 可以完成在 worker 內(nèi)的數(shù)據(jù)的緩存和復(fù)用，Irucache 有一個(gè)非常大的優(yōu)勢(shì)是可以存儲(chǔ)任何對(duì)象。而共享內(nèi)存則是完成不同 worker 之間的數(shù)據(jù)共享，但它只能存儲(chǔ)簡(jiǎn)單對(duì)象，有些東西是不能跨 worker 共享，比如 function、cdata 對(duì)象等。

對(duì) Irucache 進(jìn)行二次封裝，封裝的內(nèi)容主要包括：key 要盡量短、簡(jiǎn)單：我們?cè)趯?key 時(shí)jiao重要的是要簡(jiǎn)單，key jiao糟糕的設(shè)計(jì)是里面東西很長(zhǎng)，但是有用信息不多。key 理論上大家都喜歡用字符串，但他可以是 table 等對(duì)象，key 盡量做到明確，只包含你感興趣的內(nèi)容，能省略的盡量省略，降低拼接成本。

version 可降低垃圾緩存：這點(diǎn)算是我在做 ApacheAPISIX 的突破：提取出了 version， Irucache+ version 這套組合，可以極大地降低垃圾緩存。

重用 stale 狀態(tài)的緩存數(shù)據(jù)。

△ lrucache 接?口簡(jiǎn)化

上圖是 lrucache 的封裝，從下往上看，key 是 /routes，它跟的版本號(hào)是 conf_version，global 函數(shù)里做的事情是根據(jù) key+version 的方式，去查找有無(wú)陳舊數(shù)據(jù)的緩存，如果有就直接返回，如果沒(méi)有就調(diào) creat_r3_router 完成創(chuàng)建，creat_r3_router 是負(fù)責(zé)創(chuàng)建一個(gè)新的對(duì)象，它只接受一個(gè)傳參 routes，這個(gè)傳參是由 routes.values 傳進(jìn)去的。

這層封裝，把 Irucache new、數(shù)量等都隱藏起來(lái)，這樣很多東西我們看不到，當(dāng)我們需要自定義的時(shí)候可能還是需要關(guān)心這些。ApacheAPISIX 為了簡(jiǎn)化插件開(kāi)發(fā)者對(duì)各種東西的理解，所以必須要做一層封裝，簡(jiǎn)化使用。

△ lrucache jiao佳實(shí)踐?例

上圖是用 version 降低垃圾緩存、重用 stale 狀態(tài)的緩存數(shù)據(jù)，這 Irucache 的二次封裝的代碼。首先來(lái)看第二行，根據(jù) key 去緩存里面取對(duì)象，然后把對(duì)象的 cache_ver 拿出來(lái)和當(dāng)前傳入的 version 做比較，如果相同則判定這個(gè)緩存對(duì)象一定是可用的。

往下多了 stale_obj，stale_obj 在文檔里面說(shuō)明的比較少，它只有在一種情況會(huì)發(fā)生：緩存對(duì)象在 Irucache 中已經(jīng)被淘汰了，但是它只是到了淘汰的邊緣，還沒(méi)有完全被扔掉。上圖中通過(guò)陳舊數(shù)據(jù)的 cache_ver 與進(jìn)來(lái)的 version 做比較，如果 version 一致那就是有效的。所以只要源頭的數(shù)據(jù)沒(méi)有變化，就可以再次使用。這樣我們就可以復(fù)用 stale_obj 從而避免再次創(chuàng)建新的對(duì)象。

到這里可以解釋一下前面提到的：version 可降低垃圾緩存。如果沒(méi)有 version，我們需要把 version 寫到 key 里面，每次 version 變化都會(huì)產(chǎn)生一個(gè)新的 key，那些被淘汰的舊數(shù)據(jù)會(huì)一直存在，沒(méi)辦法剔除掉。同時(shí)意味著 Irucache 里面的對(duì)象數(shù)會(huì)不停增加。而我們前面的方式是保證 key 如果是一個(gè)對(duì)象，只會(huì)有一個(gè) table 與它對(duì)應(yīng)，不會(huì)根據(jù)不同的 version 產(chǎn)生不同的對(duì)象緩存，進(jìn)而降低緩存總數(shù)。

以上是我今天的全部分享，謝謝大家！

總結(jié)

以上是生活随笔為你收集整理的apisix实际应用_Apache APISIX 的高性能实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。