簡介

我們假設您正在為一個購物應用開發一個原生移動客戶端。您可能需要實現一個產品詳細信息頁面，用于展示給定商品的信息。

例如，圖 2-1 展示了在 Amazon 的 Android 移動應用中滾動產品信息時所看的內容。

這是一個智能手機應用，產品詳細信息頁面展示了許多信息。不僅有基本的產品信息，如名稱、描述和價格，頁面還展示了：

• 購物車中的物品數量
• 訂單歷史
• 客戶評價
• 低庫存警告
• 配送選項
• 各種推薦，包括了購買此產品的客戶購買的其他產品
• 選擇性購買選項

在使用單體應用架構的情況下，移動客戶端通過對應用程序進行單個 REST 調用來檢索此數據，例如：

GET api.company.com/productdetails/productId

負載均衡器將請求路由到幾個相同應用程序實例中的其中一個。之后，應用程序查詢各個數據庫表并返回響應給客戶端。相比之下，當使用微服務架構時，產品詳細頁面上展示的數據來自多個微服務。以下是一些微服務， 可能擁有特定產品頁面展示的數據：

• 訂單服務 訂單歷史
• 目錄（ catalog）服務 基本的產品信息，如產品名稱、圖片和價格
• 評價服務 客戶評價
• 庫存服務 低庫存警告
• 配送服務 配送選項、期限和費用，由配送方的 API 單獨提供
• 推薦服務 推薦類目

我們需要決定移動客戶端如何訪問這些服務。讓我們來看看有哪些方法。

客戶端與微服務直接通信

理論上，客戶端可以直接向每個微服務發送請求。每個微服務都有一個公開的端點：

https://serviceName.api.company.name

該 URL 將映射到用于跨可用實例分發請求的微服務負載均衡器。為了檢索特定的產品頁面信息，移動客戶端將向上述的每個微服務發送請求。

不幸的是，這種方式存在著挑戰與限制。第一個問題是客戶端的需求與每個微服務暴露的細粒度的 API 不匹配。 在此示例中，客戶端需要進行七次單獨請求。如果在更加復雜的應用中，它可能需要做更多的工作。例如，Amazon 展示了在產品頁面渲染中如何牽涉到數百個微服務。雖然客戶端可以通過 LAN 發送許多請求，但在公共互聯網下效率低下，在移動網絡必然是不切實際。

客戶端直接調用微服務存在的另一個問題是有些可能使用了非 web 友好協議。一個服務可能使用了 Thrift 二進制 RPC，而另一個則可能使用 AMQP 消息協議。這兩個協議無論是對瀏覽器還是防火墻而言都是不友好的，最好是在內部使用。應用程序在防火墻之外應該使用 HTTP 或者 WebSocket 之類的協議。

這種方法的另一個缺點是它難以重構微服務。隨著時間推移，我們可能會想改變系統劃分服務。例如，我們可能會合并兩個服務或者將服務拆分為兩個或者多個。然而，如果客戶端直接與服務進行通信，實施這類的重構將變得非常困難。

由于存在這些問題，很少有客戶端直接與微服務進行通信。

使用 API 網關

通常更好的方法是使用 API 網關。 API 網關是一個服務器，是系統的單入口點。它類似于面向對象設計模式中的門面（ Facade）模式。 API 網關封裝了內部系統架構，并針對每個客戶端提供一個定制 API。它還可用于認證、監控、負載均衡、緩存和靜態響應處理。

圖 2-3 展示了 API 通常如何整合架構

API 網關負責請求路由、組合和協議轉換。所有的客戶端請求首先要通過 API 網關，之后請求被路由到適當的服務。 API 網關通常會通過調用多個微服務和聚合結果來處理一個請求。它可以在 Web 協議（如 HTTP 和 WebSocket）和用于內部的非 Web 友好協議之間進行轉換。

API 還可以為每個客戶端提供一個定制 API。它通常會為移動客戶端暴露一個粗粒度的 API。例如，考慮一下產品詳細信息場景。API 網關可以提供一個端點

/productdetails?productid=xxx

如圖 2-3 所示，一個使用了 API 網關的微服務。允許移動客戶端通過一個單獨的請求來檢索所有產品詳細信息。 API 網關通過調用各種服務（產品信息、推薦、評價等）并組合結果。

一個很好的 API 網關案例是 Netflix API 網關。 Netflix 流媒體服務可用于數百種不同類型的設備，包括電視機、機頂盒、智能手機、游戲機和平板電腦等。起初，Netflix 嘗試為他們的流媒體服務提供一個通用的 API。后來，他們發現由于設備種類繁多，并且他們各自有著不同需求，所以并不是能很好地運作。如今，他們使用了 API 網關，通過運行特定設備適配代碼來為每個設備提供一個定制 API。

API 網關的優點與缺點

正如您所料，使用 API 網關同樣存在好處與壞處。使用 API 網關的主要好處是它封裝了應用程序的內部結構。客戶端只需要與網關通信，而不必調用特定的服務。 API 網關為每種類型的客戶端提供了特定的 API，減少了客戶端與應用程序之間的往返次數。它還簡化了客戶端代碼。

API 網關也存在一些缺點，它是另一個高度可用的組件，需要開發、部署和管理。還另外，還有一個風險是 API 網關可能會成為開發瓶頸。開發人員必須更新 API 網關以暴露每個微服務的端點。

重要的是更新 API 網關的過程應盡可能地放緩一些。否則，開發人員將被迫排隊等待網關更新。盡管 API 網關存在這些缺點，但對于大多數的真實應用來說，使用 API 是合理的。

