インターネット エンジニアリングの実践: この分散 IM インスタント メッセージング システムはどのようにして弾力的な拡張と縮小を実現するのでしょうか?

分散型 IM インスタント メッセージング システムの本質は、オンライン チャットとユーザーの管理です。チャット自体の主な要件は、テキスト、画像、ファイル、音声、ビデオの送信、メッセージのキャッシュ、メッセージの保存、未読メッセージ、既読メッセージ、取り消されたメッセージ、オフライン メッセージ、履歴メッセージ、単一チャット、グループ チャット、複数端末の同期、およびその他の要件です。

ユーザー管理の場合、既存のニーズには、友達の追加、友達リストの表示、友達の削除、友達情報の表示、グループチャットの作成、グループチャットへの参加、グループメンバー情報の表示、グループチャットの終了、グループニックネームの変更、グループへの参加の招待、グループからの退出、グループチャットの解散、グループアナウンスの記入、グループメモの変更、その他のユーザー関連のニーズが含まれます。

注: 後で履歴書に書けるように、小さなノートにこれを記録しておいてください。OpenAI の大規模モデルを統合した分散 IM インスタント メッセージング システムです。これからは、あなたの履歴書には、高い同時実行性、高いパフォーマンス、高可用性、監視、早期警告、スケーラビリティを特徴とし、高いスケーラビリティをサポートする別の実際のビジネス シナリオ プロジェクトが記載されることになります。

1. はじめに

分散 IM インスタント メッセージング システムの設計をよりよく理解していただくために、私たちは建築家の視点から説明します。システム要件、ビジネスプロセス、技術プロセスを十分に理解した後、グローバルな視点からシステムのソリューション目標を設定し、技術ソリューションを選択し、システムの全体的なアーキテクチャと階層化アーキテクチャを設計し、メッセージ、シングルチャット、グループチャットの送信のためのインタラクティブリンクを整理します。これにより、誰もが履歴書に「分散型 IM インスタント メッセージング システム」と記載しやすくなり、競争力が高まります。

II.プログラムの目的

テクノロジを選択して全体的なアーキテクチャを設計する前に、1 つ明確にしておく必要があることがあります。それは、システムがどのソリューションやアーキテクチャ設計を採用するかに関係なく、ソリューションのビジネス目標、技術目標、およびアーキテクチャ目標を明確に定義する必要があるということです。研究開発プロセスでは、システム全体のパフォーマンスを継続的に評価し、システムのボトルネックを特定し、継続的な最適化を実行する必要があります。

一般に、私たちが構築および開発する分散 IM インスタント メッセージング システムは、次のソリューション目標を満たす必要があります。

• ビジネス目標: 需要設計の章でさまざまな需要シナリオを満たす。
• 技術目標: 無制限の拡張をサポートし、数百万のユーザーが同時にオンラインでチャットできるようにします。
• アーキテクチャの目標: 高い同時実行性、高いパフォーマンス、高可用性、監視可能性、早期警告、スケーラビリティ、無制限の拡張のサポート。

3. 技術の選択

技術選択においては、SpringBootなどの基本フレームワークの採用に加え、コンテナ化されたソリューションも採用されます。同時に、技術的なハードルを最小限に抑えるために、分散型 IM インスタント メッセージング システム全体の技術選択では、市場でより一般的な技術フレームワークとソリューションが主に採用されます。具体的な選択内容は下記になります。

• 開発フレームワーク: SpringBoot、SpringCloud、SpringCloud Alibaba、Dubbo。
• キャッシュ: Redis 分散キャッシュ + Guava ローカル キャッシュ。
• データベース: MySQL、TiDB、HBase。
• トラフィックゲートウェイ: OpenResty+Lua。
• ビジネス ゲートウェイ: SpringCloud Gateway + Sentinel。
• 永続化層フレームワーク: MyBatis、Mybatis-Plus。
• サービス構成、サービス登録、および検出: Nacos。
• メッセージミドルウェア: RocketMQ。
• ネットワーク通信: Netty。
• ファイルストレージ: Minio。
• ログ可視化管理: ELK。
• コンテナ管理: Swarm、Portainer。
• モニタリング: プロメテウス、グラファナ。
• フロントエンド: Vue。
• ユニットテスト: Junit。
• ベンチマーク: JMH。
• ストレステスト: JMeter。

