作者 | 溫銘，Apache APISIX PMC主席

責(zé)編 | 張紅月

出品 | CSDN（ID：CSDNnews）

API 是各個(gè)不同的應(yīng)用程序和系統(tǒng)之間互相調(diào)用和傳輸數(shù)據(jù)的標(biāo)準(zhǔn)方式。在很多的開(kāi)發(fā)團(tuán)隊(duì)中都是使用 API-first 的模式，圍繞著 API 來(lái)進(jìn)行產(chǎn)品的迭代，包括測(cè)試、Mock、文檔、API 網(wǎng)關(guān)、Dev Portal 等，這就是 API 全生命周期管理（Full Life Cycle API Management）。

API 解決的問(wèn)題

在 API 出現(xiàn)之前，數(shù)據(jù)的傳輸和交換并沒(méi)有標(biāo)準(zhǔn)的方式，大多數(shù)情況下是通過(guò)數(shù)據(jù)庫(kù)、Excel 表格、文本，或者是 FTP，不同的系統(tǒng)和程序通過(guò)各種五花八門(mén)的方式來(lái)溝通。這些混亂的背后，隱藏了巨大的開(kāi)發(fā)成本和安全隱患：權(quán)限控制、數(shù)據(jù)精細(xì)管控、限流限速、審計(jì)等，都只能用笨重的方式來(lái)解決。這就是計(jì)算機(jī)世界中的“巴別塔”（Tower of Babel），因此只有解決了不同語(yǔ)言開(kāi)發(fā)的系統(tǒng)以及不同存儲(chǔ)方案帶來(lái)的問(wèn)題，才有機(jī)會(huì)構(gòu)建足夠復(fù)雜的產(chǎn)品。

而 API 的出現(xiàn)，則成功地解決了巴別塔問(wèn)題，開(kāi)發(fā)者只需要關(guān)心其他系統(tǒng)對(duì)外暴露的 API 即可，無(wú)需關(guān)心底層實(shí)現(xiàn)和細(xì)節(jié)。

我們熟知的手機(jī) App、網(wǎng)絡(luò)游戲、視頻直播、遠(yuǎn)程會(huì)議和 IoT 設(shè)備，都離不開(kāi)終端設(shè)備與服務(wù)端的連接和數(shù)據(jù)傳輸，這些都是通過(guò) API 完成的。

為什么需要 API 網(wǎng)關(guān)

API 網(wǎng)關(guān)是 API 全生命周期管理的關(guān)鍵基礎(chǔ)組件，負(fù)責(zé)生產(chǎn)環(huán)境中 API 的配置、發(fā)布、版本回滾、安全、負(fù)載均衡等。API 網(wǎng)關(guān)是所有終端流量的入口，負(fù)責(zé)把終端的 API 請(qǐng)求路由到正確的上游服務(wù)進(jìn)行處理，然后再把返回的數(shù)據(jù)返回給原始請(qǐng)求方，同時(shí)保證整個(gè)過(guò)程的安全、可靠和低延遲。

在最開(kāi)始 API 數(shù)量不多的情況下，API 網(wǎng)關(guān)往往是一個(gè)由 Web Server 和上游服務(wù)兩部分拼接而成的虛擬組件：由 Apache 和 NGINX 等組件完成最簡(jiǎn)單的路由轉(zhuǎn)發(fā)、反向代理和和負(fù)載均衡，其他功能比如身份認(rèn)證、限流限速等，則依靠上游服務(wù)自身進(jìn)行實(shí)現(xiàn)。

但隨著 API 的數(shù)量越來(lái)越多，喜歡“偷懶”的開(kāi)發(fā)者們發(fā)現(xiàn)了一個(gè)嚴(yán)重的問(wèn)題：他們需要在不同的上游服務(wù)中，重復(fù)實(shí)現(xiàn)身份認(rèn)證、限流限速、日志等通用的功能，這不僅會(huì)浪費(fèi)開(kāi)發(fā)資源，而且一旦需要修改這部分的代碼，就需要修改很多代碼，這是版本管理和升級(jí)維護(hù)的噩夢(mèng)。怎么辦呢？聰明的開(kāi)發(fā)者們很快就找到了解決方案：把這些通用的功能抽象到一個(gè)統(tǒng)一的組件中，把上述的兩層結(jié)構(gòu)改為一層結(jié)構(gòu)，從上游的邏輯代碼中剝離與業(yè)務(wù)無(wú)關(guān)的功能，然后增強(qiáng) Apache 和 NGINX 這類(lèi)組件。這就是第一代 API 網(wǎng)關(guān)的誕生過(guò)程。

