0

最近、オンプレミスの Service Fabric の使用を開始することを決定しましたが、「依存関係」の問題が発生しました。

それらの間に依存関係があるいくつかのゲスト実行可能ファイルがあり、それらが依存しているサービスの再起動からは再起動しないと回復できません。

明確にするための例：

下の図では、サービス B はサービス A に依存しています。サービス A で予期しないエラーが発生して再起動すると、サービス B は「エラー」状態になります (ファブリックには報告されません)。これは、サービス B がエラー状態であっても正常性状態が OK であることを報告することを意味します。

私たちは、これらの行に関する解決策を考えていました:

クラスター内のすべてのレプリカ/パーティション/アプリケーションのヘルス状態イベントを監視し、依存関係ツリー全体を含む独立したサービスを起動します。

サービスのヘルス状態が変化すると、サービスは直接の依存関係を再起動します。これにより、イベントのドミノ効果が発生します -> サブツリー全体がリセットされるまで再起動します (以下のイベント -> アクション フロー チャートに示すように)。

イベント アクション フロー

問題は、healthReport イベントが短い間隔で送信されないことです (つまり、システム全体が機能せず、数分間わからないということです)。正常性の状態を監視しますが、履歴を知る必要があります (状態が現在正常であっても、以前にエラー状態ではなかったという意味ではありません)。

もう 1 つの問題は、イベントが任意のサービス レベル (レプリカ/パーティション) でポップされる可能性があり、すべてのイベントを集約する必要があることです。

この問題について何か助けていただければ幸いです。また、この問題に対する他の提案については、まったく別の方向であっても、完全にオープンです。

4

1 に答える 1

1

サービス間のカスケード障害は、通常、サービス間の通信境界にフォールト トレランスを導入することで回避できます。これを達成するためのいくつかの戦略：

  • 間に遅延を設けて、失敗した操作の再試行を導入します。遅延間の時間は指数関数的に増加する可能性があります。現在、サービス間でリモート プロシージャ コール (RPC) スタイルの通信を多数行っている場合、これは簡単に実装できるオプションです。依存するサービスの再起動にあまり時間がかからない場合は、非常に効果的です。Pollyは、再試行を実装するためのよく知られたライブラリです。

  • サーキット ブレーカーを使用して、障害のあるサービスとの通信を閉じます。この比喩では、正常に通信する 2 つのサービス間に閉回路が形成されます。サーキット ブレーカーは通信を監視します。失敗した通信がいくつか検出されると、回路が「開かれ」、それ以降の通信はすぐに失敗します。次に、サーキット ブレーカーは、障害が発生したサービスに定期的なクエリを送信して正常性をチェックし、障害が発生したサービスが動作可能になると、サーキットを閉じます。これは、開回路がサービスをクラッシュさせないようにする責任と、健全なサービスを構成するものを決定する責任があるため、再試行ポリシーよりも少し複雑です。Polly はサーキット ブレーカーもサポートしています

  • キューを使用して、サービス間の完全な非同期通信を形成します。サービス B から A に直接通信する代わりに、サービス B の A へのアウトバウンド操作をキューに入れます。独自のスレッドでキューを処理します。通信障害がキュー プロセッサをエスケープできないようにします。サービス A にインバウンド キューを追加して、サービス B のアウトバウンド キューからメッセージを受信し、ネットワークからメッセージ処理を完全に分離することもできます。これはおそらく最も耐久性がありますが、RPC とは非常に異なるアーキテクチャを必要とするため、最も複雑でもあります。繰り返し失敗するメッセージを処理する方法も決定する必要があります。失敗したメッセージをすぐに再試行するか、遅延後にキューの最後に送信するか、手動処理のためにデッド レター コレクションに送信するか、メッセージを完全に削除することができます。あなた以来

于 2019-03-31T18:12:34.353 に答える