白澤平，Apache APISIX PMC 成員，目前主要在 APISIX 和周邊項(xiàng)目 APISIX Dashboard 上進(jìn)行相關(guān)貢獻(xiàn)。本文整理自阿里云「中間件開發(fā)者 Meetup」中的議題分享。

Apache APISIX 是一個高性能的、動態(tài)的、實(shí)時的 API 網(wǎng)關(guān)，它是基于 NGINX 和 OpenResty 進(jìn)行實(shí)現(xiàn)的。

作為一個脫胎于 NGINX 和 OpenResty 的軟件，APISIX 天然繼承了 NGINX 的性能和 OpenResty 的靈活性，因此，APISIX 的性能在一眾 API 網(wǎng)關(guān)中都是數(shù)一數(shù)二的。

細(xì)數(shù) Apache APISIX 優(yōu)勢

架構(gòu)取長補(bǔ)短

具體來說，像 NGINX + Linux epoll 提供了高性能的網(wǎng)絡(luò) IO 基礎(chǔ)設(shè)施，這些是 C 語言實(shí)現(xiàn)的，是靜態(tài)的。而 OpenResty 則集成了 LuaJIT，它基于 NGINX 提供的生命周期鉤子進(jìn)行擴(kuò)展，允許用戶通過 Lua 代碼對 NGINX 進(jìn)行編程。而 LuaJIT 本身，得益于優(yōu)秀的 JIT 實(shí)現(xiàn)，它可以在運(yùn)行時對代碼進(jìn)行 JIT 編譯，當(dāng)熱路徑上的內(nèi)容被編譯為機(jī)器碼后，性能將可以與原生 C 語言相比。

當(dāng)然，除了 NGINX 與 OpenResty 的天然特性優(yōu)勢外，APISIX 本身也為性能進(jìn)行了多處優(yōu)化。比如沒有復(fù)用 NGINX 的 location 來處理路由匹配，而是使用了基數(shù)樹的方式。目前其他很多 API 網(wǎng)關(guān)還在使用遍歷的方式處理路由，而 APISIX 則不會出現(xiàn)遍歷方式的嚴(yán)重性能衰退，在路由很多時（這里指達(dá)到數(shù)千量級），它也可以提供基本平穩(wěn)的匹配速度。

同時，APISIX 也在動態(tài)性能層面進(jìn)行了一些操作。

相信使用過 NGINX 做服務(wù)部署的朋友一定記得，如果你修改了 NGINX 的配置文件，即使只是添加了一個 location，也必須要通過 NGINX reload 指令來應(yīng)用配置，甚至有時還需要重啟。這種情況對于內(nèi)部應(yīng)用場景來說還可以接受，但是對線上應(yīng)用來進(jìn)行這種操作時，可能會造成客戶端連接的中斷，這就影響很大。

而在 APISIX 中，上述配置操作過程都是完全動態(tài)的，location 可以動態(tài)配置，upstream 和 SSL 證書這些全部都可以動態(tài)配置。這主要得益于 APISIX 使用了 etcd 作為配置中心，通過 etcd watch 機(jī)制實(shí)現(xiàn)了動態(tài)的更新其配置，從而不需要依賴 reload 和重啟。

除此之外，像是以往需要 NGINX 修改配置才可以設(shè)置的 gzip 和緩存等，也可以動態(tài)地在單一路由的維度中進(jìn)行啟用。

如上是 APISIX 體系的架構(gòu)圖，底層就是剛剛提到的 NGINX + Lua 環(huán)境，再向上是 APISIX 的核心模塊，它包括路由、上游等相關(guān)能力，還有一些常用功能的封裝。這個核心模塊也是插件框架的入口，用戶在類似路由等組件中配置路由時，將被合并在此調(diào)用執(zhí)行。

