マイクロサービスとgRPCの分離
私はマイクロサービスアーキテクチャをセットアップしていますが、gRPCがサービスを疎結合できる方法について混乱しています（Kafkaのようなpub-subメッセージサービスと比較して）。リクエストはサーバーに直接送信されず、pub/subシステムを経由しませんか？ gRPCは非同期リクエストをサポートしていますが、サービス間のバッファとしてpub/subを使用して、それらを個別にスケーリングする必要がありますか？
gRPCは非同期リクエストを実行できますが、それでもRPCパターンであるため、メッセージ（サブ/パブ）システムの実装ではなく、答えを気にしない場合に主に使用します。
私がしていることは、RPCが必要な場合は通信にgRPCを使用し、ProtocolBuffersを使用してデータをシリアル化します。次に、メッセージングが必要な場合は、ProtocolBuffersと一緒にAMQPを使用します。
スケーリングが必要な場合、サーバー間でルーティングを行う場合、またはオフラインメッセージやメッセージ受信通知などの機能が必要な場合は、gRPCがメッセージングシステムを介してデータをバッファリングすることは理にかなっています。
私のアドバイスは、通信シナリオを紙に描くことであり、どのタイプのサービスが必要かを明確にする必要があります。
また、gRPCの使用はほとんどターンキーであり、AMQPはそうではないことに注意してください。通常、メッセージングシステムでは、多くのコードを記述する必要があります。実際にスケーリングしない場合は、作業量が多すぎる可能性があります。また、両方が必要になることはまれだと思います。 RPCパターンは、ほとんどがメッセージングパターンのサブセットです。 RPCを超える場合は、IMOの最初からメッセージングを使用します。
gRPCとキュー|ブローカーは相互に排他的ではありません。どちらかを選ばなければならないというわけではありません。 1つ、両方、または何も選択しない場合があります。 SMTPサーバーをキューまたはプレーンテキストファイルとして使用することもできます。
それらは異なる目的を満たすため、互いに補完できます。
デカップリング
各ステージがプロセス（サービス）であるパイプラインで考えます。
[Process A] < ----- > [Process B]
矢印は、基数と依存関係を示します。
この図は、同時にクライアントとサーバーである2つのサービスを示しています。 [〜＃〜] a [〜＃〜]は[〜＃〜] b [のクライアントおよびサーバーです〜＃〜]。およびその逆。このようなa IPCには、通信プロトコル（HTTP 1/2、Webソケット、ソケットなど）に関係なく、サービスが互いに認識していることが含まれます。
今、間にキューまたはブローカーを置きます
[Process A] <----- > [Queue|Broker] <------> [Process B]
矢印は、基数または依存関係を示します。
キューとブローカーは、サービス間のカーディナリティーを破壊するため、依存関係があります。彼らはもうお互いを意識する必要はありません。サービスのパブリックインターフェイスは不要になる可能性があるため、削除することもできます。パブリックインターフェイス、カップリングはありません。
採用機能
キューとブローカーは通常、I/Oに関してパフォーマンス/信頼性/一貫性/スケーラブル/回復力を持つように設計されており、これらを実装することで、これらの機能をアーキテクチャに提供できます。たとえば、gRPCは、リクエスト/レスポンスおよび（非永続的）ストリーミングのユースケースのトランスポートメカニズムです。メッセージが不足している余裕がない場合は、代替案や補完的なアーキテクチャコンポーネントを探す必要があります。キューとブローカーがその仕事をするかもしれません。 IPC=を提供する機能は永続性だけではありません。
- メッセージの一貫性と持続性
- キャッチとバッチ処理
- エラー処理
- フェイルオーバー
- リトライ
- スケーラビリティ
- モジュール性または区分性（専用のブローカーまたはキューがある）
- すぐに使用できるいくつかのプロトコルとの互換性
- トラフィックのトレーサビリティ
- 交通監視
- ツーリング
関連リンク
私は このブログ投稿 を見つけました。
言及に値する マイクロサービスとIPC実装 に関するNginxブログ投稿）。