本文將從云原生時代的機遇和挑戰(zhàn)說起，介紹一個全新的開源高性能云原生 API 網關——Apache APISIX，探討如何解決云原生時代 API 網關所面臨的一些痛點，最后介紹該開源項目未來的規(guī)劃。

背景

云原生的機遇和挑戰(zhàn)

很多應用和服務都在向微服務、容器化遷移，形成新的云原生時代。云原生是下一個 5-10 年的技術顛覆，重寫了傳統企業(yè)的技術架構，例如云原生中的 Kubernetes 顛覆了傳統操作系統，所有的“主機”（node 上的容器）由 Kubernetes 來控制和編排，非常適用于公有云、私有云、混合云等各種環(huán)境。云原生體系的特點之一就是由各種開源項目組成，不同于以往的商業(yè)閉源項目，緩解了收費貴等問題，加速了技術落地。現代公司的技術是非常重要的組成部分，在一個商業(yè)競爭激烈的時代，公司愈早的占據技術頂峰愈是能夠占據商業(yè)頂峰。網關作為云原生入口，是掌握云原生的一個必經之地，是開啟“財富”的關鍵鑰匙。

微服務的演進

從 2014-2015 年，谷歌搜索引擎上“微服務”關鍵字的搜索趨勢呈直線上升。

在單體架構上，任一請求都會負載到整個的單體服務集群上。

在微服務架構上，對應請求會負載到微服務中對應的的子服務集群上。

使用微服務進行精細管理后，服務的彈性伸縮、開發(fā)團隊變得敏捷、服務之間隔離、降低故障率；在流量變動的時候，只需要對有可能變動流量的服務進行對應資源的擴縮容即可，這樣可以很明顯的節(jié)省服務器成本以及更高的承受度；在業(yè)務變動的時候，只需要對有可能變動業(yè)務的服務進行對應業(yè)務模塊的變動即可，這樣可以很明顯的節(jié)省人力成本以及更高的控制力；在出現故障時不會導致整體服務不可用。

但是落地微服務同樣的帶來了一些問題，比如接口之間通用的功能重復開發(fā)、膨脹的服務數量、難以管理。通常的解決方案便是使用 API 網關對其進行管理。

微服務與 API 網關

使用 API 網關進行管理，通常的做法是將微服務框架中功能型的功能統一放到網關上，例如可觀測性 metrics、應用性能 apm tracing、限速、身份認證、日志等等。

灰度發(fā)布

灰度發(fā)布也叫金絲雀發(fā)布，起源是，礦井工人發(fā)現，金絲雀對瓦斯氣體很敏感，礦工會在下井之前，先放一只金絲雀到井中，如果金絲雀不叫了，就代表瓦斯?jié)舛雀?。灰度發(fā)布會將流量按比例劃分給已經上線的版本（比如1.0，占比90%）以及正在上線的版本（比如1.01，占比10%），若觀測沒有問題，逐步調整二者的流量占比直到流量完全切到1.01版本。Apache APISIX 內置的灰度發(fā)布支持讀取到的 HTTP 請求參數中包含了 Nginx 的所有變量，可以依據變量進行灰度，甚至支持 LUA 代碼去運算處理請求的請求體、請求參數。

服務熔斷

如圖所示，當 Invoices 服務出現大量常見錯誤達到配置的熔斷閾值就可以直接熔斷不接收請求了。

Apache APISIX 在傳統和云原生領域的支持粒度

| 作用在傳統API網關領域的功能 | 作用在云原生API網關領域的功能 | | ------------------------------------------------------------ | ------------------------------------------------------------ | | 讓 API 請求更安全、更高效的得到處理；覆蓋 Nginx 的所有功能：反向代理、負載均衡；動態(tài)上游、動態(tài) SSL 證書、動態(tài)限流限速；主動/被動健康檢查、服務熔斷 | 對接 Prometheus、Zipkin、Skywalking；gRPC 代理和協議轉換 (REST <-> gRPC)；身份認證：OpenID Relying Party、OP（Auth0、okta……）高性能、無狀態(tài)、隨意擴容和縮容動態(tài)配置，不用 reload 服務支持多云、混合云容器優(yōu)先，Kubernetes 友好 |

API 生命周期管理全景圖

API 生命周期指的是從 API 的設計到 API 的文檔和他的 SDK 以及他的 API 的上線之類，甚至還包括 API 的市場等等一整套的解決方案，網關在其中是核心角色。

