私はいくつかのマイクロサービス（残りのテンプレートを持つspring mvc）を持っていて、REST（主に非同期）を介して互いに通信しています。マイクロサービス/ RESTフォールトトレラントコミュニケーション
問題は、私はいくつかのフォールトトレランス機能をシステムに追加したいと思います。例えば他のシステムが要求している間にマイクロサービスの1つがダウンしている場合、この要求は自動的に後で再試行されます。だから、
、基本的に私はRESTプロキシのいくつかの種類、探しています：
これにはプロジェクト/ライブラリはありますか？
おかげで、 krisy
あなたがドッキングウィンドウを使用してmutlipleホストマシン上で（ドッキングウィンドウの群れのように、kubernetes ...）コンテナオーケストレーションのいくつかのフォームを持っているなら、あなたは、各microserviceランニングのmutlipleレプリカを持つことができ、自動復旧障害後、レプリカ間のロードバランシングとシンプルなネットワーキング（サーバIPはマイクロサービス名の必要はありません）。
しかし、これはまた、同じアプリケーションを実行している複数のレプリカを持つ（データの一貫性...）という複雑さを追加します。
しかし、いくつかの外部データベースまたはファイルシステム上にデータが保存された状態で、各サービスの1つのレプリカで実行されているswarm（複数のサーバー）を持つことができます。次に、サーバーの1つが死んだり、サービスの1つが問題に遭遇したりすると、新しいインスタンスがスピンアップし、すべての要求がこのスピンアップを待機します（サービスは、お互いのIPを知りません。話をするには、オーケストレーターがサービスをリンクします）。
最も簡単な設定では、サーバーが1つだけのswarmもあり、ローカルDBまたはファイルシステムに何かを格納できます。美しさは、あなたの設定が既にスケーリング可能な技術で構築されていることです。
Springのソリューションを使用する準備が整いました。Spring Cloud + Eureka + Hystrix + Zuul + Ribbon @Retryable @Recoverアノテーションでspring-retryを使用することもできます。
私はSpringの再試行を見つけました。これはとてもいいプロジェクトのようです（なぜSpringコアにないのでしょうか？） - メモリ内のクライアント側の解決策の代わりに、別のマイクロサービスまたは永続的なクライアントサイドのソリューションです。 – krisy
メッセージングサービスのように聞こえるか、キューを使用してコードを記述する必要があります。非常に大容量で大容量のデータであることが予想される場合は、データベースへのすべてのコールを書き留め、データベーステーブルを読み込んでフラグを更新するデーモンスレッドを作成し、一度読んで休憩サービスを呼び出します。 （スレッドの実装は、ソース送り先、要求データ、および応答データを読み取ることができます）。もちろん、定期的にテーブルを清掃してください。 – surya
[Netflixリボン]（https://github.com/Netflix/リボン）、[RxNetty]（https://github.com/ReactiveX/RxNetty）をご覧ください。リトライ機能を提供しています。 @suryaで述べられているように、メッセージブローカーがより適しています。 –
クライアント側の解決策は、私がプロキシについて考えている主な理由です。マイクロサービスの一部があまり信頼性がないので、クラッシュする可能性があります（サードパーティのプロキシもクラッシュする可能性がありますが、それはそうではありません）。何らかの永続ストレージ戦略があれば、リボンはいいかもしれません。 – krisy