APISIX 在核心模塊中提供了很多開箱即用的功能，比如負(fù)載均衡、動態(tài)上游、灰度發(fā)布、服務(wù)熔斷、身份認(rèn)證、可觀測性、服務(wù)發(fā)現(xiàn)、限流限速和日志收集等功能。

APISIX 中的很多功能都是通過插件方式進(jìn)行實(shí)現(xiàn)的，目前 APISIX 的插件已接近 80 個，未來還在持續(xù)擴(kuò)展增加中。提到插件，不得不說 APISIX 提供的插件運(yùn)行時是一個非常易于開發(fā)的插件框架，用戶可以輕而易舉地使用 Lua 編寫自己的插件，來實(shí)現(xiàn)特定業(yè)務(wù)功能。如果實(shí)在不具備 Lua 的開發(fā)維護(hù)能力也可以使用外部 Plugin Runner（APISIX 多語言插件） 或者 WASM 開發(fā)插件。

開源活躍開放

APISIX 是 Apache 軟件基金會旗下的頂級開源項(xiàng)目，它使用了 Apache License v2 開源協(xié)議，對商業(yè)使用與二次開發(fā)都比較友好。

同時 APISIX 社區(qū)也一直保持著活躍，包括但不限于產(chǎn)品技術(shù)本身的活躍（比如近一個月內(nèi)有 70+ commit，處理了 70+ issue 等），還有社區(qū)活動和一些內(nèi)容分享上的全球布道等。

Apache Way 的理念，指導(dǎo)著每一個 Apache 基金會開源項(xiàng)目，即「社區(qū)>代碼」。社區(qū)的建設(shè)至關(guān)重要，重要性甚至超過項(xiàng)目代碼本身?；剡^頭來我們看，為什么 APISIX 社區(qū)可以如此活躍？

• 社區(qū)開放，歡迎任何有意義的討論（比如問題報告、新功能等）。 除此之外，無論項(xiàng)目維護(hù)者身份如何、來自什么公司，大家都采用同樣的方式參與社區(qū)。所有討論都在郵件列表內(nèi)進(jìn)行，未經(jīng)郵件列表討論的事項(xiàng)，就是不存在的；全部開發(fā)工作也都是公開的，任何事項(xiàng)都有痕跡。

• 經(jīng)常與其他社區(qū)進(jìn)行項(xiàng)目合作。 比如 APISIX 的很多插件都是與其他項(xiàng)目或者服務(wù)的集成，像 Casbin 社區(qū)參與到 APISIX 項(xiàng)目中，貢獻(xiàn)了 casbin 權(quán)限管理和 casdoor 身份認(rèn)證插件。

• 通過各種渠道吸引新的貢獻(xiàn)者參與社區(qū)。 比如 APISIX 項(xiàng)目已連續(xù)多年參與 Google GSoC 計(jì)劃和國內(nèi)開源供應(yīng)鏈點(diǎn)亮計(jì)劃等活動，吸引國內(nèi)外對開源項(xiàng)目感興趣的學(xué)生來參與其中，增加學(xué)生們對開源社區(qū)的經(jīng)驗(yàn)。

周邊項(xiàng)目齊開花

上文我們提到的都是 APISIX 項(xiàng)目本身的一些內(nèi)容。但其實(shí)，基于 APISIX 這個云原生 API 網(wǎng)關(guān)，也衍生出了很多周邊項(xiàng)目。

通過使用 APISIX Ingress Controller，用戶可以將 Kubernetes Ingress 資源和 APISIX 自定義的 CRD 資源提取出來，進(jìn)而為 APISIX 配置路由、上游或插件等。它將自動根據(jù) K8s Service 生成上游，并與路由進(jìn)行關(guān)聯(lián)，提供了一種在 K8s 中的聲明式 API 的實(shí)現(xiàn)路徑。

除此之外，APISIX 還提供自己的開源控制臺實(shí)現(xiàn)——APISIX Dashboard，它提供了 APISIX 中最常用功能的可視化配置能力，可直接在界面上修改即可完成 API 的配置上下線。這與 APISIX Ingress Controller 提供的代碼即配置的思路有所不同，前者注重配置的靈活性，而后者注重規(guī)則定義的確定性。

