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

在 9 月底，Apache APISIX 發(fā)布了 3.0.0-beta 預(yù)覽版，為用戶們提前帶來(lái)了一些新的功能體驗(yàn)。今天，APISIX 正式發(fā)布了 3.0.0 版本，將產(chǎn)品從體驗(yàn)和功能角度，帶到了新一輪的進(jìn)程中。經(jīng)過(guò)迭代的 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)。可以說(shuō)這次的版本迭代，真正做到了“性能更強(qiáng)更智能，生態(tài)更廣更多樣”。

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

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

全面支持 ARM64

目前 ARM64 對(duì)于云廠商來(lái)說(shuō)，已成為一個(gè)非常主流的服務(wù)器架構(gòu)選型。從 AWS Graviton、GCP Tau T2A 再到華為鯤鵬等系列產(chǎn)品，可以看到各家云廠商都開(kāi)始推出了基于 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)行各種功能。

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

重新設(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í)后兼容不了之前的版本。

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)行功能的迭代而互不影響。

新增 AI 平面

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

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

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

AI 平面給流量處理帶來(lái)了新的可能性，在后續(xù)使用過(guò)程中，類似上游服務(wù)自動(dòng)熱身、安全威脅發(fā)現(xiàn)等都可以通過(guò) AI 平面來(lái)進(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)一致性的組件，通常無(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 所使用。

新增 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é)議拓展框架，允許開(kāi)發(fā)者在上面自定義特定的應(yīng)用協(xié)議。基于 xRPC，開(kāi)發(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é)議可以共享這些能力。

支持更多四層可觀測(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)作狀況。

集成 OpenAPI 規(guī)范

API 其實(shí)是一個(gè)涉及從開(kāi)發(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)行集成。

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

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

由于 Kubernetes Ingress 資源本身的限制，南北向場(chǎng)景中很多的流量管理能力無(wú)法被很好的表達(dá)出來(lái)，因此市場(chǎng)上大量的 Ingress Controller 解決方案都提供了自定義的 CRD，雖然這樣能很好地幫助用戶管理流量，但是卻間接提高了遷移的成本，幾乎導(dǎo)致用戶被某個(gè) Ingress Controller 選型鎖定。因此 Kubernetes 社區(qū)在前兩年開(kāi)始著手制定 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）；更上層的開(kāi)發(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)行更方便地二次開(kāi)發(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)、安全或者可觀測(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 從零開(kāi)始發(fā)展到現(xiàn)在，還是已經(jīng)推出的 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è)開(kāi)源項(xiàng)目的評(píng)判標(biāo)準(zhǔn)，或許并不只有性能和功能，而是需要更多站在用戶、開(kāi)發(fā)者和企業(yè)的角度，去考慮他們使用這個(gè)產(chǎn)品是否可以快速有效地解決當(dāng)下的痛點(diǎn)。

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

審核編輯 ：李倩