導讀：

之前提過要做一個 API 閘道器的介紹，事實上，無論是微服務、服務網格，還是雲原生、數字化的建設，API 閘道器都是繞不開的話題。介於網上對於 API 閘道器的介紹參差不齊，所以今天我們不再簡單的做 API 閘道器基礎知識與功能介紹，而是直切要點，聊聊 ESB、ServiceMesh、 微服務與 API 閘道器的關係。

01

API 閘道器的核心

隨著微服務場景的普遍運用，API 閘道器也逐漸被大家所重視，聚合介面、聚合服務以提供前端呼叫、業務封裝，這是 API 閘道器的主要場景。

API 閘道器處於業務內外通訊或系統前後端的橋樑，功能上除了建立通訊、路由轉發以外，也承擔了許多非業務的功能，比如安全、流控、過濾、快取、監控等；在服務化模式下，也會增加一些運營的功能，比如 API 管理、計量計費、服務訂閱等等。

可見，在 API 閘道器上我們可以做很多文章，只因它對流量做了承接和轉發，這也是 API 閘道器的核心。

這樣的角色並不陌生，在我之前的兩篇文章中提到的ESB、ServiceMesh都有藉助流量的承接轉發功能，然後形成的解決方案。同一件工具，被置於不同的位置，就有其不同的形態，API 閘道器就是這樣的工具。

02

API與ESB 、ServiceMesh、微服務的關係

替代ESB的場景

ESB 沒必要再做深入的介紹了，其核心也是路由、轉發、轉換、流控。在當下ESB 逐步退出數字化的舞臺的同時，多數企業也在思考如何通過一個替代品逐步替換 ESB，我們博雲就在多個專案中分別通過微服務框架、服務網格框架做出過多種平滑接替 ESB 的方案和功能。同時覆蓋其原有的路由轉發、協議轉換、限流控制的功能，最直接的方案就是通過 API 閘道器實現。

ESB 的架構，同時承擔了東西向服務間的訪問控制，和南北向流量的控制。而使用了 API 閘道器的方案就顯得更加靈活了，其可大可小的體量、動態配置的靈活特性、自服務的消費模式，都更能符合多變多樣化的新型數字架構。如果規劃得當，API 閘道器在替代 ESB 的同時，也可以作為整個網路域內，甚至整個企業級的閘道器，這也就是服務中臺化的第一步。

服務網格中的應用

ServiceMesh 的理念其實很容易理解，通過一個代理服務，將所有的流量接管，同時將非業務的治理、監控等功能，都通過代理服務實現。那麼這個代理服務（proxy），就是 API 閘道器的另一個運用場景。劫持流量，然後加入所需的定製化功能。

與其他場景相比，這裡的閘道器功能上沒有太大的變動，但是使用位置卻有很大差別。在 ServiceMesh 場景中，閘道器是一個很小很輕量的代理單元，而每個業務執行單元都會搭載該代理單元共同啟動，所以在 ServiceMesh 場景中，通常叫做邊車（Sidecar）。也就是說 ServiceMesh 中的 Sidecar 就是一個 API 閘道器的應用，比如 Istio 框架下，資料面 Sidecar 就是 Envoy（基於C++語言的 API 閘道器）。

微服務閘道器

值得一提的是微服務場景下的 API 閘道器，這種場景難道不是最基本的運用嗎？其實不然，微服務閘道器也是對 API 閘道器的場景化改造後的結果，比如SpringcloudGateway、Zuul 這兩種是基於 netty 框架的 Java 語言開發的微服務閘道器，主要在 Springcloud 微服務的場景下使用。

微服務場景下，服務間通訊的定址都需要依賴於註冊中心，微服務閘道器做路由轉發的時候，上游地址也需要從註冊中心獲取，同時微服務訪問閘道器的時候也可以直接通過註冊中心定址，因此微服務閘道器需要符合微服務框架的註冊與發現機制。

03

總結

三種閘道器核心都是通訊的代理和轉發，替代 ESB 的時候帶上協議轉換的特性，對接微服務的時候增加註冊中心同步的功能，做為 Sidecar 的時候需要做流量劫持以及控制面的通訊。另外還有沒提到 API 市場的場景，這種場景就需要補充計量計費等功能了。

所以根據不同的使用場景、不同的運用方式，依賴於 API 閘道器都可以自由調整。在我們博雲內部，就至少涉及了三種閘道器和多種場景的使用。

• 第一種：企業級的 API 閘道器，主要注重服務能力的提供，承接全企業的流量，因此對於閘道器的效能有極高的要求。我們採用的元件是基於openresty+lua 的 kong 來解決，效能上保證全企業的互動壓力。

• 第二種：微服務的閘道器，主要是微服務的封裝，但是不是重點和難點，通過很多個專案的交付發現，微服務的需求容易滿足，而過渡方案比較難。所謂過渡方案是指非微服務的應用，在需要與微服務應用統一治理時，通過 API 閘道器做的 Sidecar 方案。我們博雲內部採用的是 SpringcloudGateway，並在其上做協議轉換、服務檢測等功能，實現對單體應用、傳統架構系統的統一納管和治理。

• 第三種：服務網格，主要是資料面 Sidecar 部分，與之上的區別是，之上的微服務框架基本已經確定是 Springcloud，而服務網格本在我們博雲內部採用的是 Istio 框架，Istio 框架下 Sidecar 採用的是 Envoy 。我們在 Envoy 上拓展 ESB 的場景、傳統架構相容的場景，並增加協議支援、協議轉換、資料收集、鏈路收集等功能，以實現複雜的微服務轉型需求。

陣而後戰，兵法之常，運用之妙，存乎一心。API 閘道器的技術已經幾於成熟，在合適的場景下合理的運用將會發揮極大的作用。