本文總結(jié)和提出了解決當前在實現(xiàn)微服務時明顯的問題，主要包括

• 服務之間的內(nèi)部通信，這種一般使用 RPC 通信。
• 外部第三方系統(tǒng)需要通過 Http Rest 方式訪問服務，這些服務可能只提供了 RPC 接口。

介紹

微服務架構(gòu)的采用率正在上升，并因其帶來的靈活性（包括可維護性和可擴展性）而被廣泛接受。隨著容器化，微服務架構(gòu)變得更加強大，允許用戶創(chuàng)建專注于其功能而不是解決依賴關(guān)系的應用程序。云原生應用程序開發(fā)由使用容器的微服務架構(gòu)提供支持。

分布式系統(tǒng)設計復雜，并且隨著業(yè)務需求的不同性質(zhì)而變得更加復雜，為了實現(xiàn)端到端業(yè)務能力，需要互連或調(diào)用多個微服務。集成技術(shù)的選擇變得至關(guān)重要，目前采用的常用方法是任何服務間通信利用 gRPC（Google 遠程過程調(diào)用）和任何面向客戶端的服務利用 REST（代表性狀態(tài)傳輸）API。

• gRPC – 遵循 RPC API 實現(xiàn)，利用 HTTP 2.0 協(xié)議和協(xié)議緩沖區(qū)進行消息交換。
• REST – 架構(gòu)遵循 HTTP 協(xié)議，用于消息傳遞的數(shù)據(jù)格式是 JSON 或 XML。

設計和開發(fā)需要由其他服務在內(nèi)部使用并暴露給第三方系統(tǒng)或用戶的能力的挑戰(zhàn)

讓我們考慮一個由訂單管理器和產(chǎn)品庫存微服務組成的訂單管理系統(tǒng)的示例場景。

產(chǎn)品庫存服務包含所有產(chǎn)品詳細信息及其關(guān)系，包括各種類別。需要 REST API 將產(chǎn)品詳細信息及其與外部系統(tǒng)和用戶界面的關(guān)系公開。

Order Manager 服務與另一個數(shù)字渠道接口，該渠道充當客戶訂購的前端系統(tǒng)。這在內(nèi)部調(diào)用產(chǎn)品庫存服務來驗證產(chǎn)品庫存詳細信息。

在當前的方案中，有多種方法可以解決這樣的要求，下面詳細介紹了一些這樣的選項：

選項 1：

遵循任何服務間通信利用 gRPC 和任何面向客戶端的服務利用 REST 的方法。

• 通過 gRPC 公開 Product Inventory 服務以進行服務間通信

我們?yōu)楹霞s使用了 Protobuf 定義，并使用 java 來生成服務器端實現(xiàn)。

• 需要額外的編碼，如創(chuàng)建一個 REST 控制器和響應體，以公開與 REST API 相同的內(nèi)容，以供第三方系統(tǒng)使用。

這種方式需要處理 gRPC 和 REST 的額外編碼復雜性和依賴管理。

選項 2：

遵循微服務聚合器模式，

• 創(chuàng)建一個聚合器服務，該服務將通過聚合來自不同服務的響應或?qū)崿F(xiàn)包裝器 REST API 服務來公開 REST API 功能。這也將具有與其他內(nèi)部服務通信以聚合響應所需的 gRPC 客戶端實現(xiàn)。此處將包含用于從協(xié)議緩沖區(qū)創(chuàng)建 API 響應實體。

gRPC 和協(xié)議緩沖區(qū)迫使開發(fā)人員嚴格遵守契約，以確保消息安全且不會在通信之間丟失。雖然定義 RPC 的契約優(yōu)先性質(zhì)和共同開發(fā)的方法在相關(guān)服務之間是好的，但聚合器服務帶來了額外開銷。

總結(jié)

架構(gòu)師在設計分布式系統(tǒng)時花了很多心思。定義有效的集成模式是解決方案成功的關(guān)鍵。

以下是對各種集成選項和挑戰(zhàn)的總結(jié)：

• 在內(nèi)部和外部將數(shù)據(jù)公開為 REST（基于 JSON）：這種方法最流行，但遺憾的是不能滿足所有要求。由于 JSON 有效負載和 HTTP 協(xié)議的限制，這對于數(shù)據(jù)密集型服務間通信來說并不理想。
• 在內(nèi)部和外部公開 gRPC：數(shù)據(jù)交換以二進制格式發(fā)生，人類不可讀。gRPC 依賴于 HTTP2.0，它對現(xiàn)代瀏覽器的支持有限。
• 創(chuàng)建 REST 和 gRPC：正如前面選項中所解釋的，額外的編碼和集成開銷。來自任何廣泛采用的開源框架的跨技術(shù)（如 java、python、node）缺乏成熟的 gRPC 實現(xiàn)。

在我們考慮設計下一個基于微服務的解決方案時，考慮并設計這些不同的集成模式很重要。