数十億人のユーザーを抱える新浪微博プラットフォームのアーキテクチャ

はじめに

2014 年 3 月に新浪微博が発表した月間アクティブ ユーザー (MAU) は 1 億 4,300 万人に達し、2014 年の新年の最初の 1 分間に送信された Weibo の投稿数は 808,298 件に達しました。このような巨大なユーザー規模とビジネス量には、高いレベルが必要です。可用性 (HA) )、高い同時アクセス、低遅延の強力なバックエンド システム サポートを備えています。

Weibo プラットフォームの第一世代のアーキテクチャは LAMP アーキテクチャであり、データベースは MyIsam を使用し、バックエンドは PHP を使用し、キャッシュは Memcache を使用します。

アプリケーションの規模の拡大に伴い、派生した第 2 世代のアーキテクチャは、ビジネス機能のモジュール化、サービス指向化、コンポーネント化が行われ、バックエンド システムは PHP から Java に置き換えられ、徐々に SOA アーキテクチャが形成され、小規模企業をサポートしてきました。長年にわたってギャンブルプラットフォームのビジネス開発を行ってきました。

これに基づいて、長い期間の再構築、オンライン操作、思考、沈殿を経て、プラットフォームは第 3 世代のアーキテクチャ システムを形成しました。

まず、Weibo のコア ビジネス図 (下) を見てみましょう。これは非常に複雑ですか?しかし、これはすでに、これ以上単純化できないビジネス図となっており、第 3 世代のテクノロジー システムは、Weibo の中核ビジネスにおける新製品と機能の迅速かつ効率的かつ信頼性の高いリリースを保証します。

第三世代テクノロジーシステム

Weibo プラットフォームの第 3 世代テクノロジー システムは、直交分解法を使用してモデルを構築します。水平方向には、典型的な 3 レベルの階層モデルが採用されています。つまり、垂直方向には、インターフェイス層、サービス層、リソース層です。方向性に従って、ビジネス アーキテクチャ、技術アーキテクチャ、モニタリング プラットフォーム、サービス ガバナンス プラットフォームにさらに細分化されます。以下はプラットフォームの全体的なアーキテクチャ図です:

上の図に示すように、直交分解法は図全体を 3*4=12 の領域に分解し、各領域は水平方向の次元と垂直方向の次元の交点を表し、それに応じてこの領域のコア機能ポイントを定義します。領域 5 として。主にサービス層の技術アーキテクチャを完成させます。

水平方向と垂直方向の設計原則については、4、5、6 の技術コンポーネントとアーキテクチャ システム全体におけるそれらの役割に特に焦点を当てて、以下で詳しく紹介します。

水平レイヤー

水平方向の次元の分割は、大規模および中規模のインターネット バックエンド ビジネス システムの設計において非常に基本的なものであり、プラットフォームのテクノロジ システムの各世代に反映されています。以下は、その後の垂直方向の拡張への道を開くための簡単な紹介です:

[size=15.4545450210571px]1, インターフェイス層は主にWebページとモバイルクライアントとのインターフェイス対話を実装し、プラットフォームの3つのコアインターフェイスサービスはコンテンツ（フィード）サービスとユーザー関係です。サービスおよびコミュニケーション サービス (単一のプライベート メッセージ、グループ メッセージ、グループ チャット)。

[size=15.4545450210571px]

[size=15.4545450210571px]2, サービス層は主にコアビジネスをモジュール化してサービスを提供する2種類のサービスに分かれており、1つはアトミックサービスであり、その定義は他のサービスに依存しません。一般的に使用されるショート チェーン サービスや呼び出し側サービスなどのサービス モジュールがこのカテゴリに分類されます。図では、独立性を示すためにスイム レーンが使用されています。もう 1 つのタイプは、フィード サービスや通信サービスなどのさまざまなアトミック サービスとビジネス ロジックの組み合わせによって完成する複合サービスです。これらは、独自のビジネス ロジックに加えて、ショート チェーン、ユーザー、ディスパッチャー サービスにも依存します。

[size=15.4545450210571px]

[size=15.4545450210571px]3、 リソース層は主に、一般的なキャッシュ リソース Redis および Memcached に加え、永続的なデータベース ストレージ MySQL、HBase、または分散ファイル システム TFS などのデータ モデルのストレージです。新浪S3サービス。

水平階層化は、依存関係が上から下にあり、上位層のサービスは下位層に依存し、下位層のサービスは上位層に依存しないという単純かつ直接的な依存関係が形成されるという特徴があります。

