gRPC と REST を使用したマイクロサービス アーキテクチャの統合の課題

この記事では、マイクロサービスの実装における現在の明らかな問題をまとめ、主に以下の解決策を提案します。

• 一般的に RPC 通信を使用するサービス間の内部通信。
• 外部のサードパーティ システムは、Http Rest を介してサービスにアクセスする必要があり、これらのサービスは RPC インターフェイスのみを提供する場合があります。

導入

マイクロサービス アーキテクチャの採用率は上昇しており、保守性やスケーラビリティなど、それがもたらす柔軟性が広く受け入れられています。コンテナ化により、マイクロサービス アーキテクチャはさらに強力になり、ユーザーは依存関係の解決ではなく機能に重点を置いたアプリケーションを作成できるようになります。クラウドネイティブ アプリケーション開発は、コンテナを使用したマイクロサービス アーキテクチャによって実現されます。

分散システムの設計は複雑であり、ビジネス要件の性質が異なるとさらに複雑になります。エンドツーエンドのビジネス機能を実現するには、複数のマイクロサービスを相互接続するか呼び出す必要があります。統合テクノロジの選択が重要になります。現在採用されている一般的なアプローチは、サービス間通信には gRPC (Google Remote Procedure Call) を活用し、クライアント向けサービスには REST (Representational State Transfer) API を活用することです。

• gRPC – RPC API 実装に従い、メッセージ交換に HTTP 2.0 プロトコルとプロトコル バッファーを利用します。
• REST – アーキテクチャは HTTP プロトコルに準拠し、メッセージングに使用されるデータ形式は JSON または XML です。

他のサービスによって内部的に使用され、サードパーティのシステムやユーザーに公開される必要がある機能を設計および開発する際の課題

Order Manager マイクロサービスと Product Inventory マイクロサービスで構成される注文管理システムのサンプル シナリオを考えてみましょう。

製品在庫サービスには、さまざまなカテゴリを含むすべての製品の詳細とそれらの関係が含まれています。製品の詳細とその関係を外部システムやユーザー インターフェイスに公開するには、REST API が必要です。

Order Manager サービスは、顧客の注文のためのフロントエンド システムとして機能する別のデジタル チャネルとインターフェイスします。これは、製品在庫の詳細を検証するために、内部的に製品在庫サービスを呼び出します。

現在のシナリオでは、このような要件に対処する方法は複数あり、そのオプションのいくつかを以下に詳しく説明します。

オプション1:

サービス間通信には gRPC を活用し、クライアント向けサービスには REST を活用するアプローチに従ってください。

• サービス間通信のために gRPC 経由で製品在庫サービスを公開する

契約には Protobuf 定義を使用し、サーバー側の実装を生成するために Java を使用しました。

• サードパーティのシステムで使用できるように REST API と同じコンテンツを公開するには、REST コントローラーと応答本文を作成するなどの追加のコーディングが必要です。

このアプローチでは、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 実装が不足しています。

次回のマイクロサービス ベースのソリューションの設計を検討する際には、これらのさまざまな統合パターンを考慮して設計することが重要です。