4. 予備的なシステムアーキテクチャ設計

IM インスタント メッセージング システムの場合、インスタント メッセージング バックエンド サービス、大規模なバックエンド プラットフォーム、SDK アクセス サービス、OpenAI アクセス サービス、および大規模なフロントエンド UI がカバーされます。皆さんの多くは、IM インスタント メッセージング システムのアーキテクチャ図を多かれ少なかれ描くことができると思います。これは、図 1-1 に大まかに示されています。

写真

実際、このような建築デザインも非常に一般的です。このようなアーキテクチャ設計では、Kong/Openresty/Nginx は負荷分散とリバース プロキシのみを実行し、R&D 担当者はビジネス層と基本層の開発に重点を置きます。トラフィックが比較的少ない場合、この種のアーキテクチャ設計は通常、問題を引き起こしません。ただし、トラフィックが重くなり、ユーザーがバックエンド プラットフォームのインターフェイスを呼び出してメッセージを送信すると、インスタント メッセージング SDK がインスタント メッセージング サービスのインターフェイスを同期的に呼び出すときにパフォーマンスの問題が発生します。

各端末は同時に 1 つの IM インスタント メッセージング サービス インスタンスとしか接続を確立できないため、多数のユーザー端末が 1 つの IM インスタント メッセージング サービスと接続を確立すると、インスタント メッセージング SDK は同じ IM インスタント メッセージング サービスのインターフェイスを頻繁に同期的に呼び出すことになり、パフォーマンスのボトルネックが発生します。このとき、パフォーマンスのボトルネックが発生すると、IM インスタント メッセージング サービスに影響するだけでなく、バ​​ックエンド プラットフォームでのリクエスト受信業務にも一定の影響を及ぼします。

5. システムアーキテクチャ設計の最適化

図 1-1 に示すアーキテクチャ設計にはパフォーマンスのボトルネックがありますが、これを最適化するにはどうすればよいでしょうか。このため、図 1-1 に基づいて最適化を行い、最適化されたアーキテクチャを図 1-2 に示します。

写真

図 1-1 と図 1-2 を比較すると、技術的な実装の詳細を隠すという前提の下で、業務検証とトラフィック制御をフロントエンド化し、Kong/OpenResty/Nginx の役割を強化することで、これらのソフトウェアがリバース プロキシと負荷分散の機能を持つだけでなく、電流制限、ブラックリストとホワイトリスト、トラフィック制御、業務検証などの機能も実現できることがわかります。

つまり、このアーキテクチャ モードでは、分散 IM インスタント メッセージング システム全体のエントリ責任を十分に発揮し、Kong/OpenResty/Nginx の高同時実行性と高スループット機能を最大限に活用し、無効な要求のほとんどをシステム全体から排除しようとします。たとえば、ユーザーはシステムにログインせずに、メッセージの送信、友達の追加、グループの追加などのインターフェースを呼び出そうとします。これにより、バックエンド プラットフォームに対するビジネス上のプレッシャーが大幅に軽減されます。

Kong/OpenResty/Nginx に電流制限、ブラックリストとホワイトリスト、トラフィック制御、ビジネス検証などの機能を実装することに加えて、下流システムの安定性とセキュリティをさらに確保するために、電流制限、デグレード、回路遮断、フロー制御、検証、認証などの機能を実装するビジネス ゲートウェイ クラスターも導入しました。

多数のユーザー端末が同じ IM インスタント メッセージング サービス インスタンスに接続されることで発生するパフォーマンス問題を解決するために、IM インスタント メッセージング SDK は同じ IM インスタント メッセージング サービス インスタンスのインターフェイスを頻繁に呼び出します。 IM インスタント メッセージング サービス SDK と IM インスタント メッセージング サービスの間に RocketMQ クラスターを導入しました。

IM インスタント メッセージング サービス クラスター内の各 IM インスタント メッセージング サービス インスタンスにはクラスター内で一意の ID があり、各 IM インスタント メッセージング サービス インスタンスが起動されると、RocketMQ 内の独自の ID に関連するトピックのみをリッスンします。この方法では、各 IM インスタント メッセージング サービスは、独自の ID に関連するトピック内のメッセージのみを受信し、すべてのメッセージを受信するわけではありません。

