マイクロサービス周りのシステムデザインなどを調べテイク中でmessagingについて調べたのでまとめる

メッセージングとは

ざっくりメッセージとチャネルというのがある メッセージというのをチャネルを介してsender(メッセージを送る側)がreciever(メッセージ受け取る側)に送るシステム

Google PubSubとかAWS SQSとか

メッセージ

ヘッダとボディで構成される データに関するメタデータとかが入ってる、他にもメッセージングサービスが生成した一意なメッセージIDやリターンアドレスといったものが入る

ボディは送られるデータそのもの。JSONだったりバイナリだったりいろいろ

チャネル

メッセージチャンネルには

• point-to-point チャンネルを読み取るレシーバの一つだけにメッセージを送る(1:1)
• publish-subscribe 接続中のすべてのレシーバにメッセージを届ける(1:N)

非同期リクエスト/レスポンスの実装

リクエスト/レスポンス型ではただちにレスポンスを返すことが想定されている。非同期リクエスト/レスポンス型ではその想定がないので、ブロッキングすることができる。

クライアントからリクエストチャンネルに送る送るメッセージには

• reployをどのチャンネルから返すべきか を付与し、リプライメッセージには
• どのリクエストIDのリプライかがわかるようにcorrelationIdにリクエストのmessageId を付与する

メッセージブローカー

メッセージングを実現するインフラサービス。スタイルは大きく分けて二種類

ブローカーレス

ブローカーなしで実現する方法。サービスとサービスが直接メッセージを送受信する ZeroMQというのが有名

ServiceAはServiceB, ServiceCと、ServiceBはServiceCともMessagingを実現している

Pros

• ブローカーがいないのでネットワークレイテンシーが下がる
• ブローカーは単一障害点になりがち
• ブローカーいない分運用も楽

Cons

• ディスカバリメカニズムは必要
• メッセージ交換中は両方生きている必要あり、可用性下がる
• 配信保証を作るのは難しい

ブローカーベース(ブローカーあり)

• ActiveMQ
• RabbitMQ
• Apache Kafka
• AWS Kinesis
• AWS SQS
• Google PubSub

ざっくり

• 複数プログラミングサポート
• メッセージの順序保証
• 配信保証
• スケーラビリティ
• レイテンシー

などの要素から優先度をつけてどれを使うか選ぶことになる

ServiceAはMessageBrokerを通じてServiceB,Cとメッセージングを実現している