階層化モデルに対応して、Weibo システムのサーバーには主に 3 種類があります: フロントエンド マシン (API インターフェイス サービスを提供)、キュー マシン (アップリンク ビジネス ロジックの処理、主にデータ書き込み)、およびストレージ (mc、mysql、mcq、 redis、HBase など)。

垂直方向に拡張された技術アーキテクチャ

ビジネス アーキテクチャの開発と最適化により、プラットフォームの研究開発はコア ビジネスをサポートするために多くの優れたミドルウェア製品を実装しました。これらのミドルウェアはビジネスによって推進され、技術コンポーネントがますます豊富になるにつれて、完全なプラットフォーム テクノロジ フレームワークが形成されます。 、プラットフォームの製品研究開発効率とビジネス運営の安定性が大幅に向上します。

水平方向の上位層と下位層の関係とは異なり、垂直方向では、両側のビジネス アーキテクチャ、監視プラットフォーム、サービス ガバナンス プラットフォームを推進し、影響を与える基盤サポート ポイントとして技術フレームワークが使用されます。次に、コアコンポーネントを紹介します。

インターフェイス層 Web V4 フレームワーク

インターフェイス フレームワークは、ビジネス インターフェイスの開発作業を簡素化および標準化し、共通のインターフェイス層機能をフレームワークにパッケージ化し、Spring のアスペクト指向 (AOP) 設計概念を採用します。インターフェイス フレームワークは Jersey に基づいて二次開発され、アノテーションに基づいてインターフェイス (URL、パラメータ) を定義し、認証、頻度制御、アクセス ログ、ダウングレード機能が組み込まれており、インターフェイス層の監視プラットフォームとサービス ガバナンスをサポートします。 Bean-json/xml シリアル化が自動化されています。

サービス層フレームワーク

サービス層には主に RPC リモート呼び出しフレームワークとメッセージ キュー フレームワークが含まれており、これらは Weibo プラットフォームのサービス層で最も広く使用されている 2 つのフレームワークです。

MCQ メッセージ キュー

メッセージ キューは、プラットフォーム内で先入れ先出し通信メカニズムを提供します。最も一般的なシナリオは、データ ランディング操作をキューに非同期で書き込み、キュー ハンドラーが読み取りとバッチ DB への書き込み、メッセージ キューによって提供される非同期メカニズムにより、フロントエンド マシンの応答時間が短縮されます。第 2 に、バッチ DB 操作により、間接的に DB 操作のパフォーマンスも向上します。別のアプリケーション シナリオでは、プラットフォームが検索を提供します。データ、およびメッセージ キューを介して商業運用部門に送信されます。

Weibo プラットフォーム内で広く使用されている MCQ (SimpleQueue Service Over Memcache) メッセージ キュー サービスは MemCache プロトコルに基づいており、メッセージ データは get/set の 2 つのコマンドのみであり、また、監視が非常に簡単 (統計キュー) 長年オンラインで実行されている豊富なクライアント ライブラリがあり、そのパフォーマンスは一般的な MQ よりも何倍も優れています。

Motan RPC フレームワーク

Weibo の Motan RPC サービス、基礎となる通信エンジンは Netty ネットワーク フレームワークを使用、シリアル化プロトコルはヘッセ行列と Java シリアル化をサポート、通信プロトコルは Motan、http、tcp、mc などをサポート、Motanフレームワーク システムの堅牢性とサービス ガバナンスの点で、比較的成熟した技術ソリューションがあり、Config 構成管理サービス (柔軟な FailOver および FailFast HA をサポート) に基づいて高可用性と負荷分散戦略を実装しています。サービス ガバナンスの観点から、完全なサービス コール チェーン データ、サービス リクエスト パフォーマンス データ、応答時間 (応答時間)、QPS、および標準化されたエラーと標準化されたエラーを生成します。例外ログ情報。

リソース層フレームワーク

MySQL と HBase をカプセル化する Key-List DAL ミドルウェア、カスタマイズされたカウント コンポーネント、分散 MC と Redis をサポートするプロキシなど、多くのリソース レイヤー フレームワークが業界で共有されています。プラットフォーム アーキテクチャのオブジェクト ライブラリと SSD キャッシュ コンポーネント。

