クラウドネイティブシステムの弾力性モデル

[[410918]]

この記事はWeChatの公開アカウント「Lean Coder」から転載したもので、著者はXiaomajiaです。この記事を転載する場合は、Lean Coder の公開アカウントにご連絡ください。

概要

1. クラウドネイティブシステムの回復力パターン

• 1.1 サービス障害による雪崩効果
• 1.2 クラウド ネイティブ エラスティック リクエストに関する前回の質問への回答は?

2. 弾力性モード: 下流のリクエストメッセージに基づいて動作する

3. 短時間中断時の応答コード

4. ポリークラシック戦略

5. Golang サーキットブレーカーパターン

ドイツの哲学者ニーチェはかつてこう言いました。「私を殺さないものは私を強くする。」

01クラウドネイティブシステムの弾力性モデル

今回は、最近の仕事の経験も踏まえて、引き続きクラウドネイティブの弾力性モデル（スケールではなく回復力）についてお話しします。これは「現代のクラウドネイティブ設計コンセプト」への回答でもあります。

「分散アーキテクチャでは、サービス B がサービス A からのネットワーク要求に応答しない場合はどうなるでしょうか?

サービス C が一時的に利用できなくなり、C を呼び出す他のサービスがブロックされた場合はどうすればよいですか?

ネットワークの問題またはサービス自体の理由により、サービス B と C は時間内に応答できず、サービス A によって開始された要求はブロックされます (B と C が応答するまで)。このとき、大量のリクエストが殺到すると、サービス A のスレッドリソースが枯渇し、サービス A の処理性能に大きな影響が出てしまい、ダウンストリームが依存する外部クライアント/バックエンド srv にも影響が出てしまいます。

障害は広がり、連鎖反応を引き起こし、分散構造全体に壊滅的な結果をもたらします。これはサービス障害の「雪崩効果」です。

サービス B と C が利用できない場合、ダウンストリーム クライアント/バックエンド srv は何ができますか?

客観的に見ると、リクエストは失敗し、事前に決定された弾性戦略（再試行/回路切断）が実行されます。

02 エラスティックモード: ダウンストリームリクエストメッセージに基づく動作

レジリエンス モードとは、障害が発生してもシステムが正常な動作を維持する能力です。失敗を避けるのではなく、失敗を受け入れてそれに対処しようとすることです。

Polly は、開発者が流暢かつスレッドセーフな方法で回復力戦略を表現できるようにする、包括的な .NET 回復力および一時エラー処理ライブラリです。

一般的に、エラスティック ポリシーはさまざまな要求メッセージ (外部クライアント要求またはバックエンド サービス要求) に適用されます。

その目的は、一時的に利用できないサービス要求を補うことです。

03 短時間中断時の応答コード

正確で標準化された応答コードは、開発者ができるだけ早く障害を特定するのに役立ちます。

失敗戦略を実行するときは、失敗によって発生した操作のみを再試行し、403UnAuthorized を再試行しないなど、より対象を絞ることもできます。

04ポリーの定番戦略

• 再試行: ネットワーク ジッタ/一時エラーに対して再試行戦略を実装できます (障害はすぐに回復すると予想されます)。
• サーキットブレーカー: 無効な再試行による障害の伝播を回避するために、一定時間内に障害の数がしきい値に達すると、サーキットブレーカーが開きます (一定時間内の高速障害)。