ユーザーがシステムにログインすると、IM インスタント メッセージング サービスとの永続的な接続が確立され、ユーザー ID と端末がキーとして使用され、IM インスタント メッセージング サービスの ID が値として使用されて分散キャッシュに保存されます。同時に、ユーザー ID と端末がキーとして使用され、ユーザー端末と IM インスタント メッセージング サービス間で確立された長い接続が値として使用され、IM インスタント メッセージング サービスのローカル メモリに保存されます。

ユーザーがバックエンド プラットフォームのインターフェイスを呼び出してメッセージを送信すると、対象ユーザーの ID が含まれ、ユーザーがログインする端末デバイスが IM インスタント メッセージング SDK で指定されます。最後に、メッセージは IM インスタント メッセージング SDK を通じて RocketMQ に送信されます。

このとき、IM インスタント メッセージング SDK は、対象ユーザーの ID と端末に基づいて、分散キャッシュから対象ユーザーが接続している IM インスタント メッセージング サービスの ID を取得し、この ID に関連するトピックにメッセージを送信します。このとき、対象ユーザーとの永続的な接続を確立した IM インスタント メッセージング サービスは、RocketMQ でメッセージを受信し、ユーザー ID と端末に基づいてローカル キャッシュからユーザー端末との永続的な接続を取得し、この永続的な接続に基づいてユーザーにメッセージをプッシュします。

また、実際の実装では、多数のユーザーが IM インスタント メッセージング サービス クラスター内の 1 つのサービス インスタンスに同時に接続することを回避するために、ユーザーの接続 IP、ブラウザー フィンガープリント、モバイル デバイスなどに対してハッシュおよびモジュロ演算が実行され、クラスター内の各サービス インスタンスに可能な限り均等に分散されます。

そこで疑問になるのが、このアーキテクチャ設計をさらに最適化する余地があるかどうかです。

6. コンテナ化されたアーキテクチャ設計

分散 IM インスタント メッセージング システムのパフォーマンス、可用性、および柔軟なスケーラビリティをさらに強化するために、図 1-3 に示すように、分散 IM インスタント メッセージング システム用のコンテナー化されたアーキテクチャを設計できます。

写真

ご覧のとおり、分散 IM インスタント メッセージング システムのアーキテクチャ設計をさらに最適化し、コンテナ化されたアーキテクチャ設計を採用しました。オリジナルのアーキテクチャをベースに、以下の改善と最適化を行いました。

（１）基本サポートサービス

基本サポート サービスは、MySQL データベース、TiDB データベース、HBase、Redis キャッシュ、RocketMQ メッセージ キュー、Prometheus 監視、Portainer コンテナ管理、その他の基本ミドルウェア実装など、さまざまな基本ミドルウェア、データ ストレージ サービス、監視サービスによって実装されます。基本サポート サービスでは、分散 IM インスタント メッセージング システム全体に対して、最も基本的なデータ、転送、監視、およびコンテナ管理サービスが提供されます。

（２）コンテナ化

コンテナ化レベルでは、Docker、Swarm、Portainer を通じて実装され、その中でコンテナ化は Swarm と Portainer に基づいて管理されます。

（３）その他の基本機能の実現

分散 IM インスタント メッセージング システムを構築する場合、上記の階層化アーキテクチャに加えて、例外監視、サービス登録と検出、視覚化、サービス低下とバックアップ データ、サービス フロー制御、サービス障害復旧、容量計画と拡張と縮小、およびフルリンク ストレス テストも考慮する必要があります。

7. DDD階層化ビジネスアーキテクチャ設計

分散 IM インスタント メッセージング システムでは、大規模なバックエンド プラットフォームであっても、IM インスタント メッセージング サービスであっても、ビジネス層コードに階層化されたビジネス アーキテクチャを採用します。ここで、DDD の階層化アーキテクチャの考え方を参考にして、コードをプレゼンテーション層、アプリケーション層、ドメイン層、インフラストラクチャ層の 4 つの層に分割できます。ただし、分散 IM インスタント メッセージング システムの特殊性を考慮すると、コードの階層化は DDD の原則に厳密に従って設計されるわけではありません。具体的な設計は図1-4に示されています。

