API 網(wǎng)關(guān)作為一個(gè)存在時(shí)間比較長(zhǎng)的基礎(chǔ)組件，一直致力于提供業(yè)務(wù)層面的限流限速、身份認(rèn)證、可觀測(cè)性等多方面的功能。
隨著服務(wù)端系統(tǒng)的迭代，越來(lái)越多的服務(wù)開始從裸金屬遷移到了 K8s 中，原來(lái)的單體架構(gòu)也逐漸進(jìn)化為微服務(wù)架構(gòu)，同時(shí)企業(yè)也開始將一些私有化機(jī)房部署到多云和混合云場(chǎng)景中來(lái)。
隨著這些大環(huán)境的技術(shù)變更，業(yè)務(wù)層面對(duì)于 API 網(wǎng)關(guān)的需求也開始逐漸復(fù)雜。
API 網(wǎng)關(guān) Apache APISIX
Apache APISIX 在產(chǎn)品誕生之際，就希望能夠在云原生和微服務(wù)的技術(shù)環(huán)境下，幫助企業(yè)解決一些新的問(wèn)題。比如通過(guò)全動(dòng)態(tài)特性將業(yè)務(wù)的流量進(jìn)行自動(dòng)擴(kuò)縮容、通過(guò)一次性修改進(jìn)行更方便地集群化管理等。
因此 APISIX 在架構(gòu)設(shè)計(jì)上，就采取了數(shù)據(jù)面與控制面分離的模式，實(shí)現(xiàn)了全動(dòng)態(tài)和集群化管理，這些都主要得益于 etcd 組件的作用。
APISIX 會(huì)將相關(guān)的路由配置和插件配置等都放置在 etcd 內(nèi)進(jìn)行存儲(chǔ)和管理。如上圖所示，右側(cè)控制面（Control Plane）的數(shù)據(jù)都存放在 etcd 中，而左側(cè)的數(shù)據(jù)面（Data Plane）則主要是監(jiān)聽 etcd 的變更，快速感知其變化，無(wú)需修改其他配置文件。
但是只解決了這些問(wèn)題還是不夠的。作為對(duì)上下游都有承接需求的中間件來(lái)說(shuō)，API 網(wǎng)關(guān)大多數(shù)時(shí)候都是在企業(yè)架構(gòu)中起到了流量入口和承上啟下的關(guān)鍵位置。這個(gè)位置就決定了它不會(huì)像數(shù)據(jù)庫(kù)一樣，只接收來(lái)自用戶業(yè)務(wù)層面的需求。
除了業(yè)務(wù)層面需求外，API 網(wǎng)關(guān)也會(huì)存在類似二次開發(fā)這種定制或集成需求。如何讓開發(fā)者在使用 APISIX 時(shí)能更輕松地實(shí)現(xiàn)自定義開發(fā)，這就是 APISIX 解決的第三個(gè)痛點(diǎn)，即讓開發(fā)者的使用門檻降得足夠低。
在 APISIX 里，插件的開發(fā)主要是通過(guò) Lua 語(yǔ)言來(lái)完成，通過(guò) LuaJIT 去保證編譯后的代碼性能足夠好。但 Lua 作為一個(gè)相對(duì)小眾的語(yǔ)言，對(duì)絕大部分后端工程師而言學(xué)習(xí)成本略高。為此，APISIX 通過(guò)兩種方式來(lái)解決這個(gè)問(wèn)題。
第一種方式就是通過(guò) Runner Plugin 來(lái)支持更多的主流開發(fā)語(yǔ)言，比如 JAVA、Python/ target=_blank class=infotextkey>Python、Go 等。如果你是一個(gè)后端工程師，至少應(yīng)該會(huì)其中一種語(yǔ)言，那么這個(gè)時(shí)候你就可以非常方便地通過(guò)本地 RPC 通信，使用你之前熟悉的計(jì)算語(yǔ)言去開發(fā)一個(gè) APISIX 插件。
這樣做的好處是減少了開發(fā)成本，提高了開發(fā)效率。當(dāng)然弊端就是在性能層面有一些損失。那么，有沒(méi)有一種既能達(dá)到 Lua 原生性能，同時(shí)又兼顧高級(jí)語(yǔ)言的開發(fā)效率方案呢？
這里就引出了第二種方式，也就是上圖左側(cè)部分。WebAssembly 最早是用在前端或?yàn)g覽器上的一個(gè)技術(shù)，在服務(wù)端它也逐漸展示出來(lái)它的優(yōu)勢(shì)。
把 WebAssembly 嵌入到了 APISIX 里，用戶就可以使用 WebAssembly 去編譯成 WebAssembly 的字節(jié)碼在 APISIX 中運(yùn)行。最終達(dá)到的效果就是利用高效率，開發(fā)出了一個(gè)既有高性能又使用高級(jí)計(jì)算語(yǔ)言編寫的 APISIX 插件。
所以在目前的 APISIX 版本中，用戶可以使用 Lua、Go、Python 和 Wasm 等多種方式，基于 APISIX 編寫自定義代碼。通過(guò)這樣的方式，降低了開發(fā)者的使用門檻，也為 APISIX 的功能提供了更多的可能性。
得益于 APISIX 的架構(gòu)和性能優(yōu)勢(shì)，從誕生到現(xiàn)在三年多的時(shí)間內(nèi)，APISIX 在全球范圍內(nèi)的用戶發(fā)展速度遠(yuǎn)超預(yù)期。比如 wps、新浪微博、愛奇藝等國(guó)內(nèi)大廠，這些都是每天承載幾百億次 API 調(diào)用的企業(yè)用戶。在海外也有像 NASA、歐盟數(shù)字工廠、瑞士電信等類似科研機(jī)構(gòu)領(lǐng)域的用戶在使用。
APISIX 3.0 新增的 10 大亮點(diǎn)
APISIX 在 2022 年初就提出了全新的 3.0 Roadmap，在 3.0 版本中將重點(diǎn)在易用性和生態(tài)系統(tǒng)等方面進(jìn)行迭代與更新。
目前 APISIX 已正式推出 3.0 預(yù)覽版，在此也選取了如下十個(gè)亮眼功能，進(jìn)行一個(gè)簡(jiǎn)單的功能介紹。
1.全面支持 ARM64
目前 ARM64 對(duì)于云廠商來(lái)說(shuō)，已成為一個(gè)非常主流的服務(wù)器架構(gòu)選型。從 AWS Graviton、GCP Tau T2A 再到華為鯤鵬等系列產(chǎn)品，可以看到各家云廠商都開始推出了基于 Arm 架構(gòu)的服務(wù)器。
目前從數(shù)據(jù)來(lái)看，Arm 架構(gòu)的服務(wù)器在性價(jià)比層面的表現(xiàn)略優(yōu)于 x86。為了順應(yīng)時(shí)代技術(shù)潮流，APISIX 也在 ARM64 上做了全面的 CI 回歸。保證用戶在 Arm 架構(gòu)中運(yùn)行 APISIX 時(shí)，依舊可以順暢運(yùn)行各種功能。
2.新增 gRPC 客戶端
在 3.0 版本中，將新增一個(gè) core.grpc 模塊。如果你熟悉 Nginx 和 OpenResty 的話，就知道這兩者對(duì)于 gRPC 的支持相當(dāng)有限，僅停留在執(zhí)行反向代理或負(fù)載均衡這樣的基礎(chǔ)功能上。
而 APISIX 在目前 2.x 版本中就已經(jīng)實(shí)現(xiàn)了 gRPC 和 HTTP 協(xié)議的轉(zhuǎn)換。在 3.0 版本中，將通過(guò)新增 gRPC 客戶端的方式，允許開發(fā)者直接調(diào)?第三?的 gRPC 服務(wù)，?需引?額外的組件或要求服務(wù)提供?額外使? HTTP 接?，將使用過(guò)程大大簡(jiǎn)捷化。
3.重新設(shè)計(jì) Admin API
目前在使用 APISIX 時(shí)，你可能會(huì)發(fā)現(xiàn) APISIX 的響應(yīng)體中摻雜了很多沒(méi)有意義的數(shù)據(jù)，比如一些 etcd 的返回值，沒(méi)有進(jìn)行任何剪裁就直接傳送給了客戶端。同時(shí)目前整個(gè)響應(yīng)體的架構(gòu)設(shè)計(jì)也并不完善，存在一些冗余字段。
在 APISIX 3.0 版本中，重新設(shè)計(jì)了響應(yīng)體結(jié)構(gòu)，新的格式可以讓整個(gè)請(qǐng)求格式和返回體都更加的 Restful 化，從而讓用戶更加方便地使用新版本的 Admin API。當(dāng)然該過(guò)程也允許通過(guò)參數(shù)來(lái)控制使用哪個(gè)版本的 Admin API，不用害怕升級(jí)后兼容不了之前的版本。
4.DP 和 CP 分離
APISIX 在最近一兩年內(nèi)出現(xiàn)了多個(gè)安全相關(guān)的漏洞，大多數(shù)漏洞的根本原因都是因?yàn)?APISIX 在默認(rèn)部署模式下，將數(shù)據(jù)面與控制面部署在一起了。一旦數(shù)據(jù)面上存在安全漏洞，攻擊者就可以通過(guò)數(shù)據(jù)面直接侵入控制面，從而影響到其他所有的數(shù)據(jù)面。
因此在 3.0 版本中，新增了部署模式配置deployment，默認(rèn)屬性為traditional，也就是數(shù)據(jù)面與控制面部署在一起。當(dāng)然，新配置模式還是更建議大家將屬性設(shè)置為data_plane或control_plane，從而實(shí)現(xiàn)數(shù)據(jù)面與控制面的完全分離。
在完全分離后，不僅能解決上述安全隱患，還能更好地在數(shù)據(jù)面和控制面中分別進(jìn)行功能的迭代而互不影響。
5.更完善的服務(wù)發(fā)現(xiàn)支持
APISIX 在現(xiàn)版本中，已支持集成了很多服務(wù)發(fā)現(xiàn)組件，比如 Zookeeper、Consul、Nacos 等。但目前這些集成都是在數(shù)據(jù)面上完成的，一旦你的數(shù)據(jù)面節(jié)點(diǎn)非常多，這對(duì)于后續(xù)的服務(wù)發(fā)現(xiàn)組件壓力也是非常大的。尤其是像 etcd 和 ZooKeeper 這一類提供強(qiáng)一致性的組件，通常無(wú)法承受太大量的連接數(shù)；此外，用戶還需要為 Apache APISIX 數(shù)據(jù)面配置服務(wù)發(fā)現(xiàn)組件的認(rèn)證，如果你在使用虛擬機(jī)部署 Apache APISIX，那么你需要將認(rèn)證配置同步到每一個(gè)實(shí)例。
同時(shí)在用戶實(shí)際生產(chǎn)環(huán)境中，他們想要的不僅僅是一個(gè)簡(jiǎn)單的類似于像 Consul KV 的集成或者是 DNS 的集成，而是更希望能做到類似健康檢查等更多完整功能的集成。
因此在 APISIX 3.0 中，我們通過(guò)新增一個(gè)子項(xiàng)目APISIX-SEED進(jìn)行了一層抽象，實(shí)現(xiàn)了控制層面的服務(wù)發(fā)現(xiàn)支持，降低了對(duì)服務(wù)發(fā)現(xiàn)組件的壓力。后端服務(wù)的節(jié)點(diǎn)將由APISIX-SEED組件進(jìn)行更新然后同步到 etcd，最終被 Apache APISIX 所使用。
6.新增 xRPC 框架
APISIX 在現(xiàn)版本中支持代理 TCP 協(xié)議，但是有些時(shí)候，純粹的 TCP 協(xié)議代理是不夠的。用戶需要的是特定應(yīng)用協(xié)議的代理，比如 redis Proxy、Kafka Proxy 等。因?yàn)橛行┕δ鼙仨氃趯?duì)該協(xié)議進(jìn)行編解碼之后才能實(shí)現(xiàn)。
因此，APISIX 在 3.0 版本中實(shí)現(xiàn)了一個(gè)名為 xRPC 的四層協(xié)議拓展框架，允許開發(fā)者在上面自定義特定的應(yīng)用協(xié)議。基于 xRPC，開發(fā)者可以通過(guò) Lua 代碼對(duì)請(qǐng)求和響應(yīng)進(jìn)行編解碼，進(jìn)而在了解協(xié)議內(nèi)容的基礎(chǔ)上完成故障注入、日志上報(bào)、動(dòng)態(tài)路由等功能的實(shí)現(xiàn)。
基于 xRPC 框架，APISIX 可以提供對(duì)若干主流應(yīng)用協(xié)議的代理實(shí)現(xiàn)。同時(shí)用戶也可以基于該框架來(lái)支持自己私有的基于 TCP 的應(yīng)用協(xié)議，使其具備類似 HTTP 協(xié)議代理的精準(zhǔn)顆粒度的和更高階的七層控制。而在不同的協(xié)議之上，又可以去抽象一些共性因素，實(shí)現(xiàn)相關(guān)插件能力，讓不同的協(xié)議可以共享這些能力。
7.支持更多四層可觀測(cè)性
APISIX 在可觀測(cè)性的功能支持上一直都投入很多，幾乎支持了所有的可觀測(cè)性組件，比如 Zipkin、Apache SkyWalking、Datadog 等等。同時(shí)還支持了各種各樣的日志組件，但這些大多都是在七層（應(yīng)用層）進(jìn)行的。
在 APISIX 3.0 版本中將會(huì)增加更多基于四層（傳輸層）的可觀測(cè)性支持。比如增加了四層上對(duì)于 Prometheus 和各種日志的支持，不僅可以讓用戶非常輕松地觀測(cè)到七層流量中哪里出了問(wèn)題，也可以去發(fā)現(xiàn)四層的流量運(yùn)作狀況。
8.集成 OpenAPI 規(guī)范
API 其實(shí)是一個(gè)涉及從開發(fā)、測(cè)試、上線到整個(gè)全生命周期的元素。在 APISIX 3.0 版本中，將支持標(biāo)準(zhǔn)的 OpenAPI 3.0 規(guī)范。
因此，如果你是在一些 API 設(shè)計(jì)和測(cè)試的軟件上進(jìn)行管理 API 的話，就可以非常方便地通過(guò)數(shù)據(jù)導(dǎo)出和導(dǎo)入，將其放置在 APISIX 中進(jìn)行管理和維護(hù)。同時(shí) APISIX 中的各種 API 也可以通過(guò) OpenAPI 3.0 規(guī)范進(jìn)行導(dǎo)出，然后再導(dǎo)入到其他系統(tǒng)中使用。
除此之外，在 3.0 版本中 APISIX 也支持了針對(duì) Postman 相關(guān)自定義格式的支持（Postman Collection Format v2），實(shí)現(xiàn)兩者之間的數(shù)據(jù)傳輸，從而更方便地進(jìn)行集成。
9.Gateway API 的全面支持和服務(wù)網(wǎng)格
在 APISIX Ingress 的版本迭代中，已開始對(duì) Gateway API 進(jìn)行支持，最新的 1.5 版本中已基本支持了所有的 Gateway API 配置。
由于 Kube.NETes Ingress 資源本身的限制，南北向場(chǎng)景中很多的流量管理能力無(wú)法被很好的表達(dá)出來(lái)，因此市場(chǎng)上大量的 Ingress Controller 解決方案都提供了自定義的 CRD，雖然這樣能很好地幫助用戶管理流量，但是卻間接提高了遷移的成本，幾乎導(dǎo)致用戶被某個(gè) Ingress Controller 選型鎖定。因此 Kubernetes 社區(qū)在前兩年開始著手制定 Gateway API 這一標(biāo)準(zhǔn)。
Gateway API 是一個(gè)面向角色分層的協(xié)議，通常像 AWS、GCP 這樣的云廠商會(huì)充當(dāng)基礎(chǔ)設(shè)施提供者，他們會(huì)提供若干種不同可選的網(wǎng)關(guān)選型（GatewayClass）；而網(wǎng)關(guān)管理員，通常會(huì)創(chuàng)建不同的網(wǎng)關(guān)實(shí)例（Gateway）；更上層的開發(fā)者則只聚焦于如何創(chuàng)建路由來(lái)暴露自己的 API，而不關(guān)心底層的網(wǎng)關(guān)細(xì)節(jié)。
這種情況下就可以通過(guò) APISIX Ingress 去使用 Gateway API 的方式進(jìn)行各種配置，也就意味著你能夠在各個(gè)不同的數(shù)據(jù)面進(jìn)行切換。在今年年底，APISIX Ingress 將更加完整地支持 Gateway API 以及支持在四層和七層的更多能力。
與大多數(shù)服務(wù)網(wǎng)格方案不同，APISIX 的服務(wù)網(wǎng)格方案更有優(yōu)勢(shì)的地方是數(shù)據(jù)面（得益于 APISIX 本身的高性能），因此在控制面的選擇上，更希望去兼容一些社區(qū)上已有的主流方案。最終采取了通過(guò)使用 xDS 協(xié)議與 Istio 進(jìn)行交互，并將獲取到的配置寫入到 APISIX 的 xDS 配置中心的方式，來(lái)配合 APISIX 生成具體的路由規(guī)則，完成對(duì)應(yīng)請(qǐng)求的路由。
這種方案不僅可以讓整個(gè)服務(wù)網(wǎng)格更加輕量，同時(shí)借助于 APISIX 的高拓展性，也可以進(jìn)行更方便地二次開發(fā)與遷移。
10.集成更多生態(tài)
除了上文提到的 OpenAPI 標(biāo)準(zhǔn)之外，3.0 版本中也會(huì)新增非常多的生態(tài)插件，比如 OpenFunction、ClickHouse、Elasticsearch、SAML 和 CAS 等，去集成更對(duì)關(guān)于認(rèn)證鑒權(quán)、安全或者可觀測(cè)性等。
其中一個(gè)有趣的插件workflow是關(guān)于流量調(diào)度的， 通過(guò)該插件就可以在流量控制層面進(jìn)行一些更細(xì)粒度的處理。
比如當(dāng)條件 A 成立時(shí)執(zhí)行某個(gè)行為，條件 B 成立時(shí)執(zhí)行另一個(gè)行為等。通過(guò)這種更加清晰的方式，讓用戶更加方便地調(diào)度各種業(yè)務(wù)流量。
總結(jié)
不管是 APISIX 從零開始發(fā)展到現(xiàn)在，還是已經(jīng)推出預(yù)覽版的 3.0 版本，你會(huì)發(fā)現(xiàn) APISIX 其實(shí)并沒(méi)有在架構(gòu)層面進(jìn)行太多的調(diào)整與改動(dòng)，更多的是進(jìn)行生態(tài)、兼容性和產(chǎn)品應(yīng)用層面的改變。
一個(gè)開源項(xiàng)目的評(píng)判標(biāo)準(zhǔn)，或許并不只有性能和功能，而是需要更多站在用戶、開發(fā)者和企業(yè)的角度，去考慮他們使用這個(gè)產(chǎn)品是否可以快速有效地解決當(dāng)下的痛點(diǎn)。
而本文中提到的亮點(diǎn)或者新特性，其實(shí)都是通過(guò)開源社區(qū)的大環(huán)境，接收了來(lái)自不同開發(fā)者或者企業(yè)用戶的反饋而打造出來(lái)的，是他們讓開源產(chǎn)品更加實(shí)用和充滿活力。
最后，也歡迎大家對(duì) APISIX 3.0 預(yù)覽版進(jìn)行體驗(yàn)和反饋，期待技術(shù)與社區(qū)所迸發(fā)的技術(shù)魅力。