同時在當(dāng)前最熱門的服務(wù)網(wǎng)格領(lǐng)域，APISIX 也在嘗試交出自己的答卷。APISIX 的服務(wù)網(wǎng)格項(xiàng)目 Amesh 現(xiàn)已經(jīng)開源，目前的方案使用 Istio 作為控制面實(shí)現(xiàn)，與 Envoy 一樣通過 xDS 協(xié)議與 Istio 通信，并將通信規(guī)則轉(zhuǎn)換為 APISIX 中的路由與上游配置。從而替換了 Istio + Envoy 組合中 Envoy 的流量網(wǎng)關(guān)角色。

APISIX 如何應(yīng)對應(yīng)用發(fā)展

現(xiàn)代應(yīng)用系統(tǒng)架構(gòu)已經(jīng)經(jīng)過多次發(fā)展，從單體應(yīng)用、多單體應(yīng)用+企業(yè)服務(wù)總線的 SOA 到現(xiàn)在的多微服務(wù)架構(gòu)演化。

當(dāng)單體應(yīng)用迭代到微服務(wù)后，微服務(wù)本身具有一定規(guī)模后，單純的微服務(wù)并不足以解決生產(chǎn)上面臨的問題。其伴隨的一個顯著特征就是，服務(wù)的數(shù)量在大幅增長，各個服務(wù)間的調(diào)用關(guān)系也變得更加復(fù)雜。

因此，在不同的階段其實(shí)大家都面臨著很多不同的技術(shù)選型。比如服務(wù)層面，我們可以用到像是 Apache、NGINX、HAProxy 這樣的反向代理工具。進(jìn)入到微服務(wù)時代我們又會用到像 NGINX 或是一些更加現(xiàn)代化的動態(tài) API 管理工具，這里又會因?yàn)榧夹g(shù)棧的不同擴(kuò)展出更多的產(chǎn)品。比如在 Java 語言側(cè)選擇 Zuul 或者 Spring Cloud Gateway 這樣的組件，在 Kubernetes 部署又會有 Ingress 等選擇。更進(jìn)一步到服務(wù)網(wǎng)格架構(gòu)中，又會產(chǎn)生 Istio + Envoy/MOSN 這種選擇。

各種技術(shù)手段浩如煙海，如何根據(jù)當(dāng)前企業(yè)、團(tuán)隊(duì)的狀況選擇最合適的架構(gòu)對架構(gòu)師的能力帶來很大的挑戰(zhàn)。

除了整體架構(gòu)上的選擇，隨著團(tuán)隊(duì)的擴(kuò)大和業(yè)務(wù)場景的復(fù)雜，對于開發(fā)者而言，需要了解和考慮的東西越來越多。這種情況下，各種各樣的流量比如 HTTP/TLS、gRPC、四層的 TCP/UDP、中間件的調(diào)用（比如 Redis 緩存）等等，對它們進(jìn)行統(tǒng)一的管理正是當(dāng)下應(yīng)用發(fā)展階段所面臨的困境。

APISIX 作為云原生 API 網(wǎng)關(guān)，為許多企業(yè)提供了一個更優(yōu)的選擇。在應(yīng)對各種不同場景時，APISIX 有著一些流量代理的用法。比如我們可以將 APISIX 作為一個 LB 來處理對外服務(wù)的負(fù)載均衡問題，同時也可以將其用作 API 網(wǎng)關(guān)來解決微服務(wù)的暴露與調(diào)用，利用 APISIX Ingress Controller 還可以解決容器中的 API 管理難題。

可以看到，使用 APISIX 可以為你在不同階段提供一個統(tǒng)一的、全流量的處理方式。那這種方式能為用戶帶來哪些收益呢？

