SpringCloud Alibaba - Sentinel マイクロサービス保護は雪崩問題、Hystrix の違い、インストールと使用を解決します

マイクロサービスでは、ビジネスはより複雑になる傾向があり、1 つのビジネスサービスが複数のサービスに依存する場合があります。たとえば、内部的にサービス b、サービス c、およびサービス d に依存するサービス a があります。次に、サービス d が失敗したとします。サービス a は次のものに依存しますサービス d に対する要求は引き続き正常に応答できますか? 当然そうではありません。リクエストが来た後、サービス d の応答を待たなければなりません。サービス d は失敗して正常に応答を返すことができないため、ここでブロックされ、サービス a の内部業務がここでブロックされます。 tomcat接続が解除されません。

この時点では、サービス a が依存するサービス b またはサービス c の業務はまだ正常に実行できますが、サービス d に依存するリクエストが確実に複数ある場合、それらのリクエストは接続を解放せず、サービス a 内のすべての接続が発生します。占有されている場合、接続リソースが枯渇し、依存サービス b とサービス c が失敗します。

これは最も深刻なことではありません。マイクロサービスの呼び出し関係は非常に複雑です。つまり、サービス a に依存する他のサービスも存在し、サービス a に依存する他のサービスの障害がさらに発生します。、マイクロサービスグループ全体が崩壊します。

1.2. 雪崩問題の解決策

1.2.1. タイムアウト処理

タイムアウト処理：タイムアウト時間を設定し、一定時間が経過してもリクエストが応答しない場合、延々と待たずに直接エラーメッセージを返します。

先ほどの栗を例に挙げると、サービス a は内部的に b、c、d に依存しています。このとき、d が失敗すると、c に依存している a の内部サービスはすべてブロックされ、やがて a が崩壊します。タイムアウト処理あり？

彼は、呼び出されたビジネスに 1 秒などのタイムアウトを追加します。つまり、d に依存するビジネスの場合、最大 1 秒待機します。d が失敗し、待機時間が 1 秒を超えた場合、リクエストは直ちに終了します。応答を待つ必要がなくなり、ユーザーにはリクエストが失敗したことが通知されるため、接続リソースが常に占有されることはなく、雪崩の問題をある程度軽減できます。

欠点: 雪の問題を 100% 解決するのではなく、雪崩の問題を「緩和」するだけなのはなぜですか?

リソースを解放するのに 1 秒だけ待機すると仮定します。つまり、接続を 1 秒で解放した場合、解放したリクエストよりもリクエストが速く来ると (たとえば、リクエストごとに 500 ミリ秒)、ある日、リソースがサービス a は解放されますが、枯渇する可能性もあります (貯水池と同じように、水は出ていくよりも早く流入し、ある日、貯水池の水はあふれます)。

したがって、タイムアウト処理ではこの問題を根本的に解決することはできません。

1.2.2. バルクヘッドモード

隔壁モデルの関与は私たちの現実生活から来ています~一部の大型船は隔壁(隔壁とも呼ばれます)を使用して船体を独立した小さな空間に分割し、その空間は互いに隔離されています。船の一部が氷山に衝突して水漏れが発生しても、せいぜい客室の一部が水で満たされるだけで、船体全体が水で満たされることはなく、最終的には船が沈没します。船全体の耐災害性。

このプログラムに含まれるアプローチは、Tomcat を船全体として扱い、Tomcat 全体のリソースを使い果たさないように各企業が使用できるスレッドの数を制限する (バルクヘッド分離に相当) というものであるため、この方法は「スレッド分離」とも呼ばれます。

先ほどの栗の部分を取り上げましょう。各ビジネスにスレッドプールが割り当てられ、スレッドの最大数が 10 に制限されているとします。この時点で、サービス d が失敗すると、他のビジネスの占有を避けるために、サービス d は最大 10 個の接続リソースしか占有することができません。 . 接続リソース。

デメリット：資源の無駄遣い

このモデルは雪崩の問題を解決しますが、リソースのある程度の無駄は依然として存在します。たとえば、サービス d が実際にダウンしている場合、ダウンしていることが明らかにわかっている場合でも、10 スレッドが占有されるまでリクエストは依然として返されます。したがって、CPU リソースも無駄になります。

1.2.3. サーキットブレーカーのダウングレード

このモードにはサーキットブレーカーがあり、サービス障害リクエストと通常リクエストの比率をカウントするために使用できます。しきい値を超えると、サービスが切断され、サービスにアクセスするすべてのリクエストが傍受されます。

