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