「Chris Richardson 微服務系列」使用 API 網關構建微服務
編者的話｜本文來自 Nginx 官方博客，是微服務系列文章的第二篇，本文將探討：微服務架構是如何影響客戶端到服務端的通信，並提出一種使用 API 網關的方法。
轉自http://blog.daocloud.io/microservices-2/
作者介紹：Chris Richardson，是世界著名的軟件大師，經典技術著作《POJOS IN ACTION》一書的作者，也是 cloudfoundry.com 最初的創始人，Chris Richardson 與 Martin Fowler、Sam Newman、Adrian Cockcroft 等並稱爲世界十大軟件架構師。
Chris Richardson 微服務系列全 7 篇：
2. 使用 API 網關構建微服務
3. 深入微服務架構的進程間通信
4. 服務發現的可行方案以及實踐案例
5. 微服務的事件驅動數據管理
6. 選擇微服務部署策略
7. 將單體應用改造爲微服務
Chris Richardson 所著所有文章已獨家授權 DaoCloud 翻譯並刊載。
本期內容
微服務系列文章的第一篇介紹了微服務架構模式，討論了使用微服務的優缺點，以及爲什麼微服務雖然複雜度高卻是複雜應用程序的理想選擇。
在決定以一組微服務來構建自己的應用時，你需要確定應用客戶端如何與微服務交互。
在單體式程序中，通常只有一組冗餘的或者負載均衡的服務提供點。在微服務架構中，每一個微服務暴露一組細粒度的服務提供點。在本篇文章中，我們來看它如何影響客戶端到服務端通信，並提出一種使用 API 網關的方法。
簡要概述
讓我們想象一下，你要爲一個購物應用程序開發一個原生移動客戶端。你很可能需要實現一個產品詳情頁面，展示任何指定商品的信息。
下圖展示了 Amazon Android 應用在商品詳情頁顯示的內容。
即使只是個智能手機應用，產品詳情頁面也顯示了大量的信息。該頁面不僅包含基本的產品信息（如名稱、描述、價格），而且還顯示瞭如下內容：
- 購物車中的商品數量
- 歷史訂單
- 客戶評論
- 低庫存預警
- 送貨選項
- 各種推薦，包括經常與該商品一起購買的其它商品、購買該商品的客戶購買的其它商品、購買該商品的客戶看過的其它商品
- 其它的購物選擇
使用單體應用程序架構時，移動客戶端通過嚮應用程序發起一次 REST 調用（GET api.company.com/productdetails/）來獲取這些數據。負載均衡器將請求路由給 N 個相同的應用程序實例中的其中之一。然後，應用程序會查詢各種數據庫表，並將響應返回給客戶端。
相反，若是採用微服務架構，顯示在產品頁上的數據會分佈在不同的微服務上。下面列舉了可能與產品詳情頁數據有關的一些微服務：
- 購物車服務——購物車中的件數
- 訂單服務——歷史訂單
- 目錄服務——商品基本信息，如名稱、圖片和價格
- 評論服務——客戶的評論
- 庫存服務——低庫存預警
- 送貨服務——送貨選項、期限和費用，這些信息單獨從送貨方 API 獲取
- 推薦服務——推薦商品
我們需要決定移動客戶端如何訪問這些服務。讓我們看看有哪些方法。
客戶端與微服務直接通信
從理論上講，客戶端可以直接向每個微服務發送請求。每個微服務都有一個公開的端點(https ://.api.company.name）。該 URL 映射到微服務的負載均衡器，由後者負責在可用實例之間分發請求。爲了獲取產品詳情，移動客戶端將逐一向上文列出的 N 個服務發送請求。
遺憾的是，這種方法存在挑戰和侷限。問題之一是客戶端需求和每個微服務暴露的細粒度 API 不匹配。在這個例子中，客戶端需要發送 7 個獨立請求。在更復雜的應用程序中，可能要發送更多的請求；按照 Amazon 的說法，他們在顯示他們的產品頁面時就調用了數百個服務。然而，客戶端通過 LAN 發送許多請求，這在公網上可能會很低效，在移動網絡上就根本不可行。這種方法還使得客戶端代碼非常複雜。
客戶端直接調用微服務的另一個問題是，部分服務使用的協議對 web 並不友好。一個服務可能使用 Thrift 二進制 RPC，而另一個服務可能使用 AMQP 消息傳遞協議。不管哪種協議對於瀏覽器或防火牆都不夠友好，最好是內部使用。在防火牆之外，應用程序應該使用諸如 HTTP 和 WebSocket 之類的協議。
這種方法的另一個缺點是，它會使得微服務難以重構。隨着時間推移，我們可能想要更改系統拆分成服務的方式。例如，我們可能合併兩個服務，或者將一個服務拆分成兩個或更多服務。然而，如果客戶端與微服務直接通信，那麼執行這類重構就非常困難了。
由於上述三種問題的原因，客戶端直接與服務器端通信的方式很少在實際中使用。
使用 API 網關構建微服務
通常來說，使用 API 網關是更好的解決方式。API 網關是一個服務器，也可以說是進入系統的唯一節點。這與面向對象設計模式中的 Facade 模式很像。API 網關封裝內部系統的架構，並且提供 API 給各個客戶端。它還可能還具備授權、監控、負載均衡、緩存、請求分片和管理、靜態響應處理等功能。下圖展示了一個適應當前架構的 API 網關。
API 網關負責服務請求路由、組合及協議轉換。客戶端的所有請求都首先經過 API 網關，然後由它將請求路由到合適的微服務。API 網關經常會通過調用多個微服務併合並結果來處理一個請求。它可以在 web 協議（如 HTTP 與 WebSocket）與內部使用的非 web 友好協議之間轉換。
API 網關還能爲每個客戶端提供一個定製的 API。通常，它會向移動客戶端暴露一個粗粒度的 API。以產品詳情的場景爲例，API 網關可以提供一個端點（/productdetails?productid=xxx），使移動客戶端可以通過一個請求獲取所有的產品詳情。API 網關通過調用各個服務（產品信息、推薦、評論等等）併合並結果來處理請求。
Netflix API 網關是一個很好的 API 網關實例。Netflix 流媒體服務提供給成百上千種類型的設備使用，包括電視、機頂盒、智能手機、遊戲系統、平板電腦等等。
最初，Netflix 試圖爲他們的流媒體服務提供一個通用的 API。然而他們發現，由於各種各樣的設備都有自己獨特的需求，這種方式並不能很好地工作。如今，他們使用一個 API 網關，通過運行與針對特定設備的適配器代碼，來爲每種設備提供定製的 API。通常，一個適配器通過調用平均 6 到 7 個後端服務來處理每個請求。Netflix API 網關每天處理數十億請求。
API 網關的優點和缺點
如你所料，使用 API 網關有優點也有不足。使用 API 網關的最大優點是，它封裝了應用程序的內部結構。客戶端只需要同網關交互，而不必調用特定的服務。API 網關爲每一類客戶端提供了特定的 API，這減少了客戶端與應用程序間的交互次數，還簡化了客戶端代碼。
API 網關也有一些不足。它增加了一個我們必須開發、部署和維護的高可用組件。還有一個風險是，API 網關變成了開發瓶頸。爲了暴露每個微服務的端點，開發人員必須更新 API 網關。API網關的更新過程要儘可能地簡單，這很重要；否則，爲了更新網關，開發人員將不得不排隊等待。不過，雖然有這些不足，但對於大多數現實世界的應用程序而言，使用 API 網關是合理的。
實現 API 網關
到目前爲止，我們已經探討了使用 API 網關的動力及其優缺點。下面讓我們看一下需要考慮的各種設計問題。
性能和可擴展性
只有少數公司擁有 Netflix 這樣的規模，需要每天處理每天需要處理數十億請求。不管怎樣，對於大多數應用程序而言，API 網關的性能和可擴展性都非常重要。因此，將 API 網關構建在一個支持異步、I/O 非阻塞的平臺上是合理的。有多種不同的技術可以實現一個可擴展的 API 網關。在 JVM 上，可以使用一種基於 NIO 的框架，比如 Netty、Vertx、Spring Reactor 或 JBoss Undertow 中的一種。一個非常流行的非 JVM 選項是 Node.js，它是一個基於 Chrome JavaScript 引擎構建的平臺。
另一個方法是使用 NGINX Plus。NGINX Plus 提供了一個成熟的、可擴展的、高性能 web 服務器和一個易於部署的、可配置可編程的反向代理。NGINX Plus 可以管理身份驗證、訪問控制、負載均衡請求、緩存響應，並提供應用程序可感知的健康檢查和監控。
使用響應式編程模型
API 網關通過簡單地將請求路由給合適的後端服務來處理部分請求，而通過調用多個後端服務併合並結果來處理其它請求。對於部分請求，比如產品詳情相關的多個請求，它們對後端服務的請求是獨立於其它請求的。爲了最小化響應時間，API 網關應該併發執行獨立請求。
然而，有時候，請求之間存在依賴。在將請求路由到後端服務之前，API 網關可能首先需要調用身份驗證服務驗證請求的合法性。類似地，爲了獲取客戶心願單中的產品信息，API 網關必須首先獲取包含這些信息的客戶資料，然後再獲取每個產品的信息。關於 API 組合，另一個有趣的例子是 Netflix Video Grid。
使用傳統的異步回調方法編寫 API 組合代碼會讓你迅速墜入回調地獄。代碼會變得混亂、難以理解且容易出錯。一個更好的方法是使用響應式方法，以一種聲明式樣式編寫 API 網關代碼。響應式抽象概念的例子有 Scala 中的 Future、Java 8 中的 CompletableFuture 和 JavaScript 中的P romise，還有最初微軟爲 .NET 平臺開發的 Reactive Extensions（RX）。Netflix 創建了 RxJava for JVM，專門用於他們的 API 網關。此外，還有 RxJS for JavaScript，它既可以在瀏覽器中運行，也可以在 Node.js 中運行。使用響應式方法能讓你編寫簡單但高效的 API 網關代碼。
服務調用
基於微服務的應用程序是一個分佈式系統，必須使用一種進程間通信機制。有兩種類型的進程間通信機制可供選擇。一種是使用異步的、基於消息傳遞的機制。有些實現使用諸如 JMS 或 AMQP 那樣的消息代理，而其它的實現（如 Zeromq）則沒有代理，服務間直接通信。
另一種進程間通信類型是諸如 HTTP 或 Thrift 那樣的同步機制。通常，一個系統會同時使用異步和同步兩種類型。它甚至還可能使用同一類型的多種實現。總之，API 網關需要支持多種通信機制。
服務發現
API 網關需要知道它與之通信的每個微服務的位置（IP 地址和端口）。在傳統的應用程序中，或許可以硬連線這個位置，但在現代的、基於雲的微服務應用程序中，這並不是一個容易解決的問題。基礎設施服務（如消息代理）通常會有一個靜態位置，可以通過 OS 環境變量指定。但是，確定一個應用程序服務的位置沒有這麼簡單。應用程序服務的位置是動態分配的，而且，單個服務的一組實例也會隨着自動擴展或升級而動態變化。
總之，像系統中的其它服務客戶端一樣，API 網關需要使用系統的服務發現機制，可以是服務器端發現，也可以是客戶端發現。下一篇文章將更詳細地描述服務發現。現在，需要注意的是，如果系統使用客戶端發現，那麼 API 網關必須能夠查詢服務註冊中心，這是一個包含所有微服務實例及其位置的數據庫。
處理局部失敗
在實現 API 網關時，還需要處理局部失敗的問題。該問題出現在所有的分佈式系統中。當一個服務調用另一個服務，而後者響應慢或不可用的時候，就會出現這個問題。API 網關不能因爲無限期地等待下游服務而阻塞。不過，如何處理失敗取決於特定的場景以及哪個服務失敗。例如，在產品詳情場景下，如果推薦服務無響應，那麼 API 網關應該向客戶端返回產品詳情的其它內容，因爲它們對用戶依然有用。推薦內容可以爲空，也可以用一個固定的 TOP 10 列表取代。不過，如果產品信息服務無響應，那麼 API 網關應該向客戶端返回一個錯誤信息。
如果緩存數據可用，那麼 API 網關還可以返回緩存數據。例如，鑑於產品價格不會頻繁變動，如果價格服務不可用，API 網關可以返回緩存的價格數據。數據可以由 API 網關自己緩存，也可以存儲在像 Redis 或 Memcached 之類的外部緩存中。通過返回默認數據或者緩存數據，API 網關可以確保系統故障不影響用戶體驗。
在編寫代碼調用遠程服務方面，Netflix Hystrix 是一個格外有用的庫。Hystrix 會暫停超出特定閾限的調用。它實現了一個“斷路器（circuit breaker）”模式，可以防止客戶端對無響應的服務進行不必要的等待。如果服務的錯誤率超出了設定的閾值，那麼 Hystrix 會啓動斷路器，所有請求會立即失敗並持續一定時間。Hystrix 允許用戶定義一個請求失敗後的後援操作，比如從緩存讀取數據，或者返回一個默認值。如果你正在使用 JVM，那麼你應該考慮使用 Hystrix；如果你正在使用一個非 JVM 環境，那麼可以使用一個功能相同的庫。
總結
對於大多數基於微服務的應用程序而言，實現 API 網關，將其作爲系統的唯一入口很有必要。API 網關負責服務請求路由、組合及協議轉換。它爲每個應用程序客戶端提供一個定製的 API。API 網關還可以通過返回緩存數據或默認數據屏蔽後端服務失敗。在本系列的下一篇文章中，我們將探討服務間通信。
下期題目：深入微服務架構的進程間通信 ，敬請期待！
點擊“Building Microservices: Using an API Gateway”，查看英文原文
This entry was posted in 乾貨 and tagged 微服務. Bookmark the permalink.