作者 | 溫銘，Apache APISIX PMC主席

責編 | 張紅月

出品 | CSDN（ID：CSDNnews）

API 是各個不同的應用程序和系統之間互相調用和傳輸數據的標準方式。在很多的開發團隊中都是使用 API-first 的模式，圍繞著 API 來進行產品的迭代，包括測試、Mock、文檔、API 網關、Dev Portal 等，這就是 API 全生命周期管理（Full Life Cycle API Management）。

API 解決的問題

在 API 出現之前，數據的傳輸和交換并沒有標準的方式，大多數情況下是通過數據庫、Excel 表格、文本，或者是 FTP，不同的系統和程序通過各種五花八門的方式來溝通。這些混亂的背后，隱藏了巨大的開發成本和安全隱患：權限控制、數據精細管控、限流限速、審計等，都只能用笨重的方式來解決。這就是計算機世界中的“巴別塔”（Tower of Babel），因此只有解決了不同語言開發的系統以及不同存儲方案帶來的問題，才有機會構建足夠復雜的產品。

而 API 的出現，則成功地解決了巴別塔問題，開發者只需要關心其他系統對外暴露的 API 即可，無需關心底層實現和細節。

我們熟知的手機 App、網絡游戲、視頻直播、遠程會議和 IoT 設備，都離不開終端設備與服務端的連接和數據傳輸，這些都是通過 API 完成的。

為什么需要 API 網關

API 網關是 API 全生命周期管理的關鍵基礎組件，負責生產環境中 API 的配置、發布、版本回滾、安全、負載均衡等。API 網關是所有終端流量的入口，負責把終端的 API 請求路由到正確的上游服務進行處理，然后再把返回的數據返回給原始請求方，同時保證整個過程的安全、可靠和低延遲。

在最開始 API 數量不多的情況下，API 網關往往是一個由 Web Server 和上游服務兩部分拼接而成的虛擬組件：由 Apache 和 NGINX 等組件完成最簡單的路由轉發、反向代理和和負載均衡，其他功能比如身份認證、限流限速等，則依靠上游服務自身進行實現。

但隨著 API 的數量越來越多，喜歡“偷懶”的開發者們發現了一個嚴重的問題：他們需要在不同的上游服務中，重復實現身份認證、限流限速、日志等通用的功能，這不僅會浪費開發資源，而且一旦需要修改這部分的代碼，就需要修改很多代碼，這是版本管理和升級維護的噩夢。怎么辦呢？聰明的開發者們很快就找到了解決方案：把這些通用的功能抽象到一個統一的組件中，把上述的兩層結構改為一層結構，從上游的邏輯代碼中剝離與業務無關的功能，然后增強 Apache 和 NGINX 這類組件。這就是第一代 API 網關的誕生過程。

讓 API 網關承載更多非業務邏輯的功能，這就是 API 網關一直以來的進化方向。在這個過程中，前端開發者和后端開發者們，為了讓產品能夠更快的迭代，就對 API 網關提出了越來越多的需求，并不僅僅局限于負載均衡、反向代理、身份認證等傳統功能，還在 gRPC、GraphQL、可觀測性等方面提出了很多新的功能。

API 網關的作用

為了讓 API 網關更靈活高效，開發者們在底層上也做了非常多創新，比如：

• 功能插件化。隨著 API 網關上承載的功能越來越多，如何讓這些功能之間更好的隔離以及讓二次開發變得更加簡單？插件，是完美的解決方案。因此，現在主流的 API 網關均采用插件來實現各種功能，比如在 Apache APISIX 中叫做 Plugins，在 Envoy 中則稱之為 Filters，它們的含義是相同的。插件化可以讓網關的開發者不再關心底層實現，用較少的開發資源就可以實現一個新的功能。
• 數據面和控制面的分離。在第一代 API 網關的實現中，數據面和控制面是在同一個進程中實現的，這樣足夠簡單，但也帶來了很大的安全隱患。由于數據面是直接對外提供服務的，如果被黑客入侵，就有機會獲取到控制面的數據（比如 SSL 證書）和控制權，造成更大的破壞。因此，現在大部分的開源 API 網關，都是將兩者分別部署的，中間通過關系型數據庫或者 etcd 來進行配置的管理和同步。

