今天我們來聊聊API集成，通過前兩天的了解，我們了解到微服務(wù)是多服務(wù)，松耦合的服務(wù)集，既然涉及到了多服務(wù)，調(diào)用外部的API的必不可少的。

由于客戶的多樣性，設(shè)計應(yīng)用程序的外部 API 變得更具有挑戰(zhàn)性。這些客戶端通常具有不同的數(shù)據(jù)要求。

1、直接溝通

這種方式以客戶端直接調(diào)用服務(wù)的方式設(shè)計 API。由于以下缺點，微服務(wù)架構(gòu)目前很少采用這種方法。

• 客戶端必須通過細粒度的服務(wù) API 發(fā)出多個請求來檢索他們需要的數(shù)據(jù)，這不僅效率低下，而且可能導(dǎo)致比較差的用戶體驗。
• 由于客戶端對每個服務(wù)及其 API 的了解導(dǎo)致缺乏封裝，因此很難更改架構(gòu)和 API。
• 客戶可能覺得使用服務(wù)的 IPC 機制既不方便也不實用。

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

這項艱難的工作就是由API 網(wǎng)關(guān)的架構(gòu)組件完成的。

2、API 網(wǎng)關(guān)模式

直接訪問服務(wù)有許多缺點。API 網(wǎng)關(guān)是一種更好服務(wù)訪問模式。

基本上，API 網(wǎng)關(guān)也是一種服務(wù)，它充當外部應(yīng)用程序的入口點。該組件負責請求路由、API 組合和其他橫切關(guān)注點，例如身份驗證、監(jiān)控和速率限制。API 網(wǎng)關(guān)類似于 OOPS(設(shè)計模式) 中的外觀設(shè)計模式。API 網(wǎng)關(guān)封裝應(yīng)用程序的內(nèi)部架構(gòu)并向其客戶端提供 API。

API 網(wǎng)關(guān)還負責請求路由、API 組合和協(xié)議轉(zhuǎn)換。來自外部客戶端的 API 請求通過 API 網(wǎng)關(guān)，API網(wǎng)關(guān)將一些請求路由到相應(yīng)的服務(wù)。API 網(wǎng)關(guān)還可以通過調(diào)用多個服務(wù)并聚合結(jié)果來處理其他請求。服務(wù)器還可以在客戶端友好協(xié)議（例如 HTTP 和 WebSockets）與服務(wù)使用的客戶端不友好協(xié)議之間進行轉(zhuǎn)換。

3、請求路由

請求路由是 API 網(wǎng)關(guān)最重要的功能之一。API 網(wǎng)關(guān)通過將請求路由到適當?shù)姆?wù)來實現(xiàn) API 操作。API 網(wǎng)關(guān)在收到請求時查詢路由映射以確定將請求路由到哪個服務(wù)。例如，路由映射可能會將 HTTP 方法和路徑映射到服務(wù)的 HTTP URL。NGINX 等 Web 服務(wù)器提供反向代理作為此功能的一部分。

4、API 組成

API 網(wǎng)關(guān)通常不僅僅做反向代理。他們還可以使用 API 組合執(zhí)行 API 操作。API 網(wǎng)關(guān)為客戶端提供了一個粗粒度的 API，使他們能夠通過一個請求來檢索他們需要的數(shù)據(jù)。

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

1. 鏈式模式：基本上，這種類型的組合模式遵循鏈式結(jié)構(gòu)。在這種模式下，客戶端與服務(wù)通信，所有服務(wù)鏈接在一起，一個服務(wù)的輸出成為下一個服務(wù)的輸入。
2. 分支模式：分支模式是聚合器和鏈模式的擴展版本?？蛻舳丝梢灾苯优c服務(wù)通信，在這種設(shè)計模式下，服務(wù)可以同時與多個服務(wù)通信。

5、協(xié)議轉(zhuǎn)換

API 網(wǎng)關(guān)也可以轉(zhuǎn)換協(xié)議。盡管應(yīng)用程序服務(wù)在內(nèi)部使用各種協(xié)議，包括 REST 和 gRPC，但它可能會向外部客戶端提供 REST API。一些 API 操作在需要時在 RESTful 外部 API 和內(nèi)部基于 gRPC 的 API 之間進行轉(zhuǎn)換。

國外一些技術(shù)網(wǎng)站，把這項功能直接稱為：Protocol Translation，直接翻譯就是：協(xié)議翻譯，我根據(jù)能力直接叫做：協(xié)議轉(zhuǎn)換

6、前端模式的后端

