「SpringBoot ミドルウェアの設計と実践」第 2 章 サービス ガバナンス、タイムアウト ヒューズ

需要の背景

たとえば、トラフィックが多いシナリオでは、ユーザーは電子商取引プラットフォームで注文した後、支払いを行うためにオンライン レジにジャンプし始めます。決済チャネルやネットワーク環境にはいつでも問題が発生する可能性があるため、決済システムの信頼性をどのように確保しているのでしょうか?

決済システムの信頼性を確保するために考慮すべき点は数多くありますが、ここで最も直接的かつ重要な内容は、決済応答時間です。最終的にはすべてのサービスがダウンします。

このとき、機能コンポーネントとしてタイムアウトやヒューズ hystrix が考えられるかもしれません。これは、ほとんどの決済システムでも必要なコンポーネントですが、どのように使用しますか? このような機能コンポーネントをすべてのインターフェイスに追加しますか? 明らかにそうするのは不適切です。一般に、このようなコンポーネントは、システムに埋め込まれている可能性があります。 RPC インターフェースや自社開発のゲートウェイ、あるいはサービス管理層全体の機能配置上にある場合もあります。つまり、簡単には公開されず、ビジネス ロジックの実装にハードコーディングできます。

次に、この章では、コンポーネント パッケージ化のコア実装を示します。どの実装も現在のシステム環境に最も適した方法で設計されており、必ずしも特定の形式に厳密である必要はないことに注意してください。

デザイン

複雑なシーンの問題に直面しても、基本的には解決策が市場にあります。この章で必要な通話タイムアウト保護システムと同様に、対応する技術コンポーネント hystrix があります。これは、Netflix によってオープンソース化されたフォールト トレラント フレームワークであり、ほとんどの RPC サービスでも導入され、使用されています。

次に、便利でシンプルになりたいだけで、そのようなサービスを作成して使用した結果を返す方法を気にする必要がない場合は、中間で hystrix フレームワークをラップし、呼び出しロジックをシールドすることができます。全体的な設計スキームを図 4-1 のタイムアウト ヒューズ ミドルウェア フレームワーク設計に示します。

一般的な考え方は次のとおりです。

おすすめ

転載: blog.csdn.net/weixin_42329623/article/details/130477450