以 Apache APISIX 為例，下面的架構圖，詮釋了以上兩個創新：

云原生時代下的挑戰

過去十年，IT 領域最大的技術變革就是云原生。誕生于 2013 年的 Docker 拉開了云原生的帷幕，從此裸金屬、虛擬機開始被容器所替代，單體架構開始被微服務所替代。但是云原生并不是簡單的技術革命，其背后的推動力主要來自互聯網產品的快速發展和激烈競爭，云原生相關的技術生逢其時，迅速流行并替代了之前的很多技術組件和方案。

具體到 API 網關在云原生中的挑戰，主要來自以下兩個方面：

單體架構到微服務的轉型

在微服務架構逐漸被開發者認可和落地后，該架構釋放了巨大的技術紅利：每個微服務可以按照自己的節奏進行升級和發布，不需要擔心與其他服務的耦合。產品的迭代因此變得敏捷，每天都可以進行幾十次甚至幾百次的發布。

但與此同時，微服務的發展也帶來了一些副作用，比如：

• API 和微服務的數量從最初的幾十個，增長到幾千個，甚至幾萬個；
• 出現故障時如何快速定位是哪一個 API 引起的？
• 如何保證 API 的安全？
• 如何做到服務熔斷和服務降級？

API 網關無法獨立解決安全性、可觀察性、灰度發布等問題。它需要與 Prometheus、Zipkin、Skywalking、Datadog、Okta 等眾多開源項目和 SaaS 服務合作，為企業提供更好的解決方案。

動態和集群化管理

容器和 Kubernetes 的普及，讓動態成為所有云原生基礎組件的標準特性。在 Kubernetes 的環境中，容器在不斷的生成和銷毀，彈性伸縮成為一個必選項而不是可選項。

想象一個場景：一家互聯網電商公司做了一次促銷，大量的用戶在一個小時內涌入，促銷結束后就會離開。對于傳統架構的公司來說，他們需要事先采購一批物理服務器，來應對這些高峰時候的 API 流量；但是對于云原生架構的公司來說，就可以隨時使用公有云上的彈性資源，根據 API 請求的數量，自動的調整網絡、計算、數據庫等資源的規模即可。那么伴隨著容器彈性伸縮而來的技術挑戰如下：

• 上游服務不斷更換 IP 地址和端口;
• IP 黑白名單的頻繁更新;
• 服務健康的及時檢測和異常處理;
• API 的頻繁發布;
• 服務注冊和發現的及時性;
• SSL 證書的熱更新和自動輪轉。

想要解決上述這些挑戰，均需要依賴于動態。以 NGINX 為代表的第一代 API 網關，動態能力是非常弱的。因為 NGINX 是本地靜態配置文件驅動的，所以變更任何配置都需要重啟 NGINX 服務才能生效，這在云原生時代是不能被企業接受的。這就是第一代 API 網關的技術痛點之一。

在中國，有一家類似微軟 Office 365 的 SaaS 辦公軟件公司 -- WPS，他們有數百臺物理機在運行著 Apache APISIX，有近萬核 CPU 在處理來自客戶端的 API 請求，每天處理數百億次 API 請求。

在這個超大規模的 API 網關環境下，開發者不可能去逐個修改每一個 API 網關的配置然后 Reload，他們希望有一個統一的控制臺來操作整個集群。可惜的是，第一代 API 網關誕生的年代，并沒有這么大的實例規模，也就沒有考慮集群管理的需求。

下一代 API 網關的發展

上述挑戰和痛點，逐漸催生了新一代的 API 網關。