API 網(wǎng)關(guān)可以提供一個通用的 API。單一 API 面臨的一個問題是不同的客戶端通常有不同的需求。這個問題的解決方案是讓客戶端可以選擇在請求中指定服務(wù)器應(yīng)該返回哪些字段和相關(guān)對象，就像使用 GraphQL 一樣。對于必須為第三方應(yīng)用程序提供服務(wù)的公共 API，這種方法就足夠了，但它不能為客戶提供更多可選的操作。

通過API網(wǎng)關(guān)為客戶端提供個性化API是一個不錯的選擇，我也比較喜歡這個能力，從一定程度上減少了通訊數(shù)據(jù)的壓力

7、實施橫切關(guān)注點

API 網(wǎng)關(guān)主要處理 API 路由和組合，但它們也可能處理橫切關(guān)注點。橫切關(guān)注點的例子包括：

• 身份驗證： 驗證發(fā)出請求的客戶端身份。
• 授權(quán)：驗證客戶端是否被授權(quán)執(zhí)行該特定操作。
• 速率限制：限制每秒來自特定客戶端或所有客戶端的請求數(shù)。
• 緩存：緩存響應(yīng)以減少對服務(wù)的請求數(shù)量。
• 指標收集：為計費分析目的收集 API 使用指標。
• 請求日志記錄：記錄請求。

注：橫切關(guān)注點指的是一些具有橫越多個模塊的行為，使用傳統(tǒng)的軟件開發(fā)方法不能夠達到有效的模塊化的一類特殊關(guān)注點。比如典型的案例，日志功能

8、API 網(wǎng)關(guān)架構(gòu)

API 網(wǎng)關(guān)具有分層的模塊化架構(gòu)。它由兩層組成，API 層和公共層。一個或多個 API 模塊構(gòu)成 API 層。API 模塊根據(jù)客戶要求實現(xiàn) API。

9、API 網(wǎng)關(guān)的好處

• 使用 API 網(wǎng)關(guān)的主要優(yōu)點是它封裝了應(yīng)用程序的內(nèi)部結(jié)構(gòu)。
• API 網(wǎng)關(guān)為客戶端提供客戶端特定的 API，減少客戶端和應(yīng)用程序之間的往返次數(shù)
• 簡化了客戶端代碼。

10、API網(wǎng)關(guān)的缺點

• 增加維護成本，也是一個可開發(fā)、部署和管理的高可用性組件。
• API 網(wǎng)關(guān)有可能成為開發(fā)瓶頸，因為開發(fā)人員必須不時更新 API 網(wǎng)關(guān)以公開他們的服務(wù) API。

11、現(xiàn)成的 API 網(wǎng)關(guān)

有幾種現(xiàn)成的服務(wù)和產(chǎn)品實現(xiàn)了 API 網(wǎng)關(guān)功能。

AWS API Gateway? ： AWS API Gateway API 是一組 REST 資源，每個資源都支持一個或多個 HTTP 方法。您可以配置 API 網(wǎng)關(guān)以將每個請求路由到后端服務(wù)。您需要在后端服務(wù)中實現(xiàn) API 組合，AWS API Gateway**不支持 API 組合。

Kong ：? Kong基于 NGINX HTTP 服務(wù)器，它允許您根據(jù) HTTP 方法、標頭和路徑定義靈活的路由規(guī)則，以決定使用哪個后端服務(wù)。

12、開發(fā) API 網(wǎng)關(guān)

使用 Web 框架，您可以構(gòu)建自己的 API 網(wǎng)關(guān)，將請求代理到其他服務(wù)。我們來看看Netflix Zuul和Spring Cloud Gateway。

Netflix Zuul? ：? Zuul是一個 Netflix 框架，它實現(xiàn)了諸如路由、速率限制和身份驗證等橫切功能。Zuul 使用了過濾器的概念，過濾器是類似于 servlet 過濾器的可重用請求攔截器。Zuul 通過組裝一系列過濾器來處理 HTTP 請求，這些過濾器會轉(zhuǎn)換請求、調(diào)用后端服務(wù)并將響應(yīng)發(fā)送到客戶端之前對其進行轉(zhuǎn)換。

Spring Cloud Gateway ?：? Spring Cloud Gateway是一個 API 網(wǎng)關(guān)框架，基于 Spring Framework、Spring Boot 和 Spring Webflux，一個反應(yīng)式 Web 框架。

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

• 將請求路由到后端服務(wù)。
• 實現(xiàn)執(zhí)行 API 組合的請求處理程序。
• 處理橫切關(guān)注點，例如身份驗證。