微服務架構的外部 API 整合模式

今天我們來聊聊API整合，通過前兩天的瞭解，我們瞭解到微服務是多服務，松耦合的服務集，既然涉及到了多服務，呼叫外部的API的必不可少的。

由於客戶的多樣性，設計應用程式的外部 API 變得更具有挑戰性。這些客戶端通常具有不同的資料要求。

1、直接溝通

這種方式以客戶端直接呼叫服務的方式設計 API。由於以下缺點，微服務架構目前很少採用這種方法。

客戶端必須通過細粒度的服務 API 發出多個請求來檢索他們需要的資料，這不僅效率低下，而且可能導致比較差的使用者體驗。

由於客戶端對每個服務及其 API 的瞭解導致缺乏封裝，因此很難更改架構和 API。

客戶可能覺得使用服務的 IPC 機制既不方便也不實用。

我們在研發的時候，不能把保持向後相容性留給後端服務的開發人員。需要開發單獨的公共 API，而不是直接向第三方公開服務。

這項艱難的工作就是由API 閘道器的架構元件完成的。

2、API 閘道器模式

直接訪問服務有許多缺點。API 閘道器是一種更好服務訪問模式。

基本上，API 閘道器也是一種服務，它充當外部應用程式的入口點。該元件負責請求路由、API 組合和其他橫切關注點，例如身份驗證、監控和速率限制。API 閘道器類似於 OOPS(設計模式) 中的外觀設計模式。API 閘道器封裝應用程式的內部架構並向其客戶端提供 API。

API 閘道器還負責請求路由、API 組合和協議轉換。來自外部客戶端的 API 請求通過 API 閘道器，API閘道器將一些請求路由到相應的服務。API 閘道器還可以通過呼叫多個服務並聚合結果來處理其他請求。伺服器還可以在客戶端友好協議（例如 HTTP 和 WebSockets）與服務使用的客戶端不友好協議之間進行轉換。

3、請求路由

請求路由是 API 閘道器最重要的功能之一。API 閘道器通過將請求路由到適當的服務來實現 API 操作。API 閘道器在收到請求時查詢路由對映以確定將請求路由到哪個服務。例如，路由對映可能會將 HTTP 方法和路徑對映到服務的 HTTP URL。NGINX 等 Web 伺服器提供反向代理作為此功能的一部分。

4、API 組成

API 閘道器通常不僅僅做反向代理。他們還可以使用 API 組合執行 API 操作。API 閘道器為客戶端提供了一個粗粒度的 API，使他們能夠通過一個請求來檢索他們需要的資料。

聚合器/組合模式有兩個子模式。

• 鏈式模式：基本上，這種型別的組合模式遵循鏈式結構。在這種模式下，客戶端與服務通訊，所有服務連結在一起，一個服務的輸出成為下一個服務的輸入。
• 分支模式：分支模式是聚合器和鏈模式的擴充套件版本。客戶端可以直接與服務通訊，在這種設計模式下，服務可以同時與多個服務通訊。

5、協議轉換

API 閘道器也可以轉換協議。儘管應用程式服務在內部使用各種協議，包括 REST 和 gRPC，但它可能會向外部客戶端提供 REST API。一些 API 操作在需要時在 RESTful 外部 API 和內部基於 gRPC 的 API 之間進行轉換。

國外一些技術網站，把這項功能直接稱為：Protocol Translation，直接翻譯就是：協議翻譯，我根據能力直接叫做：協議轉換

6、前端模式的後端

API 閘道器可以提供一個通用的 API。單一 API 面臨的一個問題是不同的客戶端通常有不同的需求。這個問題的解決方案是讓客戶端可以選擇在請求中指定伺服器應該返回哪些欄位和相關物件，就像使用 GraphQL 一樣。對於必須為第三方應用程式提供服務的公共 API，這種方法就足夠了，但它不能為客戶提供更多可選的操作。

通過API閘道器為客戶端提供個性化API是一個不錯的選擇，我也比較喜歡這個能力，從一定程度上減少了通訊資料的壓力

7、實施橫切關注點

API 閘道器主要處理 API 路由和組合，但它們也可能處理橫切關注點。橫切關注點的例子包括：

• 身份驗證 ： 驗證發出請求的客戶端身份。
• 授權：驗證客戶端是否被授權執行該特定操作。
• 速率限制：限制每秒來自特定客戶端或所有客戶端的請求數。
• 快取：快取響應以減少對服務的請求數量。
• 指標收集：為計費分析目的收集 API 使用指標。
• 請求日誌記錄：記錄請求。

注：橫切關注點指的是一些具有橫越多個模組的行為，使用傳統的軟體開發方法不能夠達到有效的模組化的一類特殊關注點。比如典型的案例，日誌功能

8、API 閘道器架構

API 閘道器具有分層的模組化架構。它由兩層組成，API 層和公共層。一個或多個 API 模組構成 API 層。API 模組根據客戶要求實現 API。

9、API 閘道器的好處

使用 API 閘道器的主要優點是它封裝了應用程式的內部結構。

API 閘道器為客戶端提供客戶端特定的 API，減少客戶端和應用程式之間的往返次數

簡化了客戶端程式碼。

10、API閘道器的缺點

增加維護成本，也是一個可開發、部署和管理的高可用性元件。

API 閘道器有可能成為開發瓶頸，因為開發人員必須不時更新 API 閘道器以公開他們的服務 API。

11、現成的 API 閘道器

有幾種現成的服務和產品實現了 API 閘道器功能。

• AWS API Gateway  ： AWS API Gateway API 是一組 REST 資源，每個資源都支援一個或多個 HTTP 方法。您可以配置 API 閘道器以將每個請求路由到後端服務。您需要在後端服務中實現 API 組合，AWS API Gateway**不支援 API 組合。
• Kong ：  Kong基於 NGINX HTTP 伺服器，它允許您根據 HTTP 方法、標頭和路徑定義靈活的路由規則，以決定使用哪個後端服務。

12、開發 API 閘道器

使用 Web 框架，您可以構建自己的 API 閘道器，將請求代理到其他服務。我們來看看Netflix Zuul和Spring Cloud Gateway。

• Netflix Zuul  ：  Zuul是一個 Netflix 框架，它實現了諸如路由、速率限制和身份驗證等橫切功能。Zuul 使用了過濾器的概念，過濾器是類似於 servlet 過濾器的可重用請求攔截器。Zuul 通過組裝一系列過濾器來處理 HTTP 請求，這些過濾器會轉換請求、呼叫後端服務並將響應傳送到客戶端之前對其進行轉換。
• Spring Cloud Gateway  ：  Spring Cloud Gateway是一個 API 閘道器框架，基於 Spring Framework、Spring Boot 和 Spring Webflux，一個反應式 Web 框架。

Spring Cloud Gateway 提供了一種簡單而全面的方式來完成以下任務：

• 將請求路由到後端服務。
• 實現執行 API 組合的請求處理程式。
• 處理橫切關注點，例如身份驗證。