API網關與服務網格的區別

By Marco Palladino Feb 26, 2020

爲何稱API管理和服務網格是不同應用場景的互補模式

備註：本文的目標是提供一個備忘便籤，指導架構師決定何時使用API網關，何時使用服務網格。如果你想直接進入“備忘便籤”部分，請跳到最後。

多年來，採用API管理(APIM)以及API網關是數據中心內外部現代API用例的主要實現技術。API網關技術在過去十年中有了很大的發展，在業界所謂的“全生命週期API管理”中適用了更大、更全的應用環境。不僅在網絡請求的數據平面提供連接,保護和管理API流量的運行時，同時還在更廣泛的上下文中提供一系列的功能，如創建、測試、文檔、計費、監測和API整體暴露等。在請求從開始到結束的過程中，API網關還在尋求更廣泛的應用。換而言之，不僅僅是公開和使用API (RESTful或非RESTful)時的網絡運行時管理，API網關在力爭以產品的形式向用戶和客戶提供API創建到服務提供的完整生命週期能力。

然後在2017年前後，行業內出現了另一種模式:服務網格。幾乎在同時，業界都無法理解這種模式如何與API網關模式相互協同，導致了很大的混亂。這在一定程度上是由於現有APIM提供商完全沒有思想領導力，他們沒能對服務網格如何補充到現有APIM應用場景中做出充分的響應。也有部分原因是由於服務網格被雲服務供應商(首先是谷歌,其次是亞馬遜,最後是微軟) 推向了更廣泛的行業應用場景。在此過程中,這種新模式的市場影響力超出了實際主流用戶的應用,因此在業界形成了一個誤解：服務網格是軟件開發商的營銷口號，而非技術實現。使得它幾乎成爲了每個人都在談論但很少人掌握的神祕模型。

隨着時間的推移，服務網格的技術實現慢慢追上了它的最初設想，越來越多的用戶實現了該模式並講述他們的案例故事。這使我們可以從服務網格的視角更加客觀地理解服務網格和API網關(和APIM)的定義和區別。業界已經有人嘗試着描述API網關和服務網格之間的區別，他們通常認爲API網關用於南北向通信，而服務網格用於東西向通信。但我認爲這種理解並不準確，它在根本上誤解了這2種模式。在本文中，我將闡述API網關和服務網格之間的區別，以及用一種務實和客觀的方式來決定在何時使用這2種模式。

API網關

API網關模式被描述爲網絡中的一個額外端點，每個請求都必須經過這個端點才能使用底層的API。因此有人認爲API網關是集中式部署模式。

API網關位於每個API請求的執行路徑上，它屬於數據平面，接收來自客戶端的請求，將請求反向代理到底層API，並在此之前執行流量控制和用戶策略。在將請求代理回原始客戶端之前，它還可以響應底層API的指令，再次執行相應的策略。

API網關可包括一個內置的控制平面來管理和配置數據平面的工作。網關支持將數據平面和控制平面綁定到同一個進程中，但具有單獨的控制平面顯然會更好一些。有些API網關與DP + CP綁定在同一進程中，隨着已有的CI / CD管道執行情況的變化，所關聯部署API網關的節點數量通常具備彈性擴展和更新的能力，這種架構取得了不錯的應用效果。

API網關部署在它自己的實例中(自有的VM、主機或pod)，獨立於客戶端和API。由於完全獨立於系統的其它模塊運行，API網關部署非常簡單。

API網關通常覆蓋API的3種主要應用場景，適用於內部和外部服務連接，數據中心外部的南北向通信和數據中心內部的東西向通信。

1.將API做成產品

第一種情況是將API打包成產品，供其他的開發人員、合作伙伴或其他團隊調用消費。客戶端應用從企業外部(如移動應用)或企業內部(如其他產品，其他團隊開發或其他的產品線)發起請求。但無論哪種方式，客戶端應用都運行在所調用開放API產品的範圍之外。

當我們將API打包成產品來開放時，API網關將對來自客戶端到API服務之間的請求，提供通用功能的封裝和管理。這些功能包括AuthN/AuthZ認證、速率限制、在線開發、計費或客戶端應用治理等。這些由L7層用戶策略實現的高級功能，已經超越了底層協議的管理範圍，將決定用戶如何使用API產品。

API網關開放的大多數API運行是以HTTP協議爲主。根據客戶端應用所處在數據中心內部或外部的位置，請求的流量即可以是南北向，也可以是東西向的。通常情況下，外部的移動應用到API網關的流量是南北向，而組織內相同數據中心的其他產品到API網關的流程基本是東西向流量。從這個角度看，其實流量的方向根本無關緊要。

API網關還具備抽象層的用途，允許我們隨時更改底層API，而不必更新對應的的客戶端。對於那些由外部開發人員構建的客戶端應用，每次決定更新API時，都不太能強制要求對方更新到最穩定或最新的API接口，在這種情況下，可以使用API網關來保持與客戶端應用的向後兼容性，可以隨時調整底層的API，抽象層的優勢自然就非常明顯。

2.服務連接性