讓 API 網(wǎng)關(guān)承載更多非業(yè)務(wù)邏輯的功能，這就是 API 網(wǎng)關(guān)一直以來(lái)的進(jìn)化方向。在這個(gè)過(guò)程中，前端開(kāi)發(fā)者和后端開(kāi)發(fā)者們，為了讓產(chǎn)品能夠更快的迭代，就對(duì) API 網(wǎng)關(guān)提出了越來(lái)越多的需求，并不僅僅局限于負(fù)載均衡、反向代理、身份認(rèn)證等傳統(tǒng)功能，還在 gRPC、GraphQL、可觀測(cè)性等方面提出了很多新的功能。

API 網(wǎng)關(guān)的作用

為了讓 API 網(wǎng)關(guān)更靈活高效，開(kāi)發(fā)者們?cè)诘讓由弦沧隽朔浅６鄤?chuàng)新，比如：

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

以 Apache APISIX 為例，下面的架構(gòu)圖，詮釋了以上兩個(gè)創(chuàng)新：

云原生時(shí)代下的挑戰(zhàn)

過(guò)去十年，IT 領(lǐng)域最大的技術(shù)變革就是云原生。誕生于 2013 年的 Docker 拉開(kāi)了云原生的帷幕，從此裸金屬、虛擬機(jī)開(kāi)始被容器所替代，單體架構(gòu)開(kāi)始被微服務(wù)所替代。但是云原生并不是簡(jiǎn)單的技術(shù)革命，其背后的推動(dòng)力主要來(lái)自互聯(lián)網(wǎng)產(chǎn)品的快速發(fā)展和激烈競(jìng)爭(zhēng)，云原生相關(guān)的技術(shù)生逢其時(shí)，迅速流行并替代了之前的很多技術(shù)組件和方案。

具體到 API 網(wǎng)關(guān)在云原生中的挑戰(zhàn)，主要來(lái)自以下兩個(gè)方面：

單體架構(gòu)到微服務(wù)的轉(zhuǎn)型

在微服務(wù)架構(gòu)逐漸被開(kāi)發(fā)者認(rèn)可和落地后，該架構(gòu)釋放了巨大的技術(shù)紅利：每個(gè)微服務(wù)可以按照自己的節(jié)奏進(jìn)行升級(jí)和發(fā)布，不需要擔(dān)心與其他服務(wù)的耦合。產(chǎn)品的迭代因此變得敏捷，每天都可以進(jìn)行幾十次甚至幾百次的發(fā)布。

但與此同時(shí)，微服務(wù)的發(fā)展也帶來(lái)了一些副作用，比如：

• API 和微服務(wù)的數(shù)量從最初的幾十個(gè)，增長(zhǎng)到幾千個(gè)，甚至幾萬(wàn)個(gè)；
• 出現(xiàn)故障時(shí)如何快速定位是哪一個(gè) API 引起的？
• 如何保證 API 的安全？
• 如何做到服務(wù)熔斷和服務(wù)降級(jí)？

API 網(wǎng)關(guān)無(wú)法獨(dú)立解決安全性、可觀察性、灰度發(fā)布等問(wèn)題。它需要與 Prometheus、Zipkin、Skywalking、Datadog、Okta 等眾多開(kāi)源項(xiàng)目和 SaaS 服務(wù)合作，為企業(yè)提供更好的解決方案。

動(dòng)態(tài)和集群化管理

容器和 Kubernetes 的普及，讓動(dòng)態(tài)成為所有云原生基礎(chǔ)組件的標(biāo)準(zhǔn)特性。在 Kubernetes 的環(huán)境中，容器在不斷的生成和銷(xiāo)毀，彈性伸縮成為一個(gè)必選項(xiàng)而不是可選項(xiàng)。

