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

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

新增了 Consumer Group，可以更方便地管理消費者；

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

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

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

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

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

APISIX 3.0 新增亮點匯總

全面支持 ARM64

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

目前從數(shù)據(jù)來看，Arm 架構的服務器在性價比層面的表現(xiàn)略優(yōu)于 x86。為了順應時代技術潮流，APISIX 也在 ARM64 上做了全面的 CI 回歸。保證用戶在 Arm 架構中運行 APISIX 時，依舊可以順暢運行各種功能。

新增 gRPC 客戶端

在 3.0 版本中，將新增一個 core.grpc 模塊。如果你熟悉 NGINX 和 OpenResty 的話，就知道這兩者對于 gRPC 的支持相當有限，僅停留在執(zhí)行反向代理或負載均衡這樣的基礎功能上。

而 APISIX 在目前 2.x 版本中就已經實現(xiàn)了 gRPC 和 HTTP 協(xié)議的轉換。在 3.0 版本中，將通過新增 gRPC 客戶端的方式，允許開發(fā)者直接調?第三?的 gRPC 服務，?需引?額外的組件或要求服務提供?額外使? HTTP 接?，將使用過程大大簡捷化。

重新設計 Admin API

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

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

DP 和 CP 分離

APISIX 在最近一兩年內出現(xiàn)了多個安全相關的漏洞，大多數(shù)漏洞的根本原因都是因為 APISIX 在默認部署模式下，將數(shù)據(jù)面與控制面部署在一起了。一旦數(shù)據(jù)面上存在安全漏洞，攻擊者就可以通過數(shù)據(jù)面直接侵入控制面，從而影響到其他所有的數(shù)據(jù)面。

因此在 3.0 版本中，新增了部署模式配置 deployment，默認屬性為 traditional，也就是數(shù)據(jù)面與控制面部署在一起。當然，新配置模式還是更建議大家將屬性設置為 data_plane 或 control_plane，從而實現(xiàn)數(shù)據(jù)面與控制面的完全分離。

在完全分離后，不僅能解決上述安全隱患，還能更好地在數(shù)據(jù)面和控制面中分別進行功能的迭代而互不影響。

新增 AI 平面

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

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

對于只配置了身份認證等 Access 階段插件的 API，自動跳過 log 等不必要階段，加快處理速度。

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

更完善的服務發(fā)現(xiàn)支持

APISIX 在現(xiàn)版本中，已支持集成了很多服務發(fā)現(xiàn)組件，比如 Zookeeper、Consul、Nacos 等。但目前這些集成都是在數(shù)據(jù)面上完成的，一旦你的數(shù)據(jù)面節(jié)點非常多，這對于后續(xù)的服務發(fā)現(xiàn)組件壓力也是非常大的。

尤其是像 ETCD 和 ZooKeeper 這一類提供強一致性的組件，通常無法承受太大量的連接數(shù)；此外，用戶還需要為 Apache APISIX 數(shù)據(jù)面配置服務發(fā)現(xiàn)組件的認證，如果你在使用虛擬機部署 Apache APISIX，那么你需要將認證配置同步到每一個實例。

同時在用戶實際生產環(huán)境中，他們想要的不僅僅是一個簡單的類似于像 Consul KV 的集成或者是 DNS 的集成，而是更希望能做到類似健康檢查等更多完整功能的集成。

因此在 APISIX 3.0 中，我們通過新增一個子項目 APISIX-SEED 進行了一層抽象，實現(xiàn)了控制層面的服務發(fā)現(xiàn)支持，降低了對服務發(fā)現(xiàn)組件的壓力。后端服務的節(jié)點將由 APISIX-SEED 組件進行更新然后同步到 ETCD，最終被 Apache APISIX 所使用。

新增 xRPC 框架

APISIX 在現(xiàn)版本中支持代理 TCP 協(xié)議，但是有些時候，純粹的 TCP 協(xié)議代理是不夠的。用戶需要的是特定應用協(xié)議的代理，比如 Redis Proxy、Kafka Proxy 等。因為有些功能必須在對該協(xié)議進行編解碼之后才能實現(xiàn)。