オブジェクト ライブラリオブジェクト ライブラリは、Weibo のオブジェクト データの便利なシリアル化と逆シリアル化をサポートします。シリアル化中に、JVM メモリ内のオブジェクトがシリアル化されて HBase に書き込まれ、アクセスする必要があるときに一意の ObjectID が生成されます。オブジェクト ライブラリは、あらゆる種類のオブジェクトをサポートし、PB、JSON、およびバイナリ シリアル化プロトコルをサポートします。Weibo の最大のアプリケーション シナリオでは、オブジェクトについて、合計数十のオブジェクト タイプが定義され、標準オブジェクト メタデータ スキーマが抽象化され、オブジェクトのコンテンツがオブジェクト ストレージ システム (Sina S3) にアップロードされ、Sina S3 のダウンロード アドレスがオブジェクト メタデータに格納されます。

SSDCache

SSD ハードドライブの人気に伴い、優れた IO パフォーマンスにより、従来の SATA および SAS ディスクの代替として使用されることが増えています。 1) mysql データベース ハード ディスクの置き換え。コミュニティで SSD 用に最適化された MySQL バージョンであっても、SSD ハードディスクを直接アップグレードすると、IOPS が約 8 倍向上します。3) Redis ハードディスクを交換して、静的速度を向上させます。リソースの読み込み速度。

Weibo プラットフォームは、分散キャッシュ シナリオに SSD を適用し、従来の Redis/MC + Mysql 方式を Redis/MC + SSD キャッシュ + Mysql 方式に拡張し、SSD キャッシュを L2 キャッシュとして使用し、まず MC/Redis の問題を軽減します。高コストかつ小容量であるため、DB の浸透によるデータベース アクセスのプレッシャーも解決されます。

垂直監視とサービスガバナンス

サービスの規模とビジネスがますます複雑になるにつれて、ビジネス アーキテクトでもサービス間の依存関係を正確に記述することが難しくなり、サービスの管理と運用はますます困難になります。この点については、Google の dapper と twitter のサービスを参照してください。 zipkin というプラットフォームは、独自の大規模分散追跡システム WatchMan を実装しています。

WatchMan 大規模分散追跡システム

他の大規模および中規模のインターネット アプリケーションと同様に、Weibo プラットフォームは多数の分散コンポーネントで構成されており、ブラウザまたはモバイル クライアントを介したユーザーからの各 HTTP リクエストはアプリケーション サーバーに到達した後、多くのビジネス システムまたはシステム コンポーネントを通過します。足跡を残します。ただし、これらの散在したデータは、トラブルシューティングやプロセスの最適化においてあまり役に立ちません。このような典型的なプロセス間/スレッド間シナリオでは、そのようなログを収集して分析することが特に重要です。一方で、各フットプリントのパフォーマンス データを収集し、ポリシーに基づいて各サブシステムのフロー制御やダウングレードを実行することも、Weibo プラットフォームの高可用性を確保するための重要な要素です。各リクエストの完全な呼び出しリンクを追跡できること、呼び出しリンク上の各サービスのパフォーマンス データを収集できること、およびパフォーマンス データを計算してパフォーマンスを比較することによってフィードバックを提供できることが必要です。 Weibo の Watchman システムは、これらの目標に基づいて誕生しました。

システム設計の核となる原則は非侵襲性です。非ビジネス コンポーネントとして、他のビジネス システムへの侵入を可能な限り最小限に抑え、ユーザーへの透明性を維持する必要があります。これにより、開発者の負担とアクセス障壁を大幅に軽減できます。 。この考慮事項に基づいて、すべてのログ収集ポイントは、インターフェイス フレームワーク、RPC フレームワーク、その他のリソース ミドルウェアを含むテクニカル フレームワーク ミドルウェアに分散されます。

WatchMan は技術チームによって構築されたフレームワークであり、運用ベースはこのシステムに基づいており、ビジネスと運用および保守がこのシステムを併用してサービス拡張を含む分散型サービス ガバナンスを実現します。削減、サービスの低下、トラフィックの切り替え、サービスの公開、グレースケール。

終了

現在、プラットフォームにおける技術フレームワークはますます重要な役割を果たしており、プラットフォームの技術アップグレード、ビジネス開発、システム運用保守サービスを推進しています。スペースの都合上、この記事ではコアミドルウェアの設計については紹介しません。原則とシステムアーキテクチャは将来的に導入されます。

著者について

Wei Xiangjun (@伟向军_微博) は北京郵電大学を卒業し、現在は Weibo プラットフォーム アーキテクトとして、Microsoft、Kingsoft Cloud、Sina Weibo でテクノロジーの研究開発業務に従事してきました。システム アーキテクチャ設計、オーディオおよびビデオ通信システム、分散ファイル システム、データ マイニングなどの分野。

[size=15.4545450210571px]この記事は InfoQ 公式アカウントからの転載です: ucaicn 心からお勧めします

[url=]レポート[/url]