写真

分散 IM インスタント メッセージング システムは DDD の設計概念を借用しますが、DDD メソッドに完全に従って設計されるわけではないことがわかります。

（１）プレゼンテーション層

プレゼンテーション層は、ユーザー UI 層とも呼ばれ、DDD 設計の最上位層です。外部への API インターフェイスを提供し、クライアント要求を受信し、パラメータを解析し、結果データを返し、例外を処理します。

（２）アプリケーション層

アプリケーション層 (アプリケーション レイヤーとも呼ばれます) は、主に変更される可能性のあるビジネス シナリオを処理し、関連するイベント、スケジュール、およびその他の集計操作に関する関連処理を実行できます。

（３）ドメイン層

ドメイン層とも呼ばれるドメイン層は、DDD 設計の真髄と言えます。ビジネス システムの比較的変更されていない部分を抽象化し、ドメイン モデルにカプセル化します。

分散 IM インスタント メッセージング システムの設計では、ドメイン層は基本的に他の層やインフラストラクチャ層に依存しません。これはDDD設計とは異なります。

（4）インフラ層

インフラストラクチャ レイヤー (インフラストラクチャ レイヤーとも呼ばれます) は、他のレイヤーに共通の基本機能を提供します。分散 IM インスタント メッセージング システムには、キャッシュ、共通ツール クラス、メッセージ、システム永続化メカニズムなどが含まれます。

8. メッセージのやり取りリンクの送信

分散 IM インスタント メッセージング システムでは、他のいくつかの詳細は無視し、メッセージを送信するインタラクティブ リンク ロジックに重点を置きます。単独チャットでもグループチャットでも、最終的には IM インスタント メッセージング サービスを通じてメッセージをユーザーの端末にプッシュする必要があります。このときのメッセージ送信のプロセスを図 1-5 に示します。

写真

分散型 IM インスタント メッセージング システムでユーザーがメッセージを送信すると、それが単独のチャットであ​​ってもグループ チャットであ​​っても、最終メッセージはユーザーがログインしている端末デバイスにプッシュされることがわかります。ユーザー A がユーザー B にメッセージを送信する場合、またはユーザー A とユーザー B が同じグループに属している場合、ユーザー A はグループにメッセージを送信し、ユーザー B はメッセージを受信します。主なプロセスは次のとおりです。

（1）ユーザーAはバックエンドプラットフォームのインターフェースを呼び出してユーザーBにメッセージを送信します。メッセージにはユーザーBのIDと端末情報が含まれます。

（２）バックエンドプラットフォームはメッセージをキャッシュし、メッセージリポジトリに非同期的に書き込みます。

（３）バックエンドプラットフォームは、ユーザーBが接続しているIMインスタントメッセージングサービスのIDをRedisから取得します。

（4）バックエンドプラットフォームは、ユーザーBに接続されたIMインスタントメッセージングサービスのIDを取得した後、RocketMQ内のユーザーBに接続されたIMインスタントメッセージングサービスのIDに対応するトピックにメッセージを送信します。

（５）IMインスタントメッセージングサービスは、自身のサービスIDに対応するRocketMQ内のトピックのメッセージを監視します。このとき、ユーザー B に接続されている IM インスタント メッセージング サービスがメッセージを受信します。

（６）メッセージを受信した後、IMインスタントメッセージングサービスは、ユーザーBのIDと端末情報に基づいて、ユーザーBとIMインスタントメッセージングサービスとの間に確立された接続をキャッシュから取得し、この接続を通じてユーザーBにメッセージをプッシュします。

上記のメッセージ送信プロセスを実装するには、以下の条件を満たす必要があります。

（１）バックエンドプラットフォームは分散条件を満たしており、いつでも水平方向に拡張できる。

（２）IMインスタントメッセージングサービスは分散条件を満たし、いつでも水平拡張できる。

（３）開始された各IMインスタントメッセージングサービスインスタンスは、クラスター内で一意のIDを持ちます。

（4）各IMインスタントメッセージングサービスは、自身のIDに対応するRocketMQ内のトピックのメッセージのみをリッスンします。

