マイクロサービス間通信＠マイクロサービス領域¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. リクエスト／レスポンス方式¶
リクエスト／レスポンス方式とは¶
マイクロサービス間で同期的に双方向で通信する。
ドメインモデリングは、ステートソーシングパターンになる。
送信元と宛先で通信処理が同時に実行されるため、HTTP や gRPC による同期通信をすることになる。
また、マイクロサービス間で直接的にリクエストを送受信することになる。
使用できる通信プロトコルは以下の通りである。
| プロトコル | 説明 |
|---|---|
| 従来の TCP/IP | 従来の TCP/IP プロトコルを使用する。 |
| gRPC | gRPC over HTTP/2 プロトコルを使用する。HTTP API であると、通信相手のマイクロサービスのエンドポイントをコールした後、エンドポイントに紐づくコントローラーの関数が実行される。一方で gRPC であると、通信相手のマイクロサービスの関数を直接的に実行できる。そのため、HTTP API よりもマイクロサービスの連携に適している。 ・https://techdozo.dev/grpc-for-microservices-communication/ |
リクエスト駆動型マイクロサービス¶
リクエスト／レスポンス方式で稼働するマイクロサービスアーキテクチャのこと。
仲介コンポーネント¶
▼ メッセージキューを経由しないポイントツーポイントの場合¶
マイクロサービス間で直接的に通信する。
メッセージ中継システムを経由するよりも、各マイクロサービスの結合度が高まってしまう。
一方で、マイクロサービスの実装が簡単になる。
▼ メッセージ中継システムを経由する場合¶
メッセージキュー (例：Amazon SQS など) やメッセージブローカー (例：Apache Kafka、RabbitMQ など) を経由して、マイクロサービス間で通信する。
宛先マイクロサービスが永続化の責務を担っている場合は、処理の開始/終了を担保して処理完了の確実性を担保したがいい。
そのため、リクエスト／レスポンス方式であってもマイクロサービス間に双方向のメッセージブローカーを設置する。
例えば、リクエスト／レスポンス方式でオーケストレーションベース Saga パターンを採用する場合がある。
Saga オーケストレーターの宛先マイクロサービスの間にメッセージブローカーを配置するのは、宛先マイクロサービスのローカルトランザクション処理を確実に完了するためである。
02. パブリッシュ／サブスクライブ方式¶
パブリッシュ／サブスクライブ方式とは¶
マイクロサービスからマイクロサービスに非同期的に単方向で通信する。
ドメインモデリングは、イベントソーシングパターンになる。
送信元と宛先で通信処理が独立して実行されるため、メッセージ中継システムを経由した非同期通信をすることになる。
送信元マイクロサービスはメッセージ中継システムにメッセージをパブリッシュする。
サブスクライブには、宛先マイクロサービスによるプル型と、メッセージ中継システムによるプッシュ型がある。
仲介コンポーネント¶
▼ メッセージキューを経由しないポイントツーポイントの場合¶
このパターンは存在しない。
▼ メッセージ中継システムを経由する場合¶
メッセージキュー (例：Amazon SQS など) やメッセージブローカー (例：Apache Kafka、RabbitMQ など) を経由して、マイクロサービス間で通信する。
モデリングがイベントソーシングの場合は、各マイクロサービスは非同期で通信したほうがよく、単方向のメッセージブローカーを設置する。
特に、複数の送信元マイクロサービスからのリクエストを集約するような宛先マイクロサービスがある場合を考える。その送信元にメッセージブローカーを配置すれば、宛先マイクロサービスのレートリミットを超過しないように、一定の間隔で通信をフォワーディングできる。
もしマイクロサービス間双方向に送信したい場合は、送信元マイクロサービスからメッセージを受信するメッセージブローカーと、宛先マイクロサービスから受信するメッセージブローカーを、別々に配置する。
イベント駆動型マイクロサービス¶
パブリッシュ／サブスクライブ方式で稼働するマイクロサービスアーキテクチャのこと。