同期的なリモープロシージャパターン
from マイクロサービスアーキテクチャ
クライアントとサーバー間がプロキシインターフェースを介して同期的に（クライアントがレスポンスを期待して）やり取りを行う。プロキシインターフェースが通信のプロトコルをカプセル化する。
通信のプロトコルとして、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 パターン
サービス障害時のエラーの修復としては
クライアントにエラーを返す
デフォルト値やキャッシュした値を返却する
サービスそのものが障害で動作しない可能性もあるため、適切にサービスを
など