本文來自CSDN，作者/溫銘。
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)和集群化管理
容器和Kubernetes的普及，讓動態(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、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)一管理流量。
