Architecture Thinking Growth チュートリアル シリーズ (4) - どのように「メッセージ」が複雑なシステムを分離するか

バックグラウンド

大規模なインターネット システムでは、ビジネス ロジックが比較的複雑であるか、大規模で同時実行性の高いシナリオのために技術アーキテクチャの複雑さが増しています. このとき、複雑なシステムを分離する必要があります. ここで、メッセージ ミドルウェアはシステムを分離するために使用されます。

コンテンツ

メッセージミドルウェアの使用

最初にいくつかの概念を理解しましょう。

結合:結合度とも呼ばれ、モジュール間の関連度の尺度です。結合の強さは、モジュール間のインターフェイスの複雑さ、モジュールの呼び出し方法、およびインターフェイスを介して転送されるデータの量によって異なります。

モジュール間の結合度とは、制御関係、呼び出し関係、データ転送関係など、モジュール間の依存関係を指します。一般的に言えば、モジュール間の接続が多いほど、結合が強くなり、独立性が低くなります。

結合と結合は通常、モジュールの独立性の度合いを測定するための標準として、ソフトウェア設計で使用されます。モジュールを分割する基準の 1 つは、凝集度が高く、結合度が低いことです。

メッセージ ミドルウェア:プラットフォームに依存しないデータ交換に効率的で信頼性の高いメッセージ配信メカニズムを使用し、データ通信に基づいて分散システムを統合します。メッセージパッシングとメッセージキューイングモデルを提供することにより、分散環境でプロセス間通信をスケーリングします。

メッセージ キューには、主に次の機能があります。非同期処理、トラフィック ピーク クリッピング、およびアプリケーション デカップリング

  • 非同期処理。生産側は消費者側からの応答を待つ必要がなく、直接返されるため、応答時間とスループットが向上します。
  • トラフィック クリッピング。ピーク期間中のトラフィックを均等化するために、コンシューマは自身の速度に従ってトラフィックを処理できます。同時に、リソース使用率を向上させるためにピーク期間中にあまり多くのリソースを追加する必要はありません。
  • アプリケーションの分離。生産者と消費者は互いに依存する必要はありません。

適用シナリオ

1. 非同期処理:

シナリオの説明: ユーザーが注文した後、確認のために電子メールとテキスト メッセージを送信する必要があります。2 つの従来のアプローチがあり、1 つはシリアルで、もう 1 つはパラレルです。

  • a. シリアルモード: 注文情報をデータベースに書き込んだ後、電子メールを送信してからテキスト メッセージを送信し、上記の 3 つのタスクがすべて完了したらクライアントに戻ります。ここでの問題の 1 つは、電子メールやテキスト メッセージは必要なく、単なる通知であり、このアプローチではクライアントが不要なイベントを待機することです。
  • b. 並列モード: 注文情報をデータベースに書き込んだ後、電子メールとテキスト メッセージを同時に送信し、上記の 3 つのタスクが完了した後にクライアントに戻る並列モードでは、処理時間を改善できます。

3 つのサービス ノードがそれぞれ 50ms 使用し、シリアル使用時間が 150ms、パラレル使用時間が 100ms であるとします。並列処理によって処理時間は改善されましたが、前述のように、電子メールと SMS は、ユーザーによる Web サイトの通常の使用には影響を与えません.クライアントは、注文の成功を表示するために送信の完了を待つ必要はありません. . データベースへの書き込み後に返されるはずです。

同期的に

一般的な同期方式で処理すると、システムのパフォーマンスが非常に遅くなります。

スレッドプール - 非同期モード
  • c. メッセージ待ち行列
メッセージ ミドルウェア - 非同期モード

メッセージキューの導入後は、メールやテキストメッセージなどの送信はビジネスロジックに必要ないため、非同期処理を行うことができます。

このことからわかるように、メッセージ キューの導入後、ユーザーの応答時間は、データベースへの書き込み時間 + メッセージ キューへの書き込み時間に等しくなります。応答時間は、シリアルの 3 倍、パラレルの 2 倍です。

2. アプリケーションの分離:

シナリオの説明: ある宝物ダブル 11 ショッピング カーニバルでは、ユーザーが注文した後、注文システムは在庫システムに通知して、在庫のロック操作を実行する必要があります. 従来の方法では、注文システムは在庫システムのインターフェースを呼び出します.

注文の非同期処理

このアプローチには欠点があります。在庫システムに障害が発生すると、注文が失敗します。注文システムと在庫システムは高度に結合されており、解決策はメッセージ キューを導入することです。

  • 注文システム: ユーザーが注文した後、注文システムは永続化プロセスを完了し、メッセージをメッセージ キューに書き込み、ユーザーの注文を返します。
  • 注文しました。在庫システムは、注文メッセージをサブスクライブし、注文メッセージを取得して、倉庫操作を実行します。

インベントリ システムに障害が発生した場合、メッセージ キューは、メッセージの損失を引き起こすことなく、メッセージの信頼性の高い配信を保証することもできます。

3. フロー ピーク クリッピング:

トラフィック ピーク クリッピングは、一般的に seckill システムで広く使用されています。

シナリオの説明: 通常、ショッピング サイトの seckill アクティビティにより、過剰なトラフィックが原因でアプリケーションがハングアップします. この問題を解決するには、アプリケーションのフロント エンドにメッセージ キューを追加します.

フロークリッピング

効果:

  • アクティブな人数を制御でき、一定のしきい値を超える注文は直接破棄されます。
  • 短期的な大流量破砕システムを緩和できます。

変更後の処理フローは次のとおりです。

サーバーはユーザーのリクエストを受け取ると、まずそれをメッセージ キューに書き込み、追加されたメッセージ キューの長さが最大値を超えると、ユーザーのリクエストを直接破棄するか、エラー ページにジャンプします。

seckill ビジネスは、メッセージキュー内のリクエスト情報に従ってフォローアップ処理を実行します。

やっと:

上記では、メッセージ ミドルウェアによる複雑なシステムの分離を紹介しました。メッセージ ミドルウェアの導入は、システムの応答性と使いやすさの向上にも役立ちます。

メッセージ ミドルウェアは、今日のアーキテクチャ テクノロジで非常に一般的に使用されているツールです。

 

前の章のチュートリアル

Architectural Thinking Growth Series チュートリアル (3) - 数億のトラフィック ピークに「キャッシュ」がどのように対処するか

一連のチュートリアル

建築的思考の成長シリーズのチュートリアル

私のコラム

 

 

以上で、すべての紹介は終了です

 

 

-------------------------------

-------------------------------

 

私の CSDN ホームページ

私について(個人ドメイン名、私に関する詳細情報)

私のオープンソース プロジェクト コレクション Github

 

皆さんと一緒に学び、成長し、激励できることを楽しみにしています, O(∩_∩)O ありがとう

質問の交換へようこそ。個人的な QQ 469580884 を追加できます。

または、私のグループ番号 751925591を追加して、コミュニケーションの問題について一緒に話し合ってください

嘘について話さないで、ただ実行者になりなさい

話は安いです、コードを見せてください

おすすめ

転載: blog.csdn.net/hemin1003/article/details/114928533