同時にタイマーが起動し、ブレーカーは半開モードになります（少数の要求を発行し、要求が成功すると障害が修復されたとみなされ、ブレーカーは閉状態になり、障害カウンターがリセットされます）。

 services.AddHttpClient( "小さい" )
        //ダウングレード
        .AddPolicyHandler(Policy<HttpResponseMessage>.HandleInner<Exception>().FallbackAsync(新しいHttpResponseMessage(),async b =>
        {
           // 1. ダウングレード印刷例外
          Console.WriteLine($ "サービスが低下し始めました。アップストリーム例外メッセージ: {b.Exception.Message}" );
          // 2. ダウングレード後のデータ
          b.Result.Content = new StringContent( "リクエストが多すぎます。後でもう一度お試しください" , Encoding.UTF8, "text/html" );
          b.Result.StatusCode = HttpStatusCode.TooManyRequests;
          Task.CompletedTask を待機します。
        }))
        //ヒューズ
        .AddPolicyHandler(ポリシー<HttpResponseMessage>.Handle<例外>()
           .サーキットブレーカー非同期(
              3, // 回路ブレーカーが開くまでの障害回数
              TimeSpan.FromSeconds(20), // 回路ブレーカーを開く時間間隔
              (例: ts) => //ヒューズオープン
              {
                  Console.WriteLine($ "サービス回路ブレーカーが開いています。例外メッセージ: {ex.Exception.Message}" );
                  Console.WriteLine($ "サービス回路ブレーカーの開放時間: {ts.TotalSeconds}s" );
              },
              () => { Console.WriteLine($ "サービス回路ブレーカーがリセットされました" ); }, // サーキットブレーカーリセットイベント
              () => { Console.WriteLine($ "サービス回路ブレーカーが半分開いています (しばらく開いて、しばらく閉じています)" ); } // サーキットブレーカー半開イベント
            ）
        ）
        //リトライ
        .AddPolicyHandler(ポリシー<HttpResponseMessage>.Handle<Exception>().RetryAsync(3))
       // タイムアウト
       .AddPolicyHandler(Policy.TimeoutAsync<HttpResponseMessage>(TimeSpan.FromSeconds(2))); 
        

アプリケーションに複数の HTTP 呼び出しがある場合、上記の従来の記述方法に従うと、コードには多くの重複した無関係なビジネス コードが混在することになります。

バッチ HttpClient の弾力的な戦略をエレガントに実装する方法について考えます。

ここでは 2 つの方法を紹介します。

① Blog Parkの有名ブロガーEdisonchou: AOPフレームワークを使ってPollyを動的に織り込む

② 匿名の専門家が、リフレクションと構成を使用してPollyHttpClientServiceCollectionExtension拡張クラスを実装しました。これは、構成ファイルでHttpClientNameを指定することをサポートしています。

[[410921]]

05Golang サーキットブレーカー

github.com/sony/gobreaker にアクセスしてください

func NewCircuitBreaker(st Settings) *CircuitBreaker 回路ブレーカー オブジェクトをインスタンス化します。パラメータは次のとおりです。

型設定構造体{
名前文字列
    MaxRequests uint32 #ハーフオープン状態で許可されるリクエストの最大数。デフォルト値は 0 で、1 つのリクエストが許可されます。
    間隔時間.期間
    タイムアウト時間.期間 # 回路ブレーカーが半開状態になるまでの間隔。デフォルトは60秒です。
    ReadyToTrip func(counts Counts) bool # 状態を切り替えるロジック
    OnStateChange 関数(名前文字列、変更元状態、変更先状態)
 }

次の例は、Google Web サイトをリクエストするときに、失敗率が 60% に達すると、「オープン」状態に切り替わり、同時に 60 秒のタイマーが開始されることを示しています。 60 秒後、「半オープン」状態になります (1 つのリクエストを開始できるようになります)。成功した場合、回路ブレーカーは「閉」状態になります。失敗した場合は、「オープン」状態に戻り、60 秒のタイマーをリセットします。

パッケージメイン
輸入 （
 「fmt」  
 「io/ioutil」  
 "ログ"  
 「ネット/http」  
 「github.com/sony/gobreaker」  
 ）
 var cb *gobreaker.CircuitBreaker
関数init() {
    var st gobreaker.設定
    st.名前= "HTTP GET"  
    st.ReadyToTrip = func(counts gobreaker.Counts) bool {
        失敗率:= float64(counts.TotalFailures) / float64(counts.Requests)
戻り値 counts.Requests >= 3 && failureRatio >= 0.6
    }
    cb = gobreaker.NewCircuitBreaker(st)
 }
 // CircuitBreakerでhttp.Get をラップします。
 func Get(url string) ([]byte, error) {
    本文、エラー:= cb。実行(func() (interface{}, error) {
        応答、エラー:= http.Get(url)
        err != nil の場合 {
 nil、エラーを返す
        }
        延期resp.Body.Close ()
        本文、エラー:= ioutil.ReadAll(resp.Body)
        err != nil の場合 {
 nil、エラーを返す
        }
本体を返す、nil
    })
    err != nil の場合 {
 nil、エラーを返す
    }
 body.([]byte)、nilを返す
}
関数main() {
    本文、エラー:= Get( "http://www.google.com/robots.txt" )
    err != nil の場合 {
        ログ.致命的(エラー)
    }
    fmt.Println(文字列(本文))
 }

要約する

この記事では、クラウド ネイティブ システムの弾力性モデルについて説明します。弾力性モデルとは、事前設定された戦略を通じて障害に直接対処し、一時的に利用できない要求を補正し、障害の伝播を回避することです。これは、マイクロサービスの高可用性と弾力的なフォールト トレランスを実現するために非常に重要です。