因此，APISIX 在 3.0 版本中實現(xiàn)了一個名為 xRPC 的四層協(xié)議拓展框架，允許開發(fā)者在上面自定義特定的應用協(xié)議?；?xRPC，開發(fā)者可以通過 Lua 代碼對請求和響應進行編解碼，進而在了解協(xié)議內容的基礎上完成故障注入、日志上報、動態(tài)路由等功能的實現(xiàn)。

基于 xRPC 框架，APISIX 可以提供對若干主流應用協(xié)議的代理實現(xiàn)。同時用戶也可以基于該框架來支持自己私有的基于 TCP 的應用協(xié)議，使其具備類似 HTTP 協(xié)議代理的精準顆粒度的和更高階的七層控制。而在不同的協(xié)議之上，又可以去抽象一些共性因素，實現(xiàn)相關插件能力，讓不同的協(xié)議可以共享這些能力。

支持更多四層可觀測性

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

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

集成 OpenAPI 規(guī)范

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

因此，如果你是在一些 API 設計和測試的軟件上進行管理 API 的話，就可以非常方便地通過數(shù)據(jù)導出和導入，將其放置在 APISIX 中進行管理和維護。同時 APISIX 中的各種 API 也可以通過 OpenAPI 3.0 規(guī)范進行導出，然后再導入到其他系統(tǒng)中使用。

除此之外，在 3.0 版本中 APISIX 也支持了針對 Postman 相關自定義格式的支持（Postman Collection Format v2），實現(xiàn)兩者之間的數(shù)據(jù)傳輸，從而更方便地進行集成。

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

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

由于 Kubernetes Ingress 資源本身的限制，南北向場景中很多的流量管理能力無法被很好的表達出來，因此市場上大量的 Ingress Controller 解決方案都提供了自定義的 CRD，雖然這樣能很好地幫助用戶管理流量，但是卻間接提高了遷移的成本，幾乎導致用戶被某個 Ingress Controller 選型鎖定。因此 Kubernetes 社區(qū)在前兩年開始著手制定 Gateway API 這一標準。

Gateway API 是一個面向角色分層的協(xié)議，通常像 AWS、GCP 這樣的云廠商會充當基礎設施提供者，他們會提供若干種不同可選的網(wǎng)關選型（GatewayClass）；而網(wǎng)關管理員，通常會創(chuàng)建不同的網(wǎng)關實例（Gateway）；更上層的開發(fā)者則只聚焦于如何創(chuàng)建路由來暴露自己的 API，而不關心底層的網(wǎng)關細節(jié)。

這種情況下就可以通過 APISIX Ingress 去使用 Gateway API 的方式進行各種配置，也就意味著你能夠在各個不同的數(shù)據(jù)面進行切換。在今年年底，APISIX Ingress 將更加完整地支持 Gateway API 以及支持在四層和七層的更多能力。

與大多數(shù)服務網(wǎng)格方案不同，APISIX 的服務網(wǎng)格方案更有優(yōu)勢的地方是數(shù)據(jù)面（得益于 APISIX 本身的高性能），因此在控制面的選擇上，更希望去兼容一些社區(qū)上已有的主流方案。最終采取了通過使用 xDS 協(xié)議與 Istio 進行交互，并將獲取到的配置寫入到 APISIX 的 xDS 配置中心的方式，來配合 APISIX 生成具體的路由規(guī)則，完成對應請求的路由。

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

集成更多生態(tài)

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

其中一個有趣的插件 workflow 是關于流量調度的， 通過該插件就可以在流量控制層面進行一些更細粒度的處理。

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

總 結

不管是 APISIX 從零開始發(fā)展到現(xiàn)在，還是已經推出的 3.0 正式版本，你會發(fā)現(xiàn) APISIX 其實并沒有在架構層面進行太多的調整與改動，更多的是進行生態(tài)、兼容性和產品應用層面的改變。

一個開源項目的評判標準，或許并不只有性能和功能，而是需要更多站在用戶、開發(fā)者和企業(yè)的角度，去考慮他們使用這個產品是否可以快速有效地解決當下的痛點。

而本文中提到的亮點或者新特性，其實都是通過開源社區(qū)的大環(huán)境，接收了來自不同開發(fā)者或者企業(yè)用戶的反饋而打造出來的，是他們讓開源產品更加實用和充滿活力。

審核編輯 ：李倩