和第一代 API 網關不同的是，云原生時代誕生的下一代 API 網關是在開源社區的驅動下快速成長的。借助社區和眾多開源貢獻者的力量，這些 API 網關有機會形成一個正向的迭代和進化：

• 更快速的收集一線開發者及用戶的需求和痛點
• 在開源項目中嘗試解決這些問題
• 開源項目變得更加好用，吸引更多開發者使用

于是，我們看到下一代 API 網關突破了傳統網關的負載均衡和反向代理的定位，而是承擔起了 API 和流量的連接、調度、過濾、分析、協議轉換、治理、集成等更多的職責。

支持更低成本的二次開發

同時，讓開發者能夠以更低的成本進行二次開發，也成為了下一代 API 網關的亮點。集成是 API 網關的重要功能之一，對于下游是協議解析和各種協議的轉換，包括 GraphQL、gRPC、Dubbo 等；對于上游是集成 Okta、Keycloak、Datadog、Prometheus 等身份認證、可觀測性服務，以及公司內部的認證、日志、審計等服務。API 網關不可能覆蓋集成過程中所有的組件，這時候不可避免地需要開發者通過插件的方式進行二次開發，來滿足自己的業務需求。不同的 API 網關提供了不同的二次開發的編程語言和開發方式，Apache APISIX 和 Kong 都可以使用 Lua 來編寫原生插件，Envoy 是使用 C++ 編寫原生插件。同時，Apache APISIX 還可以使用 Go、Python、Node、Java 和 Wasm 來編寫插件，這些主流的開發語言已經可以覆蓋絕大部分開發者了。

開發者不必去學習 Lua 和 C++，就可以使用自己熟悉的編程語言在下一代 API 網關上進行開發，這讓基礎組件的開發變得更加簡單。開源和易于二次開發，是下一代的 API 網關最重要的特點，它把更多的選擇權留給了開發者自身，同時，開發者也可以更加放心的在多云、混合云的環境下使用 API 網關，不用擔心被云供應商鎖定。

基于雙十一的 API 網關流量處理場景

這里，我們用一個具體的例子來解釋下現代 API 網關的作用。

在雙十一時，電商都會有各種各樣的商品促銷活動，這段時間的 API 請求量是平時的幾十倍。讓我們先來看下如果沒有 API 網關將會是怎樣的技術架構：

可以看到，在 Order 和 Payment 服務中，身份認證和日志記錄功能是重復的。一個電商的服務，一般會有數千個不同的服務組成，這時候就會有大量的代碼和功能是重復開發的。

下面是增加了 API 網關之后的架構圖：

從上圖可以看到，我們在 API 網關層統一了公共的服務，后端服務只需要關心自身業務，為彈性伸縮提供了更多可能。

當促銷開始時，客戶端大量 API 請求涌入 API 網關的時候，后端服務需要進行快速的彈性伸縮，為了保障關鍵業務不受突發流量的影響，我們需要在 API 網關上識別惡意爬蟲并實現限流限速、服務降級和熔斷。此時，我們可以暫時關閉部分服務，比如商品評價、快遞查詢等。

但是庫存信息、購買功能、支付功能等核心業務是絕對不能出現故障的，因此我們需要通過 K8s 來管理容器服務，再生成更多的服務副本來保證它的正常運行。此時 API 網關需要將客戶端的 API 請求路由到新生成的副本服務，并且自動移除出現故障的服務，如下圖所示。

總結

API 網關并不是一個新的基礎中間件，而是在產品快速迭代和技術架構的變遷中，變得越來越重要。而下一代云原生 API 網關的出現則解決了企業用戶在集群管理，動態，生態，可觀測性以及安全性等方面的痛點。

API 網關不僅可以處理 API 的流量，也可以來處理 Kubernetes Ingress 和服務網格的流量，進一步降低開發者的學習成本，幫助企業更好的統一管理流量。