.net core のマイクロサービスのサーキット ブレーカー

よし、こんな感じでいきましょう。

つまり、.NET Core で何かを構築し、サービスをつなぎ合わせて、かなり満足しているのかもしれません。ある日、サービスが停止するまで。クラッシュではありません。ただ…遅いだけです。それからゆっくりと。その後、すべてのバックアップが開始されます。電話が山積みになり、タイムアウトが発生し、無視できない警告サインのようにダッシュボードが点灯します。

それは機械の中で揺れる単一の歯車のようなものです。他のすべてが待機し、緊張し、最終的には全体の動きが停止します。

それがマイクロサービスに関するものです。彼らは話します。たくさん。そして、一部が病気になると、病気が広がる可能性があります。在庫チェックが昼寝をすることになったために、チェックアウト サービスがハングしたことはありませんか?それとも、サードパーティの API でログインが永遠に待ち続けられて困っているのでしょうか?

うん。楽しくない。

ここで「サーキットブレーカー」という概念が登場します。あなたの家の電気ブレーカーを想像してください。何かが過熱し、過大な電流が流れると、クリックしてブレーカーが落ちます。配線を省きます。物事を落ち着かせる時間を与えます。

コードでも同様です。他のサービスへの呼び出しは、小さなウォッチドッグを使用してラップされます。障害がしきい値に達すると、回路が「開きます」。それ以降の呼び出しはすぐに失敗し、待機する必要はありません。スレッドが行き詰まった状態になることはもうありません。しばらくしてから、1 つのテスト コール (ハーフオープン状態) を実行して、リモート サービスが戻っているかどうかを確認します。それが機能すると、回路が閉じます。流れが再開します。

単純？概念的にはそうです。しかし、.NET Core でそれをスムーズにするには…細部への配慮が重要になるのです。

なぜそれがあなたにとって重要なのでしょうか？決済サービスが不正検出サービスを呼び出しているとします。不正検出の応答が遅くなり始めます。過負荷になっているか、ネットワークに問題がある可能性があります。ブレーカーがないと、支払いリクエストがキューに並び、スレッドがブロックされ、支払いパイプライン全体が詰まります。ブレーカーを使用すると、たとえば 1 分間に 5 回の障害が発生すると、一時的に不正検出の呼び出しが停止されます。おそらく、支払いを簡易小切手にルーティングするか、後で確認するために記録するだけかもしれません。一部の機能が低下した場合でも、システムは応答性を維持します。

フルストールよりは良いですよね？

では、これを .NET Core でうまく機能させるにはどうすればよいでしょうか?一から構築する必要はありません。ライブラリ、パターンがあります。ただし、重要なのは、コードを再試行とチェックのロジックの迷路にせずに、フローに組み込むことです。

これは、各サービス間の呼び出しに少しの「スマート」を与えるようなものだと考えてください。しきい値を設定します。開くまでに何回失敗したか?再度テストするまでどれくらい待ちますか?開いているときに何をすべきか — キャッシュされた値を返すか、わかりやすいメッセージをスローするか、代替ワークフローをトリガーするか?

何が起こっているかを記録する必要もあります。 「回路が開かれた」だけではなく、それがなぜ、いつ、何に影響を与えたのか。なぜなら、物事がうまくいかないとき、ただ緊急警報を見るだけではなく、ストーリーを知りたいからです。

ある人が私にこう尋ねたことがあります。「これでは複雑になるのではありませんか?」確かに、少しは。しかし、午前 2 時に 10 個のサービスにわたる連鎖的な障害をデバッグする複雑さと比較してください。私はいつでもサーキット ブレーカーを使用します。

もう 1 つの質問: 「これは外部通話専用ですか?」全くない。内部サービス、データベース呼び出し、さらには同じサービス内の異なるモジュールへの呼び出しでも効果が得られます。予期せず失敗したり速度が低下したりする可能性のあるものに依存しているポイント。

実際には、これを実装することは、空中ブランコ選手の下にセーフティ ネットを追加するような感じです。アーティストは依然としてメインアクトを務めますが、アーティストが滑っても、ネットが素早くきれいにキャッチするため、ショーは続行されます。

Kpowe は、実際の .NET Core 環境向けにこのパターンを微調整するのに時間を費やしました。単なるプラグアンドプレイではありません。それはプラグアンドシンキングです。モニタリングとどのように連携すべきでしょうか?推測せずにしきい値を設定するにはどうすればよいでしょうか?単なるサイレントエラーではなく、フォールバックアクションを実際に役立つものにする方法は?

目標は回復力です。 「動く」だけではなく「部品が壊れても動く」。

したがって、次回サービスを設計するときは、それぞれの外部呼び出しを小さな遠征として想像してください。スカウトを送ります。偵察兵が時間までに戻ってこない場合は、全軍を派遣しないでください。待って。後でもう一度試してください。システムの残りの部分を動かし続けます。

それがサーキットブレーカーの役割です。開かないドアをノックするのをいつやめるべきかを知っているのはスカウトです。

そして、システムがこれまで以上に対話する世界では、この種の知恵はあれば便利なだけでなく、他のすべての作業をスムーズに進めるのに役立ちます。

2005年に設立され、キロパワーは、中国広東省東莞に本社を置く、コンパクトモーションユニットの専門メーカーです。モジュラードライブテクノロジーのイノベーションを活用し、キロパワー高性能モーター、精密減速機、マルチプロトコル制御システムを統合し、効率的でカスタマイズされたスマート ドライブ システム ソリューションを提供します。キロパワーは、スマート ホーム システム、自動エレクトロニクス、ロボティクス、精密農業、ドローン、産業オートメーションなどのさまざまな分野をカバーする製品で、世界中の 500 を超える企業クライアントにプロフェッショナルなドライブ システム ソリューションを提供してきました。