（４）ユーザーが分散IMインスタントメッセージングシステムにログインすると、IMインスタントメッセージングサービスとの永続的な接続が確立され、ユーザーIDとユーザーが所在する端末に応じて永続的な接続がキャッシュされます。同時に、接続された IM インスタント メッセージング サービスの ID が、ユーザー ID とユーザーがいる端末に応じて Redis にキャッシュされます。

（6）ユーザーがメッセージを送信すると、対象ユーザーのIDと端末に基づいてRedisからIMインスタントメッセージングサービスのIDが取得され、現在のIMインスタントメッセージングサービスのIDに対応するRocketMQトピックにメッセージが送信されます。

（７）対応するIMインスタントメッセージングサービスは、RocketMQメッセージをリッスンして受信した後、対象ユーザーのIDと端末に基づいてキャッシュからユーザーの接続情報を取得し、対象ユーザーにメッセージをプッシュします。

9. シングルチャットインタラクションリンク

シングル チャットは、分散 IM インスタント メッセージング システムにおける 1 人のユーザーと別のユーザー間の 1 対 1 のチャットです。このシナリオでは、1 対 1 のチャットに参加している 2 人のユーザーのうち 1 人がオフラインになっている可能性が非常に高くなります。

たとえば、ユーザー A がユーザー B にメッセージを送信したときに、ユーザー B がオンラインではない場合があります。この時点で、ユーザー A からユーザー B に送信されたメッセージを保存する必要があります。実際、実装した分散 IM インスタント メッセージング システムでは、ユーザー B がオンラインかどうかに関係なく、メッセージ レコードが保存されます。ユーザー B がシステムにログインすると、図 1-6 に示すように、メッセージがユーザー B に同期されます。

写真

ユーザー A がユーザー B にメッセージを送信する場合、ユーザー B がオンラインであれば、メッセージを送信するためのインタラクティブ リンクに従ってメッセージをユーザー B に送信できることがわかります。ユーザー B がオンラインでない場合、メッセージは正常にユーザー B にプッシュされません。ユーザー B が分散 IM インスタント メッセージング システムにログインすると、バックエンド プラットフォームのインターフェイスが呼び出され、すべての未読メッセージが取得され、ユーザー B のオンライン プロセスを通じてメッセージがユーザー B にプッシュされます。

10. グループチャットインタラクションリンク

グループ チャットは、分散 IM インスタント メッセージング システム内の同じグループ内の複数のユーザー間で行われるチャットです。メッセージを送信する際、グループ ID を通じてグループ内のすべてのオンライン ユーザーを見つけ、オンライン ユーザーにメッセージを即座に送信できます。オンラインでないユーザーは、図 1-7 に示すように、単一のチャットではオフライン ユーザーとして処理されます。

写真

ご覧のとおり、グループチャットのインタラクティブリンクプロセスは次のとおりです。

（1）ユーザーはバックエンドプラットフォームのインターフェースを呼び出してグループにメッセージを送信します。

（２）バックエンドプラットフォームはメッセージをキャッシュし、メッセージライブラリに非同期的に書き込みます。

（３）メッセージは複数のユーザーからなるグループに送信されるため、接続している全ユーザーのIMサービスIDのリストがRedisから取得されます。

（4）サービスIDごとにユーザーをグループ化する。同じサービス ID を持つユーザーを同じ論理グループにグループ化して、後続のメッセージ プッシュを容易にします。また、オンラインでないユーザーのリストも記録されます。

（５）各サービスIDに対応するRocketMQ内のトピックにメッセージをループして送信する。

（6）オンラインでないユーザーの未読メッセージIDをブロードキャストします。

（７）IMインスタントメッセージングサービスは、自身のサービスIDに対応するトピックを監視し、自身のサービスにプッシュされたメッセージをいつでも受信します。

（８）IMインスタントメッセージングサービスがメッセージを受信したとき、ユーザーがオフラインまたはオンラインでない場合、ユーザーへのメッセージのプッシュは失敗し、ユーザーとIMインスタントメッセージングサービスとの間の接続が見つからない場合、メッセージはユーザーにプッシュされません。

（9）ユーザーが分散IMインスタントメッセージングシステムにログインすると、履歴（オフライン）メッセージがバックエンドプラットフォームから取得され、ユーザーのオンラインプロセスを通じてユーザーにプッシュされます。