在上半象限都是一些巨頭公司，例如 google、IBM 等等，都是公有云的閉源項目，具有領導地位，跟各自產品深度綁定在一起。在下半象限都是援建者，都是開源項目，例如: Kong，挑戰(zhàn)著閉源項目, 隨著時間的推移我們發(fā)現——軟件在吞噬世界、開源軟件在吞噬軟件。以下是近幾年發(fā)生的很多 API 網關廠商相關的收購案例：

2015 年，IBM 收購 StrongLoop
2015 年，谷歌 6.25 億美元收購 apigee
2018 年，Salesforce 65 億美元收購 MuleSoft
2018 年，Broadcom 189 億美元收購 CA Technologies
2019 年，F5 收購 6.7 億美元收購 NGINX

說明 API 網關在云原生時代依然扮演者重要的角色

深入淺出 Apache APISIX

設計思路

API 網關的數據面和控制面分離。控制面不僅能控制 Apache APISIX 還能控制其他組件；數據面不僅僅能被我的控制面控制，還能被其他組件所控制

通過插件機制來方便二次開發(fā)和運維。拿 Envoy 來說，Envoy 的插件是使用 C++ 編寫的，C++ 本身就具有很大的復雜性；再來對比下 Kong，Kong 開發(fā)一個 IP 黑白名單插件需要寫 300+ 行代碼，并且插件配置解析、插件邏輯等代碼分布在 3-4 個文件中；而 Apache APISIX 開發(fā)同樣功能的插件只需要一個文件并且只需要70行代碼。

默認高可用，沒有單點故障。因為使用了 ETCD 來存儲和分發(fā)路由數據

安全和穩(wěn)定第一。Apache APISIX 基于 Nginx 實現，支持mTLS 認證以及敏感信息加密加鹽 (salt) 保存。為什么選擇 Nginx 呢？它是基于 C 語言開發(fā)的程序，性能優(yōu)化到極致，Nginx 的底層開發(fā)做的非常好，并且在大規(guī)模適用上得到充分有效的驗證，從性能角度上是最佳選擇

高性能。Apache APISIX 基于 Nginx 的網絡層，其單核心 QPS 1.5 萬，延遲低于 0.7 毫秒。

運維友好。它支持 Prometheus、SkyWalking 動態(tài)追蹤、流量復制、故障注入等功能

技術架構

Apache APISIX 架構如圖，其主要分為數據面和控制面。

數據面：以 Nginx 的網絡庫為基礎，（棄用 Nginx 的路由匹配、靜態(tài)配置和 C 模塊），使用 Lua 和 Nginx 動態(tài)控制請求流量，通過插件機制來實現各種流量處理和分發(fā)的功能：限流限速、日志記錄、安全檢測、故障注入等，同時支持用戶編寫自定義插件來對數據面進行擴充。
控制面：使用 etcd 來存儲和同步網關的配置數據，管理員通過 admin API 或者 dashboard 可以在毫秒級別內通知到所有的數據面節(jié)點，同時 etcd 集群也保證了系統的高可用。

因為 Apache APISIX 使用了 ETCD 作為配置中心，在對應其他組件時會非常方便，可以把 ETCD 直接就當做服務注冊發(fā)現中心來使用（服務注冊、發(fā)現），當然同時也支持 Consul、Eureka、Nacos 等服務注冊中心。

高性能

Apache 只是使用了 Nginx 的網絡庫而并沒有使用路由庫，重寫優(yōu)化了路由算法。

Apache APISIX 的路由復雜度是 O (k)，只和 URI 的長度有關，和路由數量無關；kong 的路由時間復雜度是 O (n) ，隨著路由數量線性增長，K 指 URI 長度，和路由數量沒有關系，例如有一百萬條路由，ApiSix 路由的時間復雜度都是一樣的，而 Kong 卻不是這樣的；
Apache APISIX 的 IP 匹配時間復雜度是 O (1)，不會隨著大量 IP 判斷而導致 CPU 資源跑滿；kong 的最新版本也換用了 Apache APISIX 的 IP 匹配庫；不管有多少IP都是一次命中，而 Kong 卻不是這樣的；
Apache APISIX 的路由匹配，接受 nginx 的所有變量作為條件，并且支持自定義函數；其他網關都是內置的幾個條件；
Apache APISIX 使用 etcd 作為配置中心，沒有單點，任意宕掉一臺機器，網關集群還能正常運行。其他基于 MySQL，postgres 的網關都會有單點問題；
Apache APISIX 的配置下發(fā)只要 1 毫秒就能達到所有網關節(jié)點，使用的是 etcd 的 watch；其他網關是定期輪詢數據庫，一般需要 5 秒才能獲取到最新配置；
只有 Apache APISIX 開放了自定義負載均衡的掛載點，其他網關都不支持。

