マイクロサービスアーキテクチャのHTTPと倹約

Question

マイクロサービスについて知り始めたばかりですが、自分では答えられないという質問があります。私はこのような状況がある

（と私はまた、Javaベースの開発者です）：

1. 私が取得データのためのスリフトサービス（名前付きT1）を呼び出し、サービスA（APIサービス）を持っています。

2. 次に、Aからのデータ応答を使用してこれらのデータを解析し、新しいデータを生成して最終的にクライアントに返すサービスBがあります。

質問：私はどちらを使うべきですか？ BからAのAPIを呼び出し、HttpClient/AsyncHttpClient（接続プールまたはBダイレクトコールT1）を使用して解析します（たとえばJSONデータ）。

IMHO、私はスリップ（接続プーリングも）がHTTPコールより高速だと思いますか？私は正しい？ 1は、私が使用する必要がありますので、

私は等の弾性検索、のNeo4j、ユーレカネットフリックス、などの内部のためにHTTPを使用するサービスの多くを参照してください...

、？なぜ、HTTPはThrift、ProtoBufなどのRPCの代わりに内部使用に普及しているのですか？

私の悪い英語のために申し訳ありません。 ありがとうございます。

Answer 1

HTTPとJSONまたはXMLは、プラットフォームと言語に依存しないため、一般的に使用されます。 HTTP APIはReSTfulアーキテクチャを可能にします。これは、分散システムを開発するためのスケーラブルなモデルであることが証明されています。

歴史的に、分散システムへのRPCベースのアプローチは、弱点の数を示しています

• は、多くの場合、彼らは言語に依存しています。 ThriftとProtobufはより相互運用性がありますが、かなり特殊なサードパーティのライブラリに依存しています。これと比較して、HTTPクライアントとXMLまたはJSONデータバインディング/プロセッサの実装が多数あります。

• クライアントとサーバーのアップグレードをまとめると、クライアントがサーバーと同時にアップグレードする必要があります。真に分散したネットワークでは、これは不可能です。

• RPCは、しばしば分散システムで大きなメタファーではありません。ネットワークを実装の懸念事項に抽象化することによって、ネットワークトラフィックが多すぎるか、信頼性の低いネットワークに耐えられない、低レベルの「チャット」インターフェースを奨励します。

• バイナリ転送形式は、何か問題が発生したときに解析/デバッグすることがより困難です。

これらの理由から、独自のRPC APIを使用してRest-with-HTTPベースのAPIを選択する傾向があります。