雲原生時代,API 閘道器為何如此重要?

雲原生時代,API 閘道器為何如此重要?

【CSDN 編者按】API是Application Program Interface,應用程式連線介面的縮寫,作為資料傳輸流轉的重要通道,API閘道器更成為雲原生時代的重要入口。

作者 | 溫銘,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 數量不多的情況下,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 為例,下面的架構圖,詮釋了以上兩個創新:

雲原生時代,API 閘道器為何如此重要?

雲原生時代下的挑戰

過去十年,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 閘道器的亮點。整合是 API 閘道器的重要功能之一,對於下游是協議解析和各種協議的轉換,包括 GraphQL、gRPC、Dubbo 等;對於上游是整合 Okta、Keycloak、Datadog、Prometheus 等身份認證、可觀測性服務,以及公司內部的認證、日誌、審計等服務。API 閘道器不可能覆蓋整合過程中所有的元件,這時候不可避免地需要開發者透過外掛的方式進行二次開發,來滿足自己的業務需求。不同的 API 閘道器提供了不同的二次開發的程式語言和開發方式,Apache APISIX 和 Kong 都可以使用 Lua 來編寫原生外掛,Envoy 是使用 C++ 編寫原生外掛。同時,Apache APISIX 還可以使用 Go、Python、Node、Java 和 Wasm 來編寫外掛,這些主流的開發語言已經可以覆蓋絕大部分開發者了。

雲原生時代,API 閘道器為何如此重要?

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

基於雙十一的 API 閘道器流量處理場景

這裡,我們用一個具體的例子來解釋下現代 API 閘道器的作用。

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

雲原生時代,API 閘道器為何如此重要?

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

下面是增加了 API 閘道器之後的架構圖:

雲原生時代,API 閘道器為何如此重要?

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

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

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

雲原生時代,API 閘道器為何如此重要?

總結

API 閘道器並不是一個新的基礎中介軟體,而是在產品快速迭代和技術架構的變遷中,變得越來越重要。而下一代雲原生 API 閘道器的出現則解決了企業使用者在叢集管理,動態,生態,可觀測性以及安全性等方面的痛點。

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

頂部