第二個應用場景是客戶端到API網關，API網關到底層API之間流量的網絡策略執行策略包括連接、保護、加密、保護和監控等。因爲對底層網絡流量進行操作，而不是控制用戶體驗，因此被稱爲L7層流量策略。

API網關收到並處理某個請求後，網關本身會向底層API發送請求以獲得對請求的響應(網關本質就是反向代理)。通常我們傾向於採用雙向TLS來保護請求，記錄請求，並全面保護和監控網絡通信。網關還充當負載均衡器的角色，提供HTTP路由、支持將請求分發到不同版本API(支持藍/綠和金絲雀部署的使用場景)，以及故障注入等功能。

API網關並不關心底層API的構建和接口暴露，因此無論是單體架構或微服務架構的系統都可以通過API網關開放底層API。大多數的API接口都是基於HTTP協議，如REST、SOAP、GraphQL或gRPC等。

3.API全生命週期管理

關於API網關的第三種應用場景是API的全生命週期管理。

我們都知道，運行時狀態下，管理API、用戶、客戶端應用以及接口流量只是成功運行一個API所需涉及衆多步驟的一部分而已。其他的部分還包括API接口的創建、記錄、測試和模擬等。API運行起來後，還必須監視和觀察，以檢測是否存在異常情況。此外，將API以產品的方式對外提供時，還必須爲最終用戶提供門戶來註冊應用、獲取身份憑據和消費API等等。

基於端到端的過程，API生命週期中的各個環節相互交織的（準確講是不同角色負責不同的節點)經驗看,上述內容可稱爲全生命週期的API管理。大多數高效的APIM解決方案都會提供一個解決方案集，通過一個或多個產品落實每個概念環節,從而全面實現API網關上的策略執行。

服務網格

我們所運行系統，在包含兩個及以上的服務環境下，服務網格從根本上爲我們展示了構建服務到服務的連接性模式。每當一個服務希望向另外的服務發送如讀寫數據庫或微服務間訪問的請求時，我們都希望能讓這些請求更安全、更可觀察等等。

服務網格作爲一種模式可以應用於包括單體架構或微服務在內的任何架構和包括虛擬機，容器，Kubernetes在內的任何平臺。

服務網格在網絡請求管理上，其實並沒有引入新的技術應用，但它把我們之前已經採用的方法應用得更好。甚至在採用服務網格模式之前，有些開發團隊就已經在應用程序中實現了諸如安全性、可觀察性和錯誤處理等流量策略。他們可以通過在服務中編寫額外的代碼來實現這些策略，從而加固應用所收發的任何出站或入站網絡請求的連接性。但這也意味着不同的開發團隊要採用各自的編程語言重複造輪子，並因此創建額外的模塊和帶來管理安全風險。

在服務網格之前，開發人員需編寫代碼和維護管理到第三方服務的網絡連接，爲支持對端不同的語言/框架而採用不同的實現方法。

在服務網格模式裏, 我們將任何入站或出站請求的網絡管理，不管是我們創建的，還是第3方創建我們部署的，都剝離出去，交給獨立的應用代理處理。由於應用代理是獨立部署的，因此，它默認就具備便攜性和應用無關性，能夠支持不同開發語言/框架的服務。代理運行在每個請求的執行路徑上，屬於數據平面處理過程。鑑於端到端mTLS加密和可觀察性的情況,服務網格設計爲每個服務伴隨部署一個代理實例，來無縫地滿足這些需求特性，而無需應用開發團隊自己做特例處理。

由於這個數據平面級代理與服務的每個副本一起運行。因此有人將服務網格稱爲去中心化部署(對應集中式部署的API網關)。此外，由於代理在網絡中增加了額外的躍點，爲了能保持最小的網絡延遲，需要與服務部署在相同的機器上(如VM、主機、pod)。理想情況下，如果代理的優勢應用得當，延遲足夠低，那麼在管理服務間的網絡連接方面，大家就會傾向於使用代理，而不是自有組件。

由於爲服務的每個副本都運行一個應用代理實例，所以應用代理扮演了出站請求代理和入站請求反向代理的雙重角色。也因此在系統中運行着許多代理。爲了對它們進行配置管理，就需要一個控制平面作爲執行配置和動作執行的可信源，並能夠動態地對代理做配置廣播。且控制平面只能連接代理，所以它不能處於服務間請求的執行路徑上。

服務網格模式比API網關模式更具侵入性。因爲它要求在數據平面爲每個服務實例伴隨部署一個代理，在部署應用程序時需大量更新CI/CD作業。雖然服務網格還有其他的部署模式，但是每個服務副本一個代理的模式被認爲是行業標準，因爲它保證了最好的、最高的可用性，並允許我們爲每個服務的每個副本分配唯一的身份憑證(mTLS證書)。

綜上所述，我們通過使用服務網格，在根本上解決了服務間調用的主要問題。

服務連接性

通過將網絡管理剝離給第三方代理應用程序，免去了開發團隊在自有服務內實現網絡管理的開發量。代理可以爲我們部署的每個服務、工作負載、數據庫及第三方服務提供雙向TLS加密、憑證、路由、日誌記錄、跟蹤、負載平衡等功能。

