コールフォワーディングとハイTPSの場合、回路ブレーカー付きのhystrixは良好ですか？

Question

私は3つのサービスA、B、Cを持っています。Aは2つのソースからの呼び出しを受け取り、ほとんどの呼び出しをBサービスに転送し、一部はCに転送し、URIに基づいていくつかを処理します。 BまたはCへの​​コールを転送する前に、Aはちょっとした作業を行います。サービスAで処理される1秒あたりのピーク要求数は約60です.60のうち55のAPI呼び出しがサービスBに転送されます。サービスBの2〜3つの高頻度APIがあります。

私はSpring Boot 1.4.1とSpring Cloud Camden.RELEASEを使用しています。ローカルのWindowsマシンでJMeterを使用した私の実験によれば、サービスは1秒あたりの要求された要求を処理できることがわかります。サービスAをサーキットブレーカとして作成し、高周波APIコールを@ HystrixCommandでラップすると、パフォーマンスが以前よりも悪くなることがわかります。 hystrixによって多くのAPI呼び出しが失敗し、フォールバックが呼び出されます。その後、execution.isolation.thread.timeoutInMillisecondsコマンドプロパティの値を "30000"に変更し、コアサイズスレッドプールのプロパティ値を "50"に変更すると、すべての呼び出しが成功しました。私はhystrixのものを有効にすると、サービスAは〜50スレッドを前よりも必要とすることを観察しました。より多くの負荷がかかると、API実行時間が長くなり、タイムアウトプロパティ値が増加します。 hystrixコマンドを使用してサービスA内のサービスBに

回路ブレーカとしてサービスAを作製し、高 周波数コール（またはすべての呼び出し）を包む場合

1. を疑問に思うが

2. 良い決定されはいの場合は、手動でスレッドカウントを変更/増加させるのは悪くないですか 将来のTPSの必要性に基づいて、ヒストリプール内の設定を通じて を設定しますか？春ブーツ は自動的に私はタイムアウトプロパティを変更する必要があるとして

3. 負荷を提供するためのスレッド・プールを扱うようhystrix状況は単純ですがなければ、サービスBは が停止しているときに、今、Aまたはhystrixは、サービスを検出するために、数秒かかりますBは に到達できません。カスケード接続を停止するためにヒステリックを使用することの実際の利点 サービスを終了または停止することはあまりありません。それでもヒステリックがお勧めですか？

4. Netflixは、コアサイズをデフォルトで10に設定することをお勧めしています。これらは、 が25を超えない範囲で使用されています。私の場合は、必要があなたの提案は、回路ブレーカとhystrixは、私の場合に有用であるか、我々はそれが有用なものにすることができる方法、またはそれをよりここで他の場合に特に知って、ここでは参考になる50

です適切（TPSはどのサービスにも低い）。 config docに

Answer 1

ベース：コールが別のスレッドのオーバーヘッドがあること（インスタンスごとに、毎秒数百）が大量である場合に一般

あなたがセマフォ分離（セマフォ）を使用しなければならない唯一の時間であります高すぎる;