作為開源的云原生 API 網(wǎng)關(guān)，Apache APISIX 致力于在性能和使用體驗(yàn)上為開發(fā)者和用戶們帶來更好更優(yōu)異的表現(xiàn)，幫助企業(yè)解決一些關(guān)于云原生和微服務(wù)技術(shù)下遇到的新問題。

在 9 月底，Apache APISIX 發(fā)布了 3.0.0-beta 預(yù)覽版，為用戶們提前帶來了一些新的功能體驗(yàn)。今天，APISIX 正式發(fā)布了 3.0.0 版本，將產(chǎn)品從體驗(yàn)和功能角度，帶到了新一輪的進(jìn)程中。經(jīng)過迭代的 3.0.0 正式版與此前 3.0.0-beta 預(yù)覽版相比：

新增了 Consumer Group，可以更方便地管理消費(fèi)者；

支持配置 DNS 解析域名類型的順序；

新增 AI 平面，更智能化地對(duì)配置與流量進(jìn)行分析與呈現(xiàn)；

對(duì)多個(gè)現(xiàn)有生態(tài)插件進(jìn)行更細(xì)致的優(yōu)化。

除了以上技術(shù)層面的細(xì)節(jié)改動(dòng)外，還有很多新的功能特性與生態(tài)擴(kuò)展細(xì)節(jié)均在下文中為大家呈現(xiàn)。可以說這次的版本迭代，真正做到了“性能更強(qiáng)更智能，生態(tài)更廣更多樣”。

如果你想立刻體驗(yàn) APISIX 3.0 正式版本，可以即刻前往官網(wǎng)進(jìn)行下載與使用，也可點(diǎn)擊文末「閱讀原文」獲取最新版本。

APISIX 3.0 新增亮點(diǎn)匯總

全面支持 ARM64

目前 ARM64 對(duì)于云廠商來說，已成為一個(gè)非常主流的服務(wù)器架構(gòu)選型。從 AWS Graviton、GCP Tau T2A 再到華為鯤鵬等系列產(chǎn)品，可以看到各家云廠商都開始推出了基于 Arm 架構(gòu)的服務(wù)器。

目前從數(shù)據(jù)來看，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)行各種功能。

新增 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 版本中，將通過新增 gRPC 客戶端的方式，允許開發(fā)者直接調(diào)?第三?的 gRPC 服務(wù)，?需引?額外的組件或要求服務(wù)提供?額外使? HTTP 接?，將使用過程大大簡捷化。

重新設(shè)計(jì) Admin API

目前在使用 APISIX 時(shí)，你可能會(huì)發(fā)現(xiàn) APISIX 的響應(yīng)體中摻雜了很多沒有意義的數(shù)據(jù)，比如一些 etcd 的返回值，沒有進(jìn)行任何剪裁就直接傳送給了客戶端。同時(shí)目前整個(gè)響應(yīng)體的架構(gòu)設(shè)計(jì)也并不完善，存在一些冗余字段。

在 APISIX 3.0 版本中，重新設(shè)計(jì)了響應(yīng)體結(jié)構(gòu)，新的格式可以讓整個(gè)請求格式和返回體都更加的 Restful 化，從而讓用戶更加方便地使用新版本的 Admin API。當(dāng)然該過程也允許通過參數(shù)來控制使用哪個(gè)版本的 Admin API，不用害怕升級(jí)后兼容不了之前的版本。

DP 和 CP 分離

APISIX 在最近一兩年內(nèi)出現(xiàn)了多個(gè)安全相關(guān)的漏洞，大多數(shù)漏洞的根本原因都是因?yàn)?APISIX 在默認(rèn)部署模式下，將數(shù)據(jù)面與控制面部署在一起了。一旦數(shù)據(jù)面上存在安全漏洞，攻擊者就可以通過數(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)行功能的迭代而互不影響。

新增 AI 平面

在數(shù)據(jù)平面和控制平面之外，Apache APISIX 新增了 AI 平面。通過對(duì)于 API 流量和配置的學(xué)習(xí)與分析，減輕開發(fā)者和維護(hù)者的使用和運(yùn)維壓力。比如以下兩個(gè)場景就可以通過 AI 平面進(jìn)行自動(dòng)優(yōu)化：

發(fā)現(xiàn)沒有身份認(rèn)證的 API，并給出風(fēng)險(xiǎn)提示；

對(duì)于只配置了身份認(rèn)證等 Access 階段插件的 API，自動(dòng)跳過 log 等不必要階段，加快處理速度。

AI 平面給流量處理帶來了新的可能性，在后續(xù)使用過程中，類似上游服務(wù)自動(dòng)熱身、安全威脅發(fā)現(xiàn)等都可以通過 AI 平面來進(jìn)行處理。