想象一個(gè)場(chǎng)景：一家互聯(lián)網(wǎng)電商公司做了一次促銷(xiāo)，大量的用戶在一個(gè)小時(shí)內(nèi)涌入，促銷(xiāo)結(jié)束后就會(huì)離開(kāi)。對(duì)于傳統(tǒng)架構(gòu)的公司來(lái)說(shuō)，他們需要事先采購(gòu)一批物理服務(wù)器，來(lái)應(yīng)對(duì)這些高峰時(shí)候的 API 流量；但是對(duì)于云原生架構(gòu)的公司來(lái)說(shuō)，就可以隨時(shí)使用公有云上的彈性資源，根據(jù) API 請(qǐng)求的數(shù)量，自動(dòng)的調(diào)整網(wǎng)絡(luò)、計(jì)算、數(shù)據(jù)庫(kù)等資源的規(guī)模即可。那么伴隨著容器彈性伸縮而來(lái)的技術(shù)挑戰(zhàn)如下：

• 上游服務(wù)不斷更換 IP 地址和端口;
• IP 黑白名單的頻繁更新;
• 服務(wù)健康的及時(shí)檢測(cè)和異常處理;
• API 的頻繁發(fā)布;
• 服務(wù)注冊(cè)和發(fā)現(xiàn)的及時(shí)性;
• SSL 證書(shū)的熱更新和自動(dòng)輪轉(zhuǎn)。

想要解決上述這些挑戰(zhàn)，均需要依賴于動(dòng)態(tài)。以 NGINX 為代表的第一代 API 網(wǎng)關(guān)，動(dòng)態(tài)能力是非常弱的。因?yàn)?NGINX 是本地靜態(tài)配置文件驅(qū)動(dòng)的，所以變更任何配置都需要重啟 NGINX 服務(wù)才能生效，這在云原生時(shí)代是不能被企業(yè)接受的。這就是第一代 API 網(wǎng)關(guān)的技術(shù)痛點(diǎn)之一。

在中國(guó)，有一家類(lèi)似微軟 Office 365 的 SaaS 辦公軟件公司 -- WPS，他們有數(shù)百臺(tái)物理機(jī)在運(yùn)行著 Apache APISIX，有近萬(wàn)核 CPU 在處理來(lái)自客戶端的 API 請(qǐng)求，每天處理數(shù)百億次 API 請(qǐng)求。

在這個(gè)超大規(guī)模的 API 網(wǎng)關(guān)環(huán)境下，開(kāi)發(fā)者不可能去逐個(gè)修改每一個(gè) API 網(wǎng)關(guān)的配置然后 Reload，他們希望有一個(gè)統(tǒng)一的控制臺(tái)來(lái)操作整個(gè)集群?？上У氖?，第一代 API 網(wǎng)關(guān)誕生的年代，并沒(méi)有這么大的實(shí)例規(guī)模，也就沒(méi)有考慮集群管理的需求。

下一代 API 網(wǎng)關(guān)的發(fā)展

上述挑戰(zhàn)和痛點(diǎn)，逐漸催生了新一代的 API 網(wǎng)關(guān)。

和第一代 API 網(wǎng)關(guān)不同的是，云原生時(shí)代誕生的下一代 API 網(wǎng)關(guān)是在開(kāi)源社區(qū)的驅(qū)動(dòng)下快速成長(zhǎng)的。借助社區(qū)和眾多開(kāi)源貢獻(xiàn)者的力量，這些 API 網(wǎng)關(guān)有機(jī)會(huì)形成一個(gè)正向的迭代和進(jìn)化：

• 更快速的收集一線開(kāi)發(fā)者及用戶的需求和痛點(diǎn)
• 在開(kāi)源項(xiàng)目中嘗試解決這些問(wèn)題
• 開(kāi)源項(xiàng)目變得更加好用，吸引更多開(kāi)發(fā)者使用

于是，我們看到下一代 API 網(wǎng)關(guān)突破了傳統(tǒng)網(wǎng)關(guān)的負(fù)載均衡和反向代理的定位，而是承擔(dān)起了 API 和流量的連接、調(diào)度、過(guò)濾、分析、協(xié)議轉(zhuǎn)換、治理、集成等更多的職責(zé)。

