マイクロサービスは互いにどのように通信しますか？

サービスは同期的（REST または gRPC 上のリクエスト/レスポンス）または非同期的（Kafka や RabbitMQ のようなブローカーを通じたメッセージ/イベント）のいずれかで通信します。

同期的（リクエスト/レスポンス）

呼び出し元は応答を待ちます。シンプルで直感的ですが、可用性を結合します — 呼び出された側がダウンしている場合、呼び出し元は影響を受けます。

GET /orders/42 HTTP/1.1
Host: orders-service
Accept: application/json

非同期的（メッセージング/イベント）

送信元はメッセージを公開して進みます。コンシューマーは後で処理します。これはサービスを時間的に分離します。

Order Service ──publish "OrderPlaced"──▶ [ Broker ] ──▶ Email Service
                                              │
                                              └──▶ Inventory Service

どちらを使うか

落とし穴

長い同期チェーン（A → B → C → D）はレイテンシーと障害確率を増やします。可能な限り非同期または集約を優先してください。

なぜ重要なのか

通信スタイルはシステムの耐性を形づくります。同期呼び出しは理解しやすいですが厳密な実行時の結合を作成し、非同期メッセージングは最終的一貫性の代償で分離を得ます。

実際のシステムのほとんどは両方を混在させます — ユーザー向けの読み取りは同期的、バックグラウンドワークフローは非同期的です。