同期的なリモープロシージャパターン

クライアントとサーバー間がプロキシインターフェースを介して同期的に（クライアントがレスポンスを期待して）やり取りを行う。プロキシインターフェースが通信のプロトコルをカプセル化する。
通信のプロトコルとして、RESTとgRPCについて取り上げる。

REST

RESTは、ビジネスオブジェクトやそのコレクションを表すリソースを、HTTPメソッドで操作するようにエンドポイントをもつAPI。APIは、インターフェース定義言語で定義しなければならない。

メリット

• curlやPostmanで簡単にAPIを叩くことができる
• リクエスト／レスポンススタイルをサポートしている
• 中間のブローカーが不要でアーキテクチャが単純になる デメリット
• リクエスト／レスポンススタイル以外の通信を利用できない
• クライアントーサーバー間が直接通信しているので、可用性が下がる
• クライアントがサービスインスタンスの位置を知っている必要がある
  • （解決策⇛[サービスディスカバリ]）
• １つのリクエストで複数のリソースをフェッチできない

gRPC

HTTP/2を利用してプロトコルバッファ形式のメッセージをやりとりするAPI。

メリット

• 操作に対して命名できるのでAPIの設計がしやすい
• 大きなメッセージのやりとりでも効率的でコンパクトに通信できる
• 双方向ストリーミングのため、RPI、メッセージの両方のスタイルで通信できる
• 言語に依存しない

デメリット

• JavaScriptクライアントでは扱いづらい
• 古いファイアウォールでは対応していない場合がある

RPIのエラー処理

同期的にサービスを呼び出す場合、以下について検討し、障害から守る必要がある。
fault-tolerance-in-a-high-volume-distributed-system - netflix

• レスポンスを待つときはネットワークタイムアウトを指定する。リソースが必ず開放されるようにする。
• クライアントから未応答のリクエストの許容上限を決めておく
• [Circuit breaker パターン]

サービス障害時のエラーの修復としては

• クライアントにエラーを返す
• デフォルト値やキャッシュした値を返却する
• サービスそのものが障害で動作しない可能性もあるため、適切にサービスを