前提のシナリオ：
そこサービスAは、あるサービスBへの大量のデータを送信し、このアクションが呼ばれています。サービスBは、データを受け入れ、転送を行い、Bとしてこのアクションを呼び出します。非常に迅速なアクション、スローアクションB。サービスは、クラスタAであり、そして他のサービス動作が必要であるため、C Bは、制御情報を提供します。（下記参照）
我々はバランスをとるので、上のアカウントの負荷を考慮に入れるならば今の質問は、B場合は、複数のサービスを作成し、その後、Aはサービス、Cはまた、「関与」され、非効率的な、非常に遅い、速いBによるものである......そう、これは恒久的な解決策ではありません。次に、管理制御メッセージとデータ配信、複数のBサービスの管理を必要とし、負荷分散戦略のゲートウェイサービスを行います。
予備的なアイデア：
サービスの最初のゲートウェイアプリケーションリソース（サービスBを要求したい）意志、ゲートウェイが特定のポリシーに基づいて行われます、「比較的自由」であるあなた自身のBに以下のすべてのサービスを分析し、サービスBサービスAに発行された「アドレス」、サービスB A後のサービスは、このデータを送信します。もちろん、我々はまた、適切なサービスBに対応する制御情報を送信する必要があります 図は、線Aおよび表Redisのまたはゲートウェイに接続された：コントロール、要求又は応答メッセージが、青い線は、パスに大量のデータを表します。
現在、この作品は後のアップデートではありません。