• 對于研發(fā)人員來說，如果一個人掌握了 APISIX 這套體系的技術(shù)，他就可以很輕松地完成企業(yè)團(tuán)隊(duì)中各種不同領(lǐng)域的工作，比如在 API 網(wǎng)關(guān)或者 Ingress Controller 這種流量管理的落地場景。

• 對于運(yùn)維人員來說，使用 APISIX 后無論是后續(xù)維護(hù)現(xiàn)有環(huán)境還是切換到新的技術(shù)棧上，你都可以直接使用同一種工具和方法進(jìn)行直接管理，而無需再投入學(xué)習(xí)和時間成本。同時作為開源產(chǎn)品，學(xué)習(xí)之后還可以作為自身的技術(shù)積累復(fù)用到其他工作中，可謂是一舉多得。

• 對于公司來說，選用 APISIX 的架構(gòu)不僅僅可以滿足現(xiàn)有需求，還為將來的技術(shù)演進(jìn)預(yù)留下空間。比如當(dāng)下是為了滿足作為 LB 的需求，如果之后公司技術(shù)發(fā)展，將來也可以無縫過渡到 API 網(wǎng)關(guān)或者容器平臺乃至服務(wù)網(wǎng)格等領(lǐng)域。

展望：與 OpenSergo 的未來計(jì)劃

我們在上文中也提到了與其他社區(qū)的積極合作。在之前，OpenSergo 在 APISIX 社區(qū)項(xiàng)目倉庫的 issue 中曾發(fā)起討論，希望可以通過社區(qū)合作的方式，協(xié)商建立一個用于流量控制的統(tǒng)一標(biāo)準(zhǔn)，這引起了一部分社區(qū)成員的興趣。之后在一次 APISIX 社區(qū)的中文 Weekly Meeting 中，OpenSergo 社區(qū)的伙伴也為大家介紹了這一項(xiàng)目的愿景、思路和價值。

作為一個開放且包容的開源社區(qū)，APISIX 是非常歡迎這種社區(qū)間合作的，通過項(xiàng)目協(xié)同可以發(fā)揮出各自項(xiàng)目更大的價值。

具體來說，由于 OpenSergo 項(xiàng)目標(biāo)準(zhǔn)的表現(xiàn)形式主要為 Kubernetes CRD， 其用于云原生的容器環(huán)境中，因此可以優(yōu)先考慮將它與 APISIX Ingress Controller 項(xiàng)目進(jìn)行集成，為其增加 OpenSergo 的配置解析和處理模塊，將原始配置轉(zhuǎn)換為 APISIX 的內(nèi)置速率限制插件等。

這種做法有助于使用 Kubernetes 的用戶來增強(qiáng)其流量控制能力，并與其他各種上下游生態(tài)進(jìn)行集成，比如 RPC 框架。對于不使用 Kubernetes 的用戶，在目前產(chǎn)品現(xiàn)狀下，還缺少一個橋梁去完成 CRD 到 APISIX 插件的配置轉(zhuǎn)換。

因此，我們也有參考彼此產(chǎn)品的一些未來規(guī)劃。比如 OpenSergo 的文檔中提到，它們將發(fā)布專門的 SDK 供數(shù)據(jù)面組件調(diào)用以集成至 OpenSergo。如果有了 SDK 或是其他形式的接口，在接下來的日子里，有望看到 OpenSergo 與 APISIX 的集成項(xiàng)目。

最后，作為開源活躍項(xiàng)目，APISIX 社區(qū)也非常歡迎有興趣的伙伴來提交這些功能的實(shí)現(xiàn)，幫助項(xiàng)目的集成成為現(xiàn)實(shí)。相信通過開源間的合作，彼此項(xiàng)目都可以取得更大的成就。文章來源地址http://www.zghlxwxcb.cn/news/detail-452958.html

到了這里，關(guān)于開源浪潮下，Apache APISIX 如何成為全球最活躍 API 網(wǎng)關(guān)的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！