支持更低成本的二次開(kāi)發(fā)

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

開(kāi)發(fā)者不必去學(xué)習(xí) Lua 和 C++，就可以使用自己熟悉的編程語(yǔ)言在下一代 API 網(wǎng)關(guān)上進(jìn)行開(kāi)發(fā)，這讓基礎(chǔ)組件的開(kāi)發(fā)變得更加簡(jiǎn)單。開(kāi)源和易于二次開(kāi)發(fā)，是下一代的 API 網(wǎng)關(guān)最重要的特點(diǎn)，它把更多的選擇權(quán)留給了開(kāi)發(fā)者自身，同時(shí)，開(kāi)發(fā)者也可以更加放心的在多云、混合云的環(huán)境下使用 API 網(wǎng)關(guān)，不用擔(dān)心被云供應(yīng)商鎖定。

基于雙十一的 API 網(wǎng)關(guān)流量處理場(chǎng)景

這里，我們用一個(gè)具體的例子來(lái)解釋下現(xiàn)代 API 網(wǎng)關(guān)的作用。

在雙十一時(shí)，電商都會(huì)有各種各樣的商品促銷(xiāo)活動(dòng)，這段時(shí)間的 API 請(qǐng)求量是平時(shí)的幾十倍。讓我們先來(lái)看下如果沒(méi)有 API 網(wǎng)關(guān)將會(huì)是怎樣的技術(shù)架構(gòu)：

可以看到，在 Order 和 Payment 服務(wù)中，身份認(rèn)證和日志記錄功能是重復(fù)的。一個(gè)電商的服務(wù)，一般會(huì)有數(shù)千個(gè)不同的服務(wù)組成，這時(shí)候就會(huì)有大量的代碼和功能是重復(fù)開(kāi)發(fā)的。

下面是增加了 API 網(wǎng)關(guān)之后的架構(gòu)圖：

從上圖可以看到，我們?cè)?API 網(wǎng)關(guān)層統(tǒng)一了公共的服務(wù)，后端服務(wù)只需要關(guān)心自身業(yè)務(wù)，為彈性伸縮提供了更多可能。

當(dāng)促銷(xiāo)開(kāi)始時(shí)，客戶端大量 API 請(qǐng)求涌入 API 網(wǎng)關(guān)的時(shí)候，后端服務(wù)需要進(jìn)行快速的彈性伸縮，為了保障關(guān)鍵業(yè)務(wù)不受突發(fā)流量的影響，我們需要在 API 網(wǎng)關(guān)上識(shí)別惡意爬蟲(chóng)并實(shí)現(xiàn)限流限速、服務(wù)降級(jí)和熔斷。此時(shí)，我們可以暫時(shí)關(guān)閉部分服務(wù)，比如商品評(píng)價(jià)、快遞查詢等。

但是庫(kù)存信息、購(gòu)買(mǎi)功能、支付功能等核心業(yè)務(wù)是絕對(duì)不能出現(xiàn)故障的，因此我們需要通過(guò) K8s 來(lái)管理容器服務(wù)，再生成更多的服務(wù)副本來(lái)保證它的正常運(yùn)行。此時(shí) API 網(wǎng)關(guān)需要將客戶端的 API 請(qǐng)求路由到新生成的副本服務(wù)，并且自動(dòng)移除出現(xiàn)故障的服務(wù)，如下圖所示。

總結(jié)

API 網(wǎng)關(guān)并不是一個(gè)新的基礎(chǔ)中間件，而是在產(chǎn)品快速迭代和技術(shù)架構(gòu)的變遷中，變得越來(lái)越重要。而下一代云原生 API 網(wǎng)關(guān)的出現(xiàn)則解決了企業(yè)用戶在集群管理，動(dòng)態(tài)，生態(tài)，可觀測(cè)性以及安全性等方面的痛點(diǎn)。

API 網(wǎng)關(guān)不僅可以處理 API 的流量，也可以來(lái)處理 Kubernetes Ingress 和服務(wù)網(wǎng)格的流量，進(jìn)一步降低開(kāi)發(fā)者的學(xué)習(xí)成本，幫助企業(yè)更好的統(tǒng)一管理流量。