先ほどの例で、サービスaにある事業者がサービスdにアクセスすると、最初のアクセスは正常ですが、その結果、次の2回は障害が発生します。このとき、ヒューズが異常を計算します。しきい値が 50% であると仮定します。3 つのリクエストのうち 2 つに問題があり、しきい値を超えているはずです。この時点でサーキットブレーカーが発生します。その後、サービス a 内で、ビジネスがサービス d にアクセスします。インターセプトされ、すぐにリソースが解放されます。

この方法はアバランシェ問題を解決するだけでなく、バルクヘッドモードでのリソースの無駄も解決するため、サーキットブレーカー劣化モードはアバランシェ問題に対するより良い解決策となります。

1.2.4. フロー制御

トラフィック制御とは、業務アクセスのqps（1秒間に処理されるリクエスト数）を制限し、トラフィックの急激な増加によるサービス障害を回避することです。

たとえば、マイクロサービスが耐えられる最大 QPS は 2、つまり 1 秒あたり最大 2 つのリクエストを処理できますが、現在は 100 件のリクエストが来ているため、フィルタリングする必要はありませんが、Sentinel はこの QPS に基づいて処理します。リクエストを制限し、処理してから解放します（これは、大量の水が注がれようとしているときに、最初に漏斗を通過し、この漏斗を通して水の流れが制限されるのと似ています）。、障害を効果的に回避できます(超過したリクエストはインターセプトされ、デフォルトでエラーが報告されますが、順番に待機してウォームアップするように構成することもできます)。

フロー制御は前の 3 つの方法とは異なり、最初の 3 つの方法はサービスに障害が発生した場合に使用され、フロー制御は障害を回避するために qps を制限します。

誤解: 最初の 3 つの方法を使用せずに、フロー制御だけを使用することは可能ですか?

もちろん、同時実行性の高さが原因でサービスが失敗することは、失敗の原因の 1 つにすぎず、ネットワークの問題やアニメーションの一時停止など、他の問題によってサービスが失敗することもよくあります。

ただし、上記の 3 つのソリューションのうち、バルクヘッドモード、サーキットブレーカーの劣化、およびフロー制御に焦点を当てます。

1.3. Sentinel と Hystrix の違い

Hystrix は、ここ数年で Spring Cloud が普及したばかりのときに、誰でも使用することを推奨されるサービス保護メカニズムです。Netflix によって作成されましたが、その後、同社は Hystrix のアップグレードと保守を停止すると発表しました。徐々に衰退したため、人々は新しい計画を探し始めました。

このとき、Alibaba は Sentinel というプロジェクトをオープンソース化し、Spring Cloud のサービス保護コンポーネントとなり、現在では国内のインターネット企業で広く使用されています。

ここで両者を比較してみます。

	センチネル	ヒストリックス
隔離戦略	セマフォの分離	スレッドプール分離/セマフォ分離
サーキットブレーカーのダウングレード戦略	スローコール比率または異常比率に基づく	故障率に基づく
リアルタイムインジケーターの実装	スライドウィンドウ	スライディングウィンドウ (RxJava ベース)
ルールの設定	複数のデータソースをサポート	複数のデータソースをサポート
スケーラビリティ	複数の拡張ポイント	プラグインフォーム
注釈ベースのサポート	サポート	サポート
制限する	QPSに基づいて、呼び出し関係に基づいた電流制限をサポート	限定的なサポート
トラフィックシェーピング	スロースタートおよび均一キューイングモードをサポート	サポートしません
システム適応型保護	サポート	サポートしません
コンソール	すぐに使用できるルールの設定、第 2 レベルの監視、マシン検出などの表示を行うことができます。	不完全
共通フレームワークの適応	サーブレット、Spring Cloud、Dubbo、gRPCなど	サーブレット、Spring Cloud Netflix

主な違いは赤い文字です。

a) 隔離戦略

hystrix の最下層はスレッドプールとセマフォに基づいています。デフォルトでは、スレッドプールが使用されます。sentinel の最下層はセマフォに基づいています。これら 2 つの方法の違いは何ですか?

