微服務(wù)架構(gòu)與 gRPC 和 REST 的集成挑戰(zhàn)

2022-03-29 10:36:32

開(kāi)發(fā)

架構(gòu)

云原生 本文旨在解釋 gRPC 和 REST 等技術(shù)為端到端微服務(wù)架構(gòu)帶來(lái)的集成挑戰(zhàn)。

創(chuàng)新互聯(lián)主要從事網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)安順,十多年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來(lái)電咨詢建站服務(wù):18980820575

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

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

介紹

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

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

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

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

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

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

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

在當(dāng)前的方案中，有多種方法可以解決這樣的要求，下面詳細(xì)介紹了一些這樣的選項(xiàng)：

選項(xiàng) 1：

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

• 通過(guò) gRPC 公開(kāi) Product Inventory 服務(wù)以進(jìn)行服務(wù)間通信

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

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

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

選項(xiàng) 2：

遵循微服務(wù)聚合器模式，

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

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

總結(jié)

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

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

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

在我們考慮設(shè)計(jì)下一個(gè)基于微服務(wù)的解決方案時(shí)，考慮并設(shè)計(jì)這些不同的集成模式很重要。

本文名稱：微服務(wù)架構(gòu)與gRPC和REST的集成挑戰(zhàn)
網(wǎng)頁(yè)鏈接：http://www.dlmjj.cn/article/dhhgcep.html