1 基本的な紹介
Sentinel と Hystrix の原理は同じです。呼び出し側リンクのリソースのパフォーマンスが不安定である (リクエストの応答時間が長い、または比率が異常に増加しているなど) ことが検出されると、このリソースの呼び出しは制限され、他のリソースへの影響や連鎖的な障害の発生を回避できません。
Sentinel はこの問題に対して 2 つのアプローチをとります。
同時スレッド数による制限
リソース プールの分離方法とは異なり、Sentinel はリソースの同時スレッド数を制限することで、不安定なリソースが他のリソースに与える影響を軽減します。これにより、スレッド切り替えのコストが削減されるだけでなく、スレッド プールのサイズを事前に割り当てる必要もなくなります。応答時間が長くなるなど、リソースが不安定になると、スレッドが徐々に蓄積され、リソースに直接影響します。特定のリソースのスレッド数が一定の数に達すると、そのリソースに対する新しいリクエストは拒否されます。スタックされたスレッドは、リクエストの受信を続ける前にタスクを完了します。
遅い呼び出しと例外のためのリソースの低下
Sentinel は、同時スレッドの数を制御することに加えて、応答時間や例外などの不安定な要因に基づいて、不安定な呼び出しを迅速にサーキット ブレークすることもできます。依存リソースの応答時間が長すぎる場合、リソースへのすべてのアクセスは直接拒否され、指定された時間枠が経過するまで徐々に復元されません。
システム適応型保護
Sentinel は、システム次元の適応型保護機能も提供します。雪崩の防止はシステム保護の重要な部分です。システムの負荷が高いときにリクエストが受信され続けると、システムがクラッシュして応答できなくなる可能性があります。クラスター環境では、ネットワーク負荷分散により、このマシンによって伝送されるトラフィックが他のマシンに転送されます。この時点で他のマシンもエッジ状態にある場合、トラフィックの増加によりこのマシンがクラッシュし、最終的にはクラスター全体が使用できなくなります。
この状況に対応して、Sentinel は対応する保護メカニズムを提供して、システムのインレット トラフィックとシステムの負荷のバランスをとり、システムがその能力内でほとんどのリクエストを処理できるようにします。
Hystrix は内部的に、セマフォとスレッド プールという 2 つの実行ロジック モードを提供します。
2 Hystrix セマフォとスレッド プールの違い
hystrix 公式 Web サイトより
デフォルトでは、Hystrix はスレッド プール モードを使用します。
しかし、この 2 つの違いは何でしょうか?また、実際のシナリオではどのように選択すればよいのでしょうか?
セマフォ モードを使用する場合は、パラメータを設定する必要がありますexecution.isolation.strategy =ExecutionIsolationStrategy.SEMAPHORE。
2.1 セマフォモード
このモードでは、リクエストの受信とダウンストリームの依存関係の実行が同じスレッドで完了します。スレッド コンテキストの切り替えによるパフォーマンスのオーバーヘッドがないため、ほとんどのシナリオではセマフォ モードを選択する必要があります。ただし、次の場合、セマフォ パターンは良い選択。
たとえば、インターフェイスは 3 つのダウンストリーム サービス (serviceA、serviceB、および serviceC) に依存しており、これら 3 つのサービスによって返されるデータは相互に依存しません。この場合、A のサーキット ブレーカー ダウングレードにセマフォ モードが使用されているとします。 、B、および C の場合、インターフェイスはサービス A、B、および C を要求するのに必要な時間の合計に等しい時間を消費します。これは間違いなく良い解決策ではありません。
さらに、ダウンストリームの依存関係への同時呼び出しの数を制限するために、Hystrix を構成できますexecution.isolation.semaphore.maxConcurrentRequests。同時リクエストの数がしきい値に達すると、リクエスト スレッドがすぐに失敗し、実行が低下する可能性があります。
実装も非常に単純です。リクエストがヒューズに入ると単純なカウンタが実行されます。tryAcquire()カウンタは 1 ずつ増加します。結果がしきい値より大きい場合、false が返され、セマフォ拒否イベントが発生し、ダウングレード ロジックは次のようになります。実行されました。リクエストがヒューズを離れると、それが実行されrelease()、カウンタが 1 ずつ減らされます。
2.2 スレッドプールモード
このモードでは、ユーザー要求は実行のためにそれぞれのスレッド プールに送信され、各ダウンストリーム サービスを実行するスレッドはリソースの分離を実現するために分離されます。スレッド プールに処理時間がなく、リクエスト キューがいっぱいの場合、新しい受信リクエストはすぐに失敗するため、依存関係の問題の拡大を回避できます。
セマフォ モードで述べた問題に関しては、スレッド プールの非同期実行により、スレッド プールが依存する複数のダウンストリーム サービスのインターフェイス パフォーマンスを効果的に向上させることができます。
アドバンテージ
- 依存するサービスが失敗した場合の影響を軽減します。たとえば、ServiceA サービスで例外が発生すると、多数のリクエスト タイムアウトが発生し、対応するスレッド プールがいっぱいになります。このとき、ServiceB と ServiceC の呼び出しは影響を受けません。
- インターフェイスのパフォーマンスが変化した場合、Hystrix パラメータが動的に調整されていれば、スレッド プールまたはタイムアウトのパラメータを簡単かつ動的に調整できます。
欠点がある
- リクエストはスレッド プールで実行されるため、タスクのスケジューリング、キューイング、コンテキストの切り替えによって確実にオーバーヘッドが発生します。
- クロススレッドを伴うため、メインスレッドで初期化されたThreadLocal変数がスレッドプールスレッドでは取得できないなど、ThreadLocalデータの転送に問題があります。
2.3 注意事項
Hystrix はデフォルトでスレッド プール モードを使用するため、コマンドごとに、初期化中に対応するスレッド プールが作成されます。プロジェクト内にダウングレードする必要があるインターフェイスが多数 (数百など) ある場合、Hystrix についてはあまり知りません。デフォルト設定に従って内部メカニズムを直接使用すると、スレッド リソースが大量に浪費される可能性があります。
3 センチネルの紹介
春雲アリババセンチネル：https://blog.csdn.net/ZGL_cyy/article/details/130874410
SpringCloud Sentinel の実際の電流制限とサーキット ブレーカーのダウングレード アプリケーション:https://blog.csdn.net/ZGL_cyy/article/details/130874410
SpringCloud Sentinel は、ゲートウェイとリアルタイム監視を統合します。https://blog.csdn.net/ZGL_cyy/article/details/130874653