スレッドプールの分離とは、各ビジネスチェーンがリクエストを処理するための独立したスレッドプールを持つことを意味します。ただし、リクエストの数が突然増加すると、より多くのスレッドが発生し、CPU に追加のコンテキストスイッチング消費が発生します (スレッドが増えるほど、前述の「おかしなニワトリのグループ」の栗のように、さらに良いです）。

セマフォ分離では、別個のスレッドプールは作成されませんが、大きなスレッドプールが使用されます。リクエストが到着すると、現在のビジネスで使用されているスレッドの数をカウントする統計が作成され、現在のビジネスで使用されるスレッドの数が制限されます。ビジネス。たとえば、10 のみ使用できます。すでに 10 を使用している場合は、スレッドを取得する新しいビジネスがあったときにブロックされます。プールはそのプールであり、デフォルトでは新しいスレッドは作成されません。したがって、パフォーマンスには影響しません。

この方法はスレッドプールの分離に比べて分離度が若干低いため、同じプールに比べればただの大きなポットであり、全員が別々のボウルを持っているだけで、比較的パフォーマンスが高いため、セマフォソリューションは有効であると考えられます。より良い。

b) サーキットブレーカーの劣化

Sentinel では、異常なリクエストの割合をカウントすることに加えて、遅い呼び出しの割合もカウントできます。

ビジネスでは、10 件中 8 件のリクエストに時間がかかり、サービス全体の速度が低下する可能性があるため、この時点で切断されます。

c) 電流制限

Sentinel では、QPS、呼び出し関係に基づく電流制限、さらにはホットスポットパラメータに基づく電流制限もサポートしています。

hystrix には特別な電流制限制御はなく、スレッドプールにのみ基づいて、プール内のスレッド数の上限を設定して電流を制限します。

d) トラフィックシェーピング

Sentinel では、スロースタート (予熱モードまたは均一キューイング) に基づいてバーストトラフィックを安定したフローレートに変換するトラフィックシェーピングがサポートされています。

ただし、hystrix はそのような機能をサポートしていません。

e) コンソール

コンソールはいわゆるビジュアルインターフェイスであり、操作に便利です。

Sentinel では、コンソールでマイクロサービスを監視し、実行ステータスを確認できるだけでなく、ダウングレードルールとフローファーストルールを構成することもできます。これらのルールは、設定後すぐに動的に有効になります。

hystrix では、コンソールはサービスステータスを表示する機能のみをサポートします。

したがって、相対的に見て、センチネルコンソールの機能はより強力です。

1.4. Sentinel のインストール

Sentinel は、システムの電流制限の設定を容易にする UI コンソールを公式に提供しています。

a) GitHub からダウンロードできます。

git clone https://github.com/alibaba/Sentinel.git

b) jar パッケージをダウンロードした後、それを中国語以外のディレクトリにコピーし、ターミナルを開いて次のコマンドを使用します。

java -jar sentinel-dashboard-1.8.1.jar

Ps: 公式チュートリアルで使用されるポートは 8080 で、ユーザーはカスタマイズできます。

Sentinel のデフォルトのポート、アカウント、パスワードを変更したい場合は、次のように設定できます。

設定項目	デフォルト値	説明する
サーバポート	8080	サービスポート
センチネル.ダッシュボード.認証.ユーザー名	番兵	デフォルトのユーザー名
センチネル.ダッシュボード.認証.パスワード	番兵	デフォルトのパスワード

たとえば、ポート番号を 8090 に変更します。

java -jar sentinel-dashboard-1.8.1.jar -Dserver.port=8090

c)次に、localhost:8080にアクセスしてコンソールページを表示します。デフォルトのアカウントとパスワードはSentinel です。

ログインに成功すると、ウェルカムページが 1 つだけ表示されますが、これはマイクロサービスで Sentinel 情報を構成していないためです。

1.5. Sentinel をマイクロサービスプロジェクトに統合する

1.5.1. マイクロサービスエンジニアリングの紹介

プロジェクトの構造は次のとおりです。

ゲートウェイ: ゲートウェイ。
user-service: ユーザーの CRUD を含むユーザーサービス (ユーザーテーブルを含む)。
order-service: 注文サービス (注文テーブルを含む) 注文を照会すると、ユーザーサービスがリモートで呼び出され、注文とユーザー情報が一緒に表示されます。
feign-api: ユーザーサービスは、偽のクライアントクラスとエンティティクラスを外部に公開します。

ユーザーテーブルは次のとおりです。

注文フォームは以下の通りです。

1.5.2. Sentinelの統合

Sentinel を order-service に統合し、Sentinel コンソールに接続する手順は次のとおりです。

a) オーダーサービスにセンチネルの依存関係を導入する

<!--sentinel-->
<dependency>
    <groupId>com.alibaba.cloud</groupId> 
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

b) コンソールアドレスを設定します。

spring:
  cloud: 
    sentinel:
      transport:
        dashboard: localhost:8080

c) order-service サービスの任意のエンドポイントにアクセスして、センチネル監視をトリガーします。

追伸: マイクロサービスを開始する前に、nacos と Sentinel を忘れずに開始してください。