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