獨創(chuàng)的插件編排

基于已有插件的基礎上，通過在界面上拖拖拽拽就可以生成一個全新的插件。

通過插件編排的方式可以把 Apache APISIX 的四十多個插件的上下游關系全部串聯起來形成一個新的插件。

當前，Kong支持 Go 編寫的插件，Envoy支持 Lua、WASM 編寫的 filter。那么，Apache APISIX 的使用者為什么要“寫”插件？我們認為運維、PM 也可以直接通過瀏覽器頁面創(chuàng)造一個自己的插件。

為了支持插件編排，Apache APISIX 一方面需要實現微插件、低代碼，同時需要底層架構和插件足夠靈活。

同類技術對比

Apache APISIX vs Kong

有對比才更有說服力，Apache APISIX 和 Kong 都是基于 Openresty/LuaJIT 實現的高性能 API 網關，讓我們來對比下他們的異同。

因此我們發(fā)現Apache APISIX的分布式可靠性強，路由支持豐富，配置變更生效時間快，網關處理速度快, 資源消耗率低，混沌測試支持度高，監(jiān)控系統(如SkyWalking)支持度高，插件變動動態(tài)化程度高以及二次開發(fā)難度低。

Apache APISIX vs Nginx

Nginx 是一款輕量級 Web 服務器、反向代理服務器，由于它的內存占用少、啟動極快、高并發(fā)能力強，故其在互聯網項目中得到廣泛應用，距今已經有十多年的歷史。但 Nginx 在步入云原生時代后遇到了更多的挑戰(zhàn)：

社區(qū)不活躍：沒有 github issue 和 PR
沒有跟進云原生：nginx-k8s-controller、nginx unit 的嘗試都失敗了
配置不能熱加載
非 http、https 流量的興起（微服務、物聯網……）
商業(yè)化不成功
被 F5 收購
后浪：API 網關比如 Kong 和 Apache APISIX，serviceMesh proxy 比如 Envoy 等

開源社區(qū)規(guī)劃

運營 Apache 孵化器項目的經驗

為了讓社區(qū)和用戶保持習慣和預期，每個月一個版本，雷打不動。
當天回復郵件列表和 github issue、PR
頻繁的布道和走訪用戶：每個月一次 meetup，走訪過美團、騰訊、華為、貝殼、平安、又拍云、中國移動、思必馳、空中云匯、中國航信等幾十家企業(yè)，深入了解用戶的需求

The Apache Way

不看重 github star，更關注如何吸引新的貢獻者以及如何讓貢獻者更加活躍
貢獻不止代碼，文檔、測試、文章都是貢獻，都可以成為 committer 和 PMC
社區(qū)多樣性：近 30 位 committer，其中兩位歐洲開發(fā)者；至少 4 位大學生，甚至有 00 后的后浪貢獻者，是 Apache APISIX committer

社區(qū)大于代碼

The Apache Way
活躍的社區(qū)，會重構壞的代碼；但再好的代碼，也會死于獨裁的社區(qū)
案例：Apache APISIX dashboard 的重構，社區(qū)對于 MySQL 的方案不滿，“怨聲載道”，然后來自 5 家公司的貢獻者一起重構掉它

規(guī)劃

2.0 版本（即將發(fā)布）：使用 etcd v3 替代 v2
3.0 版本：廢棄 admin API，分離 DP 和 CP
2021 年的 ?ag：Apache APISIX 的貢獻者超過 200 位

最后

如果你還在被 Nginx 或者 Nginx Ingress 的 reload 性能問題所折磨，又或者對 Kong 的轉發(fā)能力并不滿意，歡迎大家使用 Apache APISIX

作者：溫銘，來自一家在遠程工作方式下商業(yè)化開源項目的創(chuàng)業(yè)公司（支流科技），擔任 CEO 兼聯合創(chuàng)始人，與支流科技 (Apache APISIX) 類似的公司有 Confluent（Kafka 產品）、PinCap（TiDB產品），支流科技是 linux 基金會白銀會員、Linux 微服務 TARS 基金會創(chuàng)始會員。Apache 頂級項目 APISIX 的 PMC 主席。Skywalking 開源項目的貢獻者 (committer)。在創(chuàng)業(yè)之前，在360做企業(yè)安全，360開源委員會的發(fā)起人，騰訊的 TVP，TARS 基金會的 TOC 成員，在安全領域有四十多個專利。最近三年全職在做服務端的開源項目開發(fā)。在極客時間專欄著有OpenResty從入門到實戰(zhàn)。

原文地址： https:// cloudnative.to/blog/ful l-traffic-api-gateway-based-on-apache-apisix/