實施 API 網關

我們已經了解了使用 API 網關的動機與權衡。接下來讓我們看看您需要考慮的各種設計問題。

性能與可擴展性

只有少數公司能達到 Netflix 的運營規模，每天需要處理數十億的請求。然而，對于大多數應用來說， API 網關的性能和可擴展性是相當重要的。因此，在一個支持異步、非阻塞 I/O 平臺上構建 API 網關是很有必要的。可以使用不同的技術來實現一個可擴展的 API 網關。在 JVM 上，您可以使用基于 NIO 的框架，如 Netty、Vertx、Spring Reactor 或者 JBoss Undertow。一個流行的非 JVM 選擇是使用 Node.js，它是一個建立在 Chrome 的 JavaScript 引擎之上的平臺。

使用響應式編程模型

API 網關通過簡單地把他們（請求）路由到適當的后端服務來處理一些請求。它通過調用多個后端服務并聚合結果來處理其他請求。對于某些請求，如產品詳細信息請求，對后端服務請求而言是彼此獨立的。為了縮短響應時間到最小， API 網關應該并發執行獨立請求。

然而，有時候，請求是相互依賴的。首先， API 網關可能需要在將請求路由到后端服務之前， 通過調用驗證服務來驗證請求。同樣，為了從客戶的愿望清單中獲取產品的信息， API 網關首先必須檢索包含該信息的客戶資料，然后檢索每個產品的信息。 另一個有趣的 API 組合案例是 Netflix 視頻網格。

使用傳統的異步回調方式來編寫 API 組合代碼會很快使您陷入回調地獄。代碼將會變得雜亂、難以理解并且容易出錯。一個更好的方式是使用響應式方法以聲明式編寫 API 網關代碼。響應式抽象的例子包括 Scala 的 Future、Java 8 中的 CompletableFuture 和 JavaScript 中的 Promise。還有 Reactive Extensions（也稱為 Rx 或 ReactiveX），最初由 Microsoft 為 .NET 平臺開發。 Netflix 為 JVM 創建了 RxJava，專門應用于其 API 網關。還有用于 JavaScript 的 RxJS，它可以在瀏覽器和 Node.js 中運行。使用響應式方式可讓您能夠編寫出簡單而高效的 API 網關代碼。

服務調用

一個基于微服務的應用程序是一個分布式系統，必須使用一個進程間（inter-process）通信機制。有兩種進程間通信方案。一是使用基于消息的異步機制。某些實現采用了消息代理，如 JMS 和 AMQP。其他采用無代理的方式直接與服務通信，如 Zeromq。

另一種類型的進程間通信采用了同步機制，如 HTTP 和 Thrift。系統通常會同時使用異步和同步方式。甚至可以為每種方式應用多個實現。因此，API 網關需要支持各種通信機制。

服務發現

API 網關需要知道與其通信的每個微服務的位置（IP 地址和端口）。在傳統應用程序中，您可以將這些位置硬編碼，但在現代基于云的微服務應用程序中，找到所需的位置不是一件簡單的事情。

基礎設施服務（比如消息代理）通常都有一個可以通過系統環境變量來指定的靜態位置。但是，要確定應用程序服務的位置并不是那么容易。

應用服務可以動態分配位置。此外，由于自動擴縮和升級，一個服務的整組實例可以動態變更。因此，API 網關與系統中的任何其他服務客戶端一樣，需要使用系統的服務發現機制：服務端發現或客戶端發現。現在需要注意的是，如果系統使用客戶端發現，API 網關必須能夠查詢 服務注冊中心，該注冊中心是所有微服務實例及其位置的數據庫。

處理局部故障

實施 API 網關時必須解決的另一個問題是局部故障問題。當一個服務調用另一個響應緩慢或者不可用的服務時，所有分布式系統都會出現此問題。 API 網關不應該無期限地等待下游服務。但是，如何處理故障問題取決于特定的方案和哪些服務發生故障。例如，如果推薦服務在獲取產品詳細信息時沒有響應，API 網關應將其余的產品詳細信息返回給客戶端，因為它們對用戶仍然有用。建議可以是空的，也可以用其他代替，例如硬編碼的十強名單。然而，如果產品信息服務沒有響應，那么 API 網關應該向客戶端返回錯誤。

如果可以，API 網關還可以返回緩存數據。例如，由于產品價格變化不大，當價格服務不可用時，API 網關可以返回被緩存的價格數據。數據可以由 API 網關緩存或存儲在外部緩存中，如 Redis 或者 Memcached。 API 網關通過返回默認數據或緩存數據，確保系統發生故障時最小程度上影響到用戶體驗。

Netflix Hystrix 是一個非常有用的庫，用于編寫調用遠程服務代碼。 Hystrix 可以使超出指定閾值的調用超時。它實現了斷路器模式，防止客戶端不必要地等待無響應的服務。如果服務的錯誤率超過指定閾值， Hystrix 將會跳閘，所有請求將在指定的時間內立即失敗。 Hystrix 允許您在請求失敗時定義回退操作，例如從緩存讀取或返回默認值。如果您正在使用 JVM，那么您一定要考慮使用 Hystrix。如果您是在非 JVM 環境中運行，則應使用同等作用的庫。

總結

對于大多數基于微服務的應用程序來說，實現一個 API 網關是很有意義的， API 網關充當著系統的單入口點，并且負責請求路由，組合和協議轉換。它為每個應用程序客戶端提供了一個自定義 API。 API 網關還可以通過返回緩存或默認數據來掩蓋后端服務故障。

總結

以上是生活随笔為你收集整理的使用 API 网关的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。