由於組織內的服務連接運行了大量的協議類型，因此理想情況下，一個完整的服務網格不僅支持HTTP協議，還需支持其他任意的TCP流量，無論它是南北向還是東西向的流量。因此服務網格需支持更廣泛的服務，並實現L4/L7流量策略，而API網關向來只是關注L7層策略。

從概念上看，對於系統中運行的工作負載，服務網格具有一個非常簡單的視圖:任何對象都是一個服務，且服務之間可以相互通信。因爲API網關也是接收請求和發出請求的服務，所以API網關也可稱爲是網格中的一個服務。

因爲每個服務的每個副本都需要一個與之相伴的數據平面代理，且這個數據平面代理是一個非常有效的客戶端負載均衡,他們將出站請求路由到其他代理。服務網格的控制平面必須知道每個代理的地址,以便可以執行L4 /L7層的請求路由功能，代理地址還可以與服務名之類的任何元數據相關聯。通過這樣做，服務網格原生內置了一個服務發現工具，而無需藉助第三方解決方案。服務發現工具還可以用於與網格外部進行通信，但通常不會用於指向網格內部的通信。

API 網關 vs. 服務網格

通過使用場景，可以清楚地發現API網關和服務網格在服務連接性的應用區域是重疊的。

服務網格提供的服務連接性功能與API網關提供的API連接性功能相沖突。但服務網格提供的服務更具有包容性，覆蓋了L4 和 L7層，支持所有的TCP流量，包涵且不限於HTTP協議和API類型等，所以它在某種程度上更爲完整。然而，正如我們從上圖表中可以看到的，服務網格也有不具備的能力，即API網關模式的“產品形態API”和API全生命週期管理。

由於服務網格爲更廣泛的使用場景(L4+L7)滿足了所有的服務連接性需求，所以。我們很自然地會認爲它將在這個領域取代僅支持L7層的API網關。這個結論有效的前提是我們能夠利用好服務網格部署模型。恰如我們所探討的內容，但情況並不總是如此。

這兩種模式之間的一個主要不同點實際上是部署模型:在服務網格模式中，我們必須在每個服務的每個副本旁邊部署一個數據平面代理。當團隊想要在自己的產品範圍內或者自己的業務範圍內部署服務網格時，這很容易做到，但是當我們想要在這個範圍之外部署代理時，實現起來就會困難很多，原因有如下四點:

將應用代理部署到組織中每個產品的每個服務旁邊可能會遇到阻力，因爲不同的產品、團隊和業務線可能在應用構建、運行和部署存在根本上的差異。
每個數據平面代理鬚髮起一個到控制平面的請求,這在某些情況下,是我們不希望或者做不到的，因爲這需要在組織內爲產品，團隊和業務範圍外的服務提供到控制平面的訪問授權。
不可能在每個服務的旁邊部署代理數據平面，首先是因爲我們不能控制所有的服務，例如由開發人員、客戶或組織外部的合作伙伴所構建的第三方應用程序。
在相同服務網格中部署的服務必須使用相同的CA(證書頒發機構)，這樣才能獲得相互驗證的有效TLS證書。而在不同產品或團隊的服務之間共享CA幾乎是不可能，且不可取的。在這種情況下，可以考慮創建兩個獨立的服務網格，每個服務網格採用各自的CA，然後通過中間API網關相互通信。

鑑於API網關和服務網格關注不同的使用情況,我推薦一個備忘便籤可以確定何時使用API網關或服務網格。這個便籤假定在大多數組織中,會因產品、用戶場景和服務連接性的不同，而用到2種模式中的一種。

備忘便籤

我們將提供產品化API作爲流向判斷的中心點入口，在此之後，我們按向/外部的客戶端或用戶區分，提供API網關。通過全生命週期APIM平臺，來管理和控制API的暴露、服務運營、以及建立客戶端與底層API之間的抽象層。

在用戶的系統內的所有服務之間，我們將使用服務網格建立可靠、安全和可觀察的L4/L7流量連接。服務網格採用了適配任何服務的去中心化sidecar部署模型，可在所有服務之間創建點對點連接。企業很大可能是同時擁有這兩個使用場景，因此將同時使用API網關和服務網格。

案例:金融機構

根據上面的便籤圖表，我們可以提供以下案例。

對於一個組織來說，由不同的團隊構建不同的產品，而這些產品必須相互通信的情況是很常見的。例如，金融機構需要有一個處理銀行事務的“銀行產品”和一個從事股票市場交易的“交易產品”，這兩個產品必須通過通信來共享信息。

開發團隊將在產品路線圖中的某點上決定實現服務網格，以優化最終產品內服務之間的服務連接性。因爲不同的團隊，進展速度不同，他們將採用兩個獨立的服務網格:“服務網格A”和“服務網格B”。

假設爲了獲得高可用性，這兩個產品都部署在兩個數據中心“DC1”和“DC2”中。銀行產品團隊希望將其服務作爲產品提供給內部客戶，即交易團隊。因此，他們考慮通過策略配置，將交易團隊視同於採用內部API網關的用戶。移動團隊也必須消費這兩種產品，他們將通過edge API網關入口做到請求訪問的可達。整個架構大致如下: