在過去幾年中，我們看到了雲原生模式的興起，這種模式映射到以容器形式運行的微服務。這些容器可能運行在一個普遍存在且廣為人知的平臺上，即Kubernetes，簡稱K8S。

什麼是API？

API代錶應用程序可編程接口。這意味著您有一個與應用程序部分交互的界面，以便您可以：

• 檢索要存儲在某個存儲庫中的對象或數據
• 收集應用程序子組件的指標，以了解應用程序的運行狀况
• 操縱應用程序的特定部分以執行特定操作
• 利用應用程序為您的應用程序做一些事情
• 開發並提供您自己的定制前端，以利用另一個應用程序作為後端

當您可以訪問一個應用程序和它的較小部分時，您就可以靈活地利用所需的部分。如果您擁有該應用程序，微服務由於其解耦性質更容易更改。API網關有助於實現這種解耦。

什麼是API網關？

API網關是一個系統，它接受對API資源或應用程序後端的傳入請求。如果您熟悉網絡網關或路由器，其概念類似於網關接受請求並指向目的地。API網關比特於第7層，這意味著它可以感知第7層並監視HTTP等請求。作為網關，它必須為入站請求提供策略，以確保：

• 經過身份驗證的安全請求
• 請求被適當地路由
• 請求僅限於維持服務可用性（在大規模情况下）
• 代理
• 監測

什麼是服務網格？

服務網格是一個旨在提供服務端點或微服務的系統，這是一種相互通信的安全方式。它也是一個系統，用於控制應用程序不同部分的入口和負載平衡。在這種方法中，數據平面分布在服務端點附近。然後，數據平面由控制平面指導和管理，以實施各種策略，這些策略用於：

流量管理：

• 讓我們把流量路線安排到預定的目的地
• 讓我們將流量路由到提供相同輸出和結果的備用目的地
• 讓我們在延遲增加的情况下中斷電路，繞過服務
• 我們可以將工作負載分配到不同的環境，並且仍然可以到達這些環境
• 讓我們繼續部署不同版本的應用程序並獲得反饋（金絲雀、藍綠色部署）

安全：

• 讓我們用MTL加密可信端點的通信
• 讓我們阻止不必要或非法的請求

可觀測性：

• 服務發現
• 我們能看到什麼？
• 當我們看到出現問題時，會采取哪些自動化步驟來解决？
• 我們能追踪端點，看看哪裏出了問題嗎？

對於Kubernetes，我們遵循一種側車模式，其中部署了一個輔助側車容器，它是服務網格的數據平面。該pod的主應用程序容器將通過Service Mesh數據平面容器發送其流量，該容器由Service Mesh控制平面pod/容器控制，這些pod/容器通常比特於不同名稱空間的同一集群中。

服務網格可以擴展到直接負載平衡器和DNS，這樣應用程序就可以跨多個提供商分布。

我還必須提到let，它代錶延遲、錯誤、流量和飽和，ServiceMesh希望觀察並采取行動。

API網格和服務網格圖：

此圖的目的是說明請求者、API網關和/或服務網格與微服務之間高層的各種流量。

兩者產品比較：

它們有何不同？

API網關作為一個系統，需要確定入站請求是否合法並指向預期目的地。使用API網關將應用程序的端點公開給其他應用程序的其他部分使用。另一方面，盡管提供了入口點，但ServiceMesh更關注於建立、保護和監控點對點通信。這聽起來像一個VPN。

它們有什麼相似之處？

兩者的相似之處在於，它們控制著通往預定目的地的流量。它們都可以識別流量可能是什麼，以及流量中包含的內容。根據這些細節，API網關和服務網格可以破譯可能發生的情况。最重要的是，兩者都在第7層運行。

兩者可以協同使用嗎？

是的，雖然可能存在一些重疊，但每個重疊的目的都是從請求的角度控制和操縱流量。在未來，我懷疑您將開始看到API管理和網關與服務網格相結合的組合產品，以捕獲南北和東西交通流和模式。這可能是為了避免“泳道”的完全混亂和沖突，同時提供一體化體驗。

我們的目標是解决什麼？

我們的目標是解决服務端點之間的連接問題，同時保護應用程序API的入口點。這使我們能够更好地解耦微服務，提供更好的生命周期操作，並使用新代碼和功能不斷迭代應用程序。這兩種技術都可以防止消費者注意到任何停機、停機或可用性問題。

一個很好的例子是Uber或UberEats，它們都使用穀歌地圖API，但將通過API網關實現，主要是因為希望“rate-limit”，而不是地圖API成本過高。

利用服務網格的一個例子是，客戶機正在考慮將容器化工作負載從一個雲提供商移動到另一個雲提供商。遷移是一個技巧，需要通過三件事來處理：

• 同一應用程序的新部署
• 引導流量的負載平衡器（來自服務網格的方向）
• 域名服務器

通過服務網格實現這三個目標，應用程序可以無縫遷移。還有，因為Kubernetes 不在乎。同樣的方法也可以用於應用程序新版本的Canary部署，其中一部分流量請求被定向到該新版本，而大多數請求則轉到舊版本。這同樣適用於藍綠色部署。這同樣適用於這些Docker化工作負載的高可用性和灾難恢複。也許，我們正在從部署應用程序遷移到一組虛擬機，而服務網格可以為我們提供便利。

如何開始？

API Gateway:

• SpringCloud Gateway — https://spring.io/projects/spring-cloud-gateway
• Kong API Gateway — https://docs.konghq.com/gateway-oss/2.5.x/getting-started/quickstart/
• Tyk API Gateway — https://tyk.io/sign-up/

服務網格Service Mesh

• Istio — https://istio.io/latest/docs/setup/getting-started/
• Linkerd — https://linkerd.io/2.10/getting-started/
• Kuma — https://konghq.com/blog/getting-started-kuma-service-mesh/

結論

雖然API網關和服務網格已經存在了一段時間，但我注意到這些技術有了很大的提昇。原因有很多，但最常見的是：

• 利用微服務模式
• 保護微服務
• 縮放它們
• 觀察它們
• 與他們互動
• 操縱它們
• 在不影響請求者的情况下修改它們
• 分發

在不久的將來，我們可能會看到通過企業產品將兩者合並。我們甚至可以看到ServiceMesh如何保護用戶端點，這可能會重新定義我們處理VPN解决方案和最終用戶連接的方式。