更完善的服務(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)一致性的組件，通常無法承受太大量的連接數(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è)簡單的類似于像 Consul KV 的集成或者是 DNS 的集成，而是更希望能做到類似健康檢查等更多完整功能的集成。

因此在 APISIX 3.0 中，我們通過新增一個(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 所使用。

新增 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ā)者可以通過 Lua 代碼對(duì)請求和響應(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í)用戶也可以基于該框架來支持自己私有的基于 TCP 的應(yīng)用協(xié)議，使其具備類似 HTTP 協(xié)議代理的精準(zhǔn)顆粒度的和更高階的七層控制。而在不同的協(xié)議之上，又可以去抽象一些共性因素，實(shí)現(xiàn)相關(guān)插件能力，讓不同的協(xié)議可以共享這些能力。

支持更多四層可觀測性

APISIX 在可觀測性的功能支持上一直都投入很多，幾乎支持了所有的可觀測性組件，比如 Zipkin、Apache SkyWalking、Datadog 等等。同時(shí)還支持了各種各樣的日志組件，但這些大多都是在七層（應(yīng)用層）進(jìn)行的。

在 APISIX 3.0 版本中將會(huì)增加更多基于四層（傳輸層）的可觀測性支持。比如增加了四層上對(duì)于 Prometheus 和各種日志的支持，不僅可以讓用戶非常輕松地觀測到七層流量中哪里出了問題，也可以去發(fā)現(xiàn)四層的流量運(yùn)作狀況。

集成 OpenAPI 規(guī)范

API 其實(shí)是一個(gè)涉及從開發(fā)、測試、上線到整個(gè)全生命周期的元素。在 APISIX 3.0 版本中，將支持標(biāo)準(zhǔn)的 OpenAPI 3.0 規(guī)范。

因此，如果你是在一些 API 設(shè)計(jì)和測試的軟件上進(jìn)行管理 API 的話，就可以非常方便地通過數(shù)據(jù)導(dǎo)出和導(dǎo)入，將其放置在 APISIX 中進(jìn)行管理和維護(hù)。同時(shí) APISIX 中的各種 API 也可以通過 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)行集成。

Gateway API 的全面支持和服務(wù)網(wǎng)格

在 APISIX Ingress 的版本迭代中，已開始對(duì) Gateway API 進(jìn)行支持，最新的 1.5 版本中已基本支持了所有的 Gateway API 配置。

由于 Kubernetes Ingress 資源本身的限制，南北向場景中很多的流量管理能力無法被很好的表達(dá)出來，因此市場上大量的 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)建路由來暴露自己的 API，而不關(guān)心底層的網(wǎng)關(guān)細(xì)節(jié)。

這種情況下就可以通過 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ù)據(jù)面（得益于 APISIX 本身的高性能），因此在控制面的選擇上，更希望去兼容一些社區(qū)上已有的主流方案。最終采取了通過使用 xDS 協(xié)議與 Istio 進(jìn)行交互，并將獲取到的配置寫入到 APISIX 的 xDS 配置中心的方式，來配合 APISIX 生成具體的路由規(guī)則，完成對(duì)應(yīng)請求的路由。

這種方案不僅可以讓整個(gè)服務(wù)網(wǎng)格更加輕量，同時(shí)借助于 APISIX 的高拓展性，也可以進(jìn)行更方便地二次開發(fā)與遷移。

集成更多生態(tài)

除了上文提到的 OpenAPI 標(biāo)準(zhǔn)之外，3.0 版本中也會(huì)新增非常多的生態(tài)插件，比如 OpenFunction、ClickHouse、Elasticsearch、SAML 和 CAS 等，去集成更對(duì)關(guān)于認(rèn)證鑒權(quán)、安全或者可觀測性等。

其中一個(gè)有趣的插件 workflow 是關(guān)于流量調(diào)度的， 通過該插件就可以在流量控制層面進(jìn)行一些更細(xì)粒度的處理。

比如當(dāng)條件 A 成立時(shí)執(zhí)行某個(gè)行為，條件 B 成立時(shí)執(zhí)行另一個(gè)行為等。通過這種更加清晰的方式，讓用戶更加方便地調(diào)度各種業(yè)務(wù)流量。

總 結(jié)

不管是 APISIX 從零開始發(fā)展到現(xiàn)在，還是已經(jīng)推出的 3.0 正式版本，你會(huì)發(fā)現(xiàn) APISIX 其實(shí)并沒有在架構(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í)都是通過開源社區(qū)的大環(huán)境，接收了來自不同開發(fā)者或者企業(yè)用戶的反饋而打造出來的，是他們讓開源產(chǎn)品更加實(shí)用和充滿活力。

審核編輯 ：李倩