【CSDN 編者按】API是Application Program Interface，應(yīng)用程序連接接口的縮寫，作為數(shù)據(jù)傳輸流轉(zhuǎn)的重要通道，API網(wǎng)關(guān)更成為云原生時代的重要入口。
作者 | 溫銘，Apache APISIX PMC主席
責(zé)編 | 張紅月
出品 | CSDN（ID：CSDNnews）
API 是各個不同的應(yīng)用程序和系統(tǒng)之間互相調(diào)用和傳輸數(shù)據(jù)的標(biāo)準(zhǔn)方式。在很多的開發(fā)團(tuán)隊中都是使用 API-first 的模式，圍繞著 API 來進(jìn)行產(chǎn)品的迭代，包括測試、Mock、文檔、API 網(wǎng)關(guān)、Dev Portal 等，這就是 API 全生命周期管理（Full Life Cycle API Management）。
API 解決的問題
在 API 出現(xiàn)之前，數(shù)據(jù)的傳輸和交換并沒有標(biāo)準(zhǔn)的方式，大多數(shù)情況下是通過數(shù)據(jù)庫、Excel 表格、文本，或者是 FTP，不同的系統(tǒng)和程序通過各種五花八門的方式來溝通。這些混亂的背后，隱藏了巨大的開發(fā)成本和安全隱患：權(quán)限控制、數(shù)據(jù)精細(xì)管控、限流限速、審計等，都只能用笨重的方式來解決。這就是計算機(jī)世界中的“巴別塔”（Tower of Babel），因此只有解決了不同語言開發(fā)的系統(tǒng)以及不同存儲方案帶來的問題，才有機(jī)會構(gòu)建足夠復(fù)雜的產(chǎn)品。
而 API 的出現(xiàn)，則成功地解決了巴別塔問題，開發(fā)者只需要關(guān)心其他系統(tǒng)對外暴露的 API 即可，無需關(guān)心底層實(shí)現(xiàn)和細(xì)節(jié)。
我們熟知的手機(jī) App、網(wǎng)絡(luò)游戲、視頻直播、遠(yuǎn)程會議和 IoT 設(shè)備，都離不開終端設(shè)備與服務(wù)端的連接和數(shù)據(jù)傳輸，這些都是通過 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 請求路由到正確的上游服務(wù)進(jìn)行處理，然后再把返回的數(shù)據(jù)返回給原始請求方，同時保證整個過程的安全、可靠和低延遲。
在最開始 API 數(shù)量不多的情況下，API 網(wǎng)關(guān)往往是一個由 Web Server 和上游服務(wù)兩部分拼接而成的虛擬組件：由 Apache 和 Nginx 等組件完成最簡單的路由轉(zhuǎn)發(fā)、反向代理和和負(fù)載均衡，其他功能比如身份認(rèn)證、限流限速等，則依靠上游服務(wù)自身進(jìn)行實(shí)現(xiàn)。
但隨著 API 的數(shù)量越來越多，喜歡“偷懶”的開發(fā)者們發(fā)現(xiàn)了一個嚴(yán)重的問題：他們需要在不同的上游服務(wù)中，重復(fù)實(shí)現(xiàn)身份認(rèn)證、限流限速、日志等通用的功能，這不僅會浪費(fèi)開發(fā)資源，而且一旦需要修改這部分的代碼，就需要修改很多代碼，這是版本管理和升級維護(hù)的噩夢。怎么辦呢？聰明的開發(fā)者們很快就找到了解決方案：把這些通用的功能抽象到一個統(tǒng)一的組件中，把上述的兩層結(jié)構(gòu)改為一層結(jié)構(gòu)，從上游的邏輯代碼中剝離與業(yè)務(wù)無關(guān)的功能，然后增強(qiáng) Apache 和 NGINX 這類組件。這就是第一代 API 網(wǎng)關(guān)的誕生過程。
讓 API 網(wǎng)關(guān)承載更多非業(yè)務(wù)邏輯的功能，這就是 API 網(wǎng)關(guān)一直以來的進(jìn)化方向。在這個過程中，前端開發(fā)者和后端開發(fā)者們，為了讓產(chǎn)品能夠更快的迭代，就對 API 網(wǎng)關(guān)提出了越來越多的需求，并不僅僅局限于負(fù)載均衡、反向代理、身份認(rèn)證等傳統(tǒng)功能，還在 gRPC、GraphQL、可觀測性等方面提出了很多新的功能。
API 網(wǎng)關(guān)的作用
為了讓 API 網(wǎng)關(guān)更靈活高效，開發(fā)者們在底層上也做了非常多創(chuàng)新，比如：
-
功能插件化。隨著 API 網(wǎng)關(guān)上承載的功能越來越多，如何讓這些功能之間更好的隔離以及讓二次開發(fā)變得更加簡單？插件，是完美的解決方案。因此，現(xiàn)在主流的 API 網(wǎng)關(guān)均采用插件來實(shí)現(xiàn)各種功能，比如在 Apache APISIX 中叫做 Plugins，在 Envoy 中則稱之為 Filters，它們的含義是相同的。插件化可以讓網(wǎng)關(guān)的開發(fā)者不再關(guān)心底層實(shí)現(xiàn)，用較少的開發(fā)資源就可以實(shí)現(xiàn)一個新的功能。
-
數(shù)據(jù)面和控制面的分離。在第一代 API 網(wǎng)關(guān)的實(shí)現(xiàn)中，數(shù)據(jù)面和控制面是在同一個進(jìn)程中實(shí)現(xiàn)的，這樣足夠簡單，但也帶來了很大的安全隱患。由于數(shù)據(jù)面是直接對外提供服務(wù)的，如果被黑客入侵，就有機(jī)會獲取到控制面的數(shù)據(jù)（比如 SSL 證書）和控制權(quán)，造成更大的破壞。因此，現(xiàn)在大部分的開源 API 網(wǎng)關(guān)，都是將兩者分別部署的，中間通過關(guān)系型數(shù)據(jù)庫或者 etcd 來進(jìn)行配置的管理和同步。
以 Apache APISIX 為例，下面的架構(gòu)圖，詮釋了以上兩個創(chuàng)新：
云原生時代下的挑戰(zhàn)
過去十年，IT 領(lǐng)域最大的技術(shù)變革就是云原生。誕生于 2013 年的 Docker 拉開了云原生的帷幕，從此裸金屬、虛擬機(jī)開始被容器所替代，單體架構(gòu)開始被微服務(wù)所替代。但是云原生并不是簡單的技術(shù)革命，其背后的推動力主要來自互聯(lián)網(wǎng)產(chǎn)品的快速發(fā)展和激烈競爭，云原生相關(guān)的技術(shù)生逢其時，迅速流行并替代了之前的很多技術(shù)組件和方案。
具體到 API 網(wǎng)關(guān)在云原生中的挑戰(zhàn)，主要來自以下兩個方面：
單體架構(gòu)到微服務(wù)的轉(zhuǎn)型
在微服務(wù)架構(gòu)逐漸被開發(fā)者認(rèn)可和落地后，該架構(gòu)釋放了巨大的技術(shù)紅利：每個微服務(wù)可以按照自己的節(jié)奏進(jìn)行升級和發(fā)布，不需要擔(dān)心與其他服務(wù)的耦合。產(chǎn)品的迭代因此變得敏捷，每天都可以進(jìn)行幾十次甚至幾百次的發(fā)布。
但與此同時，微服務(wù)的發(fā)展也帶來了一些副作用，比如：
-
API 和微服務(wù)的數(shù)量從最初的幾十個，增長到幾千個，甚至幾萬個；
-
出現(xiàn)故障時如何快速定位是哪一個 API 引起的？
-
如何保證 API 的安全？
-
如何做到服務(wù)熔斷和服務(wù)降級？
API 網(wǎng)關(guān)無法獨(dú)立解決安全性、可觀察性、灰度發(fā)布等問題。它需要與 Prometheus、Zipkin、Skywalking、Datadog、Okta 等眾多開源項目和 SaaS 服務(wù)合作，為企業(yè)提供更好的解決方案。
動態(tài)和集群化管理
容器和 Kube.NETes 的普及，讓動態(tài)成為所有云原生基礎(chǔ)組件的標(biāo)準(zhǔn)特性。在 Kubernetes 的環(huán)境中，容器在不斷的生成和銷毀，彈性伸縮成為一個必選項而不是可選項。
想象一個場景：一家互聯(lián)網(wǎng)電商公司做了一次促銷，大量的用戶在一個小時內(nèi)涌入，促銷結(jié)束后就會離開。對于傳統(tǒng)架構(gòu)的公司來說，他們需要事先采購一批物理服務(wù)器，來應(yīng)對這些高峰時候的 API 流量；但是對于云原生架構(gòu)的公司來說，就可以隨時使用公有云上的彈性資源，根據(jù) API 請求的數(shù)量，自動的調(diào)整網(wǎng)絡(luò)、計算、數(shù)據(jù)庫等資源的規(guī)模即可。那么伴隨著容器彈性伸縮而來的技術(shù)挑戰(zhàn)如下：
-
上游服務(wù)不斷更換 IP 地址和端口;
-
IP 黑白名單的頻繁更新;
-
服務(wù)健康的及時檢測和異常處理;
-
API 的頻繁發(fā)布;
-
服務(wù)注冊和發(fā)現(xiàn)的及時性;
-
SSL 證書的熱更新和自動輪轉(zhuǎn)。
想要解決上述這些挑戰(zhàn)，均需要依賴于動態(tài)。以 NGINX 為代表的第一代 API 網(wǎng)關(guān)，動態(tài)能力是非常弱的。因為 NGINX 是本地靜態(tài)配置文件驅(qū)動的，所以變更任何配置都需要重啟 NGINX 服務(wù)才能生效，這在云原生時代是不能被企業(yè)接受的。這就是第一代 API 網(wǎng)關(guān)的技術(shù)痛點(diǎn)之一。
在中國，有一家類似微軟 office 365 的 SaaS 辦公軟件公司 -- wps，他們有數(shù)百臺物理機(jī)在運(yùn)行著 Apache APISIX，有近萬核 CPU 在處理來自客戶端的 API 請求，每天處理數(shù)百億次 API 請求。
在這個超大規(guī)模的 API 網(wǎng)關(guān)環(huán)境下，開發(fā)者不可能去逐個修改每一個 API 網(wǎng)關(guān)的配置然后 Reload，他們希望有一個統(tǒng)一的控制臺來操作整個集群。可惜的是，第一代 API 網(wǎng)關(guān)誕生的年代，并沒有這么大的實(shí)例規(guī)模，也就沒有考慮集群管理的需求。
下一代 API 網(wǎng)關(guān)的發(fā)展
上述挑戰(zhàn)和痛點(diǎn)，逐漸催生了新一代的 API 網(wǎng)關(guān)。
和第一代 API 網(wǎng)關(guān)不同的是，云原生時代誕生的下一代 API 網(wǎng)關(guān)是在開源社區(qū)的驅(qū)動下快速成長的。借助社區(qū)和眾多開源貢獻(xiàn)者的力量，這些 API 網(wǎng)關(guān)有機(jī)會形成一個正向的迭代和進(jìn)化：
-
更快速的收集一線開發(fā)者及用戶的需求和痛點(diǎn)
-
在開源項目中嘗試解決這些問題
-
開源項目變得更加好用，吸引更多開發(fā)者使用
于是，我們看到下一代 API 網(wǎng)關(guān)突破了傳統(tǒng)網(wǎng)關(guān)的負(fù)載均衡和反向代理的定位，而是承擔(dān)起了 API 和流量的連接、調(diào)度、過濾、分析、協(xié)議轉(zhuǎn)換、治理、集成等更多的職責(zé)。
支持更低成本的二次開發(fā)
同時，讓開發(fā)者能夠以更低的成本進(jìn)行二次開發(fā)，也成為了下一代 API 網(wǎng)關(guān)的亮點(diǎn)。集成是 API 網(wǎng)關(guān)的重要功能之一，對于下游是協(xié)議解析和各種協(xié)議的轉(zhuǎn)換，包括 GraphQL、gRPC、Dubbo 等；對于上游是集成 Okta、Keycloak、Datadog、Prometheus 等身份認(rèn)證、可觀測性服務(wù)，以及公司內(nèi)部的認(rèn)證、日志、審計等服務(wù)。API 網(wǎng)關(guān)不可能覆蓋集成過程中所有的組件，這時候不可避免地需要開發(fā)者通過插件的方式進(jìn)行二次開發(fā)，來滿足自己的業(yè)務(wù)需求。不同的 API 網(wǎng)關(guān)提供了不同的二次開發(fā)的編程語言和開發(fā)方式，Apache APISIX 和 Kong 都可以使用 Lua 來編寫原生插件，Envoy 是使用 C++ 編寫原生插件。同時，Apache APISIX 還可以使用 Go、Python/ target=_blank class=infotextkey>Python、Node、JAVA 和 Wasm 來編寫插件，這些主流的開發(fā)語言已經(jīng)可以覆蓋絕大部分開發(fā)者了。
開發(fā)者不必去學(xué)習(xí) Lua 和 C++，就可以使用自己熟悉的編程語言在下一代 API 網(wǎng)關(guān)上進(jìn)行開發(fā)，這讓基礎(chǔ)組件的開發(fā)變得更加簡單。開源和易于二次開發(fā)，是下一代的 API 網(wǎng)關(guān)最重要的特點(diǎn)，它把更多的選擇權(quán)留給了開發(fā)者自身，同時，開發(fā)者也可以更加放心的在多云、混合云的環(huán)境下使用 API 網(wǎng)關(guān)，不用擔(dān)心被云供應(yīng)商鎖定。
基于雙十一的 API 網(wǎng)關(guān)流量處理場景
這里，我們用一個具體的例子來解釋下現(xiàn)代 API 網(wǎng)關(guān)的作用。
在雙十一時，電商都會有各種各樣的商品促銷活動，這段時間的 API 請求量是平時的幾十倍。讓我們先來看下如果沒有 API 網(wǎng)關(guān)將會是怎樣的技術(shù)架構(gòu)：
可以看到，在 Order 和 Payment 服務(wù)中，身份認(rèn)證和日志記錄功能是重復(fù)的。一個電商的服務(wù)，一般會有數(shù)千個不同的服務(wù)組成，這時候就會有大量的代碼和功能是重復(fù)開發(fā)的。
下面是增加了 API 網(wǎng)關(guān)之后的架構(gòu)圖：
從上圖可以看到，我們在 API 網(wǎng)關(guān)層統(tǒng)一了公共的服務(wù)，后端服務(wù)只需要關(guān)心自身業(yè)務(wù)，為彈性伸縮提供了更多可能。
當(dāng)促銷開始時，客戶端大量 API 請求涌入 API 網(wǎng)關(guān)的時候，后端服務(wù)需要進(jìn)行快速的彈性伸縮，為了保障關(guān)鍵業(yè)務(wù)不受突發(fā)流量的影響，我們需要在 API 網(wǎng)關(guān)上識別惡意爬蟲并實(shí)現(xiàn)限流限速、服務(wù)降級和熔斷。此時，我們可以暫時關(guān)閉部分服務(wù)，比如商品評價、快遞查詢等。
但是庫存信息、購買功能、支付功能等核心業(yè)務(wù)是絕對不能出現(xiàn)故障的，因此我們需要通過 K8s 來管理容器服務(wù)，再生成更多的服務(wù)副本來保證它的正常運(yùn)行。此時 API 網(wǎng)關(guān)需要將客戶端的 API 請求路由到新生成的副本服務(wù)，并且自動移除出現(xiàn)故障的服務(wù)，如下圖所示。
總結(jié)
API 網(wǎng)關(guān)并不是一個新的基礎(chǔ)中間件，而是在產(chǎn)品快速迭代和技術(shù)架構(gòu)的變遷中，變得越來越重要。而下一代云原生 API 網(wǎng)關(guān)的出現(xiàn)則解決了企業(yè)用戶在集群管理，動態(tài)，生態(tài)，可觀測性以及安全性等方面的痛點(diǎn)。
API 網(wǎng)關(guān)不僅可以處理 API 的流量，也可以來處理 Kubernetes Ingress 和服務(wù)網(wǎng)格的流量，進(jìn)一步降低開發(fā)者的學(xué)習(xí)成本，幫助企業(yè)更好的統(tǒng)一管理流量。
