微服務架構與 gRPC 和 REST 的集成挑戰
本文總結和提出了解決當前在實現微服務時明顯的問題，主要包括
- 服務之間的內部通信，這種一般使用 RPC 通信。
- 外部第三方系統需要通過 Http Rest 方式訪問服務，這些服務可能只提供了 RPC 接口。
介紹
微服務架構的采用率正在上升，并因其帶來的靈活性（包括可維護性和可擴展性）而被廣泛接受。隨著容器化，微服務架構變得更加強大，允許用戶創建專注于其功能而不是解決依賴關系的應用程序。云原生應用程序開發由使用容器的微服務架構提供支持。
分布式系統設計復雜，并且隨著業務需求的不同性質而變得更加復雜，為了實現端到端業務能力，需要互連或調用多個微服務。集成技術的選擇變得至關重要，目前采用的常用方法是任何服務間通信利用 gRPC（Google 遠程過程調用）和任何面向客戶端的服務利用 REST（代表性狀態傳輸）API。
- gRPC – 遵循 RPC API 實現，利用 HTTP 2.0 協議和協議緩沖區進行消息交換。
- REST – 架構遵循 HTTP 協議，用于消息傳遞的數據格式是 JSON 或 XML。
設計和開發需要由其他服務在內部使用并暴露給第三方系統或用戶的能力的挑戰
讓我們考慮一個由訂單管理器和產品庫存微服務組成的訂單管理系統的示例場景。
產品庫存服務包含所有產品詳細信息及其關系，包括各種類別。需要 REST API 將產品詳細信息及其與外部系統和用戶界面的關系公開。
Order Manager 服務與另一個數字渠道接口，該渠道充當客戶訂購的前端系統。這在內部調用產品庫存服務來驗證產品庫存詳細信息。
在當前的方案中，有多種方法可以解決這樣的要求，下面詳細介紹了一些這樣的選項：
選項 1：
遵循任何服務間通信利用 gRPC 和任何面向客戶端的服務利用 REST 的方法。
- 通過 gRPC 公開 Product Inventory 服務以進行服務間通信
我們為合約使用了 Protobuf 定義，并使用 java 來生成服務器端實現。
- 需要額外的編碼，如創建一個 REST 控制器和響應體，以公開與 REST API 相同的內容，以供第三方系統使用。
這種方式需要處理 gRPC 和 REST 的額外編碼復雜性和依賴管理。
選項 2：
遵循微服務聚合器模式，
- 創建一個聚合器服務，該服務將通過聚合來自不同服務的響應或實現包裝器 REST API 服務來公開 REST API 功能。這也將具有與其他內部服務通信以聚合響應所需的 gRPC 客戶端實現。此處將包含用于從協議緩沖區創建 API 響應實體。
gRPC 和協議緩沖區迫使開發人員嚴格遵守契約，以確保消息安全且不會在通信之間丟失。雖然定義 RPC 的契約優先性質和共同開發的方法在相關服務之間是好的，但聚合器服務帶來了額外開銷。
總結
架構師在設計分布式系統時花了很多心思。定義有效的集成模式是解決方案成功的關鍵。
以下是對各種集成選項和挑戰的總結：
- 在內部和外部將數據公開為 REST（基于 JSON）：這種方法最流行，但遺憾的是不能滿足所有要求。由于 JSON 有效負載和 HTTP 協議的限制，這對于數據密集型服務間通信來說并不理想。
- 在內部和外部公開 gRPC：數據交換以二進制格式發生，人類不可讀。gRPC 依賴于 HTTP2.0，它對現代瀏覽器的支持有限。
- 創建 REST 和 gRPC：正如前面選項中所解釋的，額外的編碼和集成開銷。來自任何廣泛采用的開源框架的跨技術（如 java、python、node）缺乏成熟的 gRPC 實現。
在我們考慮設計下一個基于微服務的解決方案時，考慮并設計這些不同的集成模式很重要。
