コード: Meituan のコードホスティングプラットフォームの進化と実践

Meituan コードホスティングプラットフォームは、長期にわたる改良を経て、分散アーキテクチャの変換と実装を完了し、数万のウェアハウスをホストし、Git 関連の毎日の平均リクエスト数は数千万に達しました。この記事では、Meituan コードホスティングプラットフォームが反復的な進化プロセスで直面する課題と解決策を主に紹介し、すべての人を支援または刺激することを望んでいます。

1 はじめに
2. Meituan コードホスティングプラットフォームの構築への道
- 2.1 コードホスティングプラットフォームの開発履歴
3. Meituan コードホスティングプラットフォームアーキテクチャの進化の実装と課題
- 3.1 スケーラビリティの目標
- 3.2 ユーザビリティの目標
4. まとめ
5. 今後の展望

1 はじめに

Code は Meituan が独自に開発したコードホスティングプラットフォームで、コードバージョン管理、ブランチ管理、コードレビューなどの機能を備えており、多くの R&D プロセスツールプラットフォームと連携して、すべての社内エンジニアの日常的な R&D 作業をサポートしています。3 年近くの構築を経て、Code は現在、数万のウェアハウスをホストし、毎日数千万の Git 関連のリクエストを処理しており、Meituan の R&D プロセス仕様の継続的な実装を安定してサポートしています。この記事では、Meituan がコードホスティングプラットフォームを構築する過程で直面したいくつかの課題と実際の経験を主に紹介します。

2. Meituan コードホスティングプラットフォームの構築への道

2.1 コードホスティングプラットフォームの開発履歴

Meituan コードホスティングプラットフォームの開発履歴を振り返ると、プロセス全体は、単一マシン展開、複数マシン展開、および自己開発の分散型コードホスティングプラットフォームの 3 つの段階に分けることができます。

第 1 段階: スタンドアロン展開

Meituan のオリジナルコードホスティングプラットフォームは、ほとんどの Web システムと同様に、1 台のマシンに展開して実行でき、すべてのユーザーリクエストは Web アプリケーションを介して応答されます。Git はファイル編成に基づくストレージモードを使用するため、それがページアクセスによるものであろうと、Git コマンド操作の実行によるものであろうと、最終的にはディスク上でファイルの読み取りと書き込みとして表示されます。高 IO ディスクは特に重要です。全体的なアーキテクチャを以下の図 1 に示します。

図 1 スタンドアロン展開

フェーズ 2: マルチマシン展開

アクセス規模が小さい場合は、第 1 段階のスタンドアロンアーキテクチャで日々の開発ニーズを満たすことができます。ただし、R&D チームのビジネスニーズが継続的に増大し、テスト自動化プロセスが徐々に改善されるにつれて、スケーラビリティのボトルネックはますます明白になり、主に次の 2 つの側面で明らかになります。

ストレージ: 会社のリソースの制限や地理的な分布の不均一性などの要因により、コードホスティングプラットフォームの展開マシンは利用可能な最大の SSD ディスクで構成されていますが、使用率は依然として 80% と高く、利用可能なスペースは深刻に不十分です。
負荷: R&D 担当者の増加に伴い、アクセスのピーク期間中、CPU および IO 負荷は 95% にも達し、ページは深刻なスタック状態になります. システムの継続的なサービスは、電流制限によってのみ保証されます.

そのため、スタンドアロン展開ではピーク時のトラフィックを処理できなくなり、システムの拡張が急務となっています。そのため、より深刻な IO 負荷の問題を解決するために、複数のマシンを介して同じウェアハウスの IO をロードできる一連の読み書き分離アーキテクチャソリューションの設計を開始しました。読み書き分離アーキテクチャにおいて最も重要なことは、ユーザーの観点からデータの一貫性を確保すること (ユーザーはいつでも最新の提出されたコードを読み取ることができること) であり、ここで次のような措置が講じられています。

書き込み操作は、プライマリノードでのみ発生します。
遅延同期モードは、データの読み取り時にスレーブノードがデータを同期するようにトリガーするために使用され、失敗した場合はマスターノードにルーティングされます。
単独のマスターモードを採用することで、緊急時にスレーブノードをすばやく無効にして、データのセキュリティを確保できます。

図 2 マルチマシン展開

図 2 に示すように、ウェアハウスアクセスフォームをアプリケーションレイヤープロトコルに従って HTTP と SSH に分割し、対応する解析エージェントモジュールが読み取り、書き込み、および配布操作を実行してから、それらをマスターノードとスレーブノードに送信します (ここでは、ラウンドボビンアルゴリズムによって読み取り要求が分散され、全体的な読み取りスループットが 2 倍になります。スレーブノードについては、データの整合性を確保するためにユーザーが読み取り要求を開始したときにウェアハウスデータを同期するフェッチ操作をトリガーするエージェントをデプロイしました。

第 3 段階: 自社開発の分散コードホスティングプラットフォーム

第 2 段階では、マルチマシンロード IO の読み取りと書き込みの分離アーキテクチャによって、拡張のボトルネックの問題が一時的に解決されましたが、ウェアハウスデータは指数関数的に増加し続けました。同時に、スケーラビリティの問題に加えて、主に次の 2 つの側面で可用性のボトルネックも強調されています。

運用と保守: 毎日の反復更新バージョンであれ、緊急バグのホットフィックスであれ、システムをシャットダウンしてシステムをデプロイする必要があり、シャットダウン期間中、ユーザーはコードホスティングプラットフォームを使用できません。
バックアップ: システムはコールドバックアップを使用して Git データを複数のコピーに保存します。これは、コアデータのリアルタイムの回復を保証できず、異常な状況下でデータが失われるリスクがあります。

したがって、高可用性と水平スケーラビリティを備えた分散アーキテクチャを構築することが急務です。業界の主流のコードホスティングプラットフォームの分散ソリューションを調査し、社内のビジネス特性と組み合わせて、最終的に、次の 2 つの特性を満たすアプリケーションレイヤーシャーディングに基づく分散アーキテクチャを選択しました。

高可用性: スリーコピーマルチアクティブモードを採用してコード損失のリスクを回避し、システムバージョンアップデートでサービスを停止する必要がなく、1 台のマシンの電源がオフまたはオフになった場合でも、サービスを正常に提供できます。下。
水平展開：シャーディングクラスタを拡張することでストレージや負荷の拡張を行い、広義の「無制限」の容量を実現します。

要約すると、Code は GitLab エコロジカルオープンソースコンポーネントの二次開発に基づいており、アプリケーションレイヤーシャーディングとマルチアクティブモードの分散アーキテクチャソリューションを採用しています。

基盤となるストレージサービスは、優れたエコロジーと豊富な機能サポートを備えた GitLab エコロジカルオープンソースコンポーネントの二次開発に基づいています。
各サービスは gRPC を介して対話的に通信します。主な考慮事項は、Git のほとんどがバイナリデータで通信することであり、gRPC は良好な伝送パフォーマンスとストリーミングサポートを備えた HTTP 2.0 に基づいています。
論理層とストレージ層は、ルーティングモジュールによって効果的に分離され、論理層は物理的な断片化を認識せず、ストレージ層は全体としてサービスを提供します。
マルチアクティブレプリケーションモードのデータ保証アーキテクチャを採用して、読み取りと書き込みのスループットを向上させ、数千万の要求の毎日の需要に対応します。
アプリケーション層のシャーディングの欠点を考慮して、次のように、対応するターゲットを絞った最適化もアーキテクチャ設計で行われました。

ホットスポットライブラリ: シャードの自動移行機能を提供します. ウェアハウスでホットスポットが見つかった場合、シャードの移行を実行してシャードのバランスを取ることができます.
クロスシャードデータの相互作用: ビジネスレイヤーの Git トランザクションパッケージ化を通じて、共有オブジェクトモードを使用し、相互に関連するすべてのウェアハウスが同じシャードにあることを確認します。これにより、クロスシャード通信の問題が回避されるだけでなく、ディスク容量の使用とアクセスの遅延。

図 3 コードシステムアーキテクチャ図

3. Meituan コードホスティングプラットフォームアーキテクチャの進化の実装と課題

アーキテクチャの進化の過程で、コードホスティングプラットフォームは最終的に次の 2 つの目標を達成しました。

高可用性: コンピューティングリソースとストレージリソースの水平拡張を実現できます。
高拡張: ダウンタイムを短縮し、可用性を向上させ、システムは安定して信頼できます。

次に、目標ごとに、技術的な課題、ソリューションの選択、設計、およびソリューションの観点から、実際の経験を詳細に紹介します。

3.1 スケーラビリティの目標

3.1.1 技術的な課題

横展開変革の中で、主に以下の2種類の課題に直面しました。

スケール: R&D プロセスの自動化のコンテキストでは、Meituan コードホスティングプラットフォームは、R&D 効率を向上させるために、数千万のスループット、低レイテンシ、および高可用性システムパフォーマンスを備えている必要があります。
互換性: 技術革新には多くのシナリオがあり、主に 2 つの考慮事項があります: (1) ユーザーの意識が低く、古いシステムと新しいシステムにより、既存の通信方法とプラットフォームの使用方法が変更されないこと (2)運用および保守システムの互換性や互換性など、移行期間中のさまざまな基盤となるストレージメディアの問題を考慮し、上流および下流システムの正常な動作を確保します。

3.1.2 スキームの選択

主流のコードホスティングプラットフォーム (GitHub、GitLab、Bitbucket など) を調査および分析した結果、主要なプラットフォームは主に次の 2 つのアーキテクチャを使用してスケーラビリティの問題を解決していることがわかりました。

図 4 アーキテクチャ設計スキームの比較

上記の比較から、共有ストレージに直接アクセスする場合、コードホスティングプラットフォームの安定性とパフォーマンスの要件を当面満たすことができないことがわかります (Git メカニズムが並列で最適化され、分散ストレージシステムを使用する場合)。読み取りと書き込みのパフォーマンスが高い場合は、良い解決策になる可能性があります) s 選択)。共有ストレージの最適化と変換のコストが高いという前提の下で、スケーラビリティの要件を満たすだけでなく、より成熟して安定し、優れたパフォーマンスを示す、アプリケーションレイヤーシャーディングの分散アーキテクチャを最終的に採用しました。

3.1.3 スキーム設計

プロキシモジュールによるリクエスト分散、ルーティングモジュールによるウェアハウスの断片化、アプリケーションモジュールのステートレス変換によるエラスティックスケーリングを実現し、水平拡張というアーキテクチャ上の目標を達成しました。これらのモジュールについては、以下で詳しく説明します。

プロキシモジュール

SSH プロキシ: Git-SSH リクエストプロキシを提供し、ルーティングモジュールを介してルーティング情報を取得し、ターゲットマシンで SSH 操作を実行します。SSH Proxy コンポーネントは go-crypto ライブラリに基づいて開発されており、ユーザーの公開鍵識別、フロー制御、長時間接続タイムアウト処理、SSH to gRPC などの機能を実装しています。その後の計画では、さまざまな使用シナリオに対処するために署名検証が導入されます。
HTTP Proxy : Git-HTTP/Web リクエストプロキシを提供し、ルーティングモジュールに格納されているウェアハウスフラグメントマッピング関係を通じてウェアハウスルーティングノードを決定します。Go-Gin をベースに開発された HTTP Proxy は、リクエストのスクリーニング、フロー制御、マルチレイヤープロキシなどの機能を実装します。当初、HTTP プロキシはグレースケールマイグレーションのコアコンポーネントとしても使用され、トラフィックのユニファイドポートを介して、古いコードシステムと新しいコードシステムへのリクエストの分散をサポートし、リクエストとデータのスムーズな移行を保証します。

図 5 プロキシモジュール

ルーティングモジュール

Shard : ウェアハウスとそのシャード間のマッピング関係を記録し、アプリケーション層のシャードアーキテクチャの「中央システム」です。Shard サービスは、マッピング関係を維持するだけでなく、ディザスタリカバリモジュールにとって不可欠な「意思決定者」でもあり、各ノードが現在アクセスしているウェアハウスの最新バージョンを取得して、読み取りおよび書き込みルートを決定します。Golang の優れた高い同時実行パフォーマンスにより、ルーティング関連のインターフェイスの平均応答時間は現在 15 ミリ秒以内です。このモジュールの主な機能は次のとおりです。

倉庫とシャード間のマッピング関係を確立します. 倉庫パスの更新によるフォルダーのコピー/移動などのアクションによって引き起こされる特定の複雑さを避けるために、ここでは倉庫 ID が一意の識別子として使用されます.
Go Routine を使用してノードのデータ同期ステータスを取得し、タイムアウトメカニズムを使用してユーザーが無期限に待機しないようにします。
Key-Value キャッシュを使用してウェアハウスとフラグメントのマッピングを保存し、マッピング関係のリクエストの遅延を減らします。

図 6 ルーティングモジュール

アプリケーションモジュール

アプリケーションモジュールには、主に次の 2 つの機能が含まれます。

コードコンテンツ情報やコードレビューなどの複雑なビジネスリクエストを処理するために、Git 関連のビジネスロジックインターフェイスを提供します。
コードとブランチの変更メッセージを監視し、イベント通知を送信してサードパーティのビジネスシステムを開き、測定情報を収集します。

全体的なモジュールアーキテクチャを以下の図 7 に示します。

図 7 アプリケーションモジュール

3.1.4 ソリューション

スケールソリューションのアイデア

スケールの主な目標は、数千万のリクエストをサポートし、コンピューティング、ストレージ、およびその他のリソースの水平方向の拡張をサポートするシステム機能を持つことです。その中で、ルーティングバランスは不可欠な部分です。

a. ルートバランシング

コードシステムは、データソースの信頼性に対する要件が高く、パフォーマンスに対する要件が比較的低いため、厳格なアービトレーションルーティングモードを採用しています。具体的なロジック構成は次のとおりです。

バージョン番号を使用して、どのノードが最新のコードコンテンツを提供しているかを判断します: バージョン番号が大きいほど、データが新しい. バージョンが最大の場合、それは最新のデータです. W+R > N の場合、常に最新のデータを読み取ることができます (N: ノードの総数、W: 書き込みの成功を判断するために必要な応答ノードの数、R: データの読み取り時に少なくとも読み取りに成功した数)、W が小さいほど書き込みの可能性が高く、R が小さいほど読み取りの可能性が高くなります。確率計算によると、99.999% の可用性レベルに達することができる N=3、R=W=2 の従来の推奨構成を選択しました。
読み取り修復モードを採用: データを読み取るときに、ノードデータに矛盾があることが判明した場合、この時点でデータ同期ロジックがトリガーされ、遅れているノードのデータが修復されます。

この機能は、ルーティングモジュールのシャードサービスに組み込まれています。アーキテクチャを以下の図 8 に示します。

図 8 ルーティングロジックダイアグラム

互換性ソリューション

互換性の目標は、「ビジネスでの使用を認識しない」という1 つの文に要約できます。そのため、主に以下の3つの観点から互換性を考慮しています。

a. システムの相互作用方法と既存のインフラストラクチャとの互換性

Code システムの多くのダウンストリームシステム (フロントエンド UI の複数のセット、ビジネス R&D プロセスツールプラットフォームなど) は、オープン API やフックメカニズムなど、システムによって提供される拡張機能に依存しています。業務面でのアップグレードでは、システムの対話方法が互換性があることを確認する必要があります;同時に、システム運用および保守監視システムの正常な動作を確保し、監視可能な状態を維持するために、主に次の4つのことを行いました。

コア機能との互換性：使用頻度の高い機能は新システムに翻訳し、使用頻度の低い機能と中程度の機能は業務や利用シーンとのコミュニケーションを図り、互換性を評価します。
一部の機能の再設計: より合理的な WebHook 構成機能と新しいコードレビュー機能を提供します。
エッジ機能運用の廃止: 廃止された歴史的なレガシー機能の廃止を促進し、合理的な代替手段を提供します。
運用・保守体制の開放：既存の監視埋没点と運用・保守インタフェースアクセス方式を維持し、システムを保守・監視可能な状態にする。

b. 非配布版から配布版へのシームレスな切り替え

Codeシステムには多くの倉庫があり、データの段階的な移行を確実にするために、低コストのユーザー自律的な切り替え方法が必要です.私たちは主に次の3つのことを行います:

視覚的な自動切り替え: ページ上のワンクリックの移行ボタンにより、非分散バージョンから分散バージョンへの低コストの切り替えを実現できます (移行の進行状況を認識でき、ウェアハウスは読み取り可能ですが、書き込みはできません)。実行中にデータの整合性を確保します)。
Proxy は、基盤となるストレージメディアの多様性を保護します。単一の呼び出し方法は Proxy を介して変更されず、格納されたデータの非分散バージョンと分散バージョンの両方を取得できます。
特殊なデータの共有ストレージ: ユーザーや SSH 公開キーなどのデータは、ウェアハウスデータと強制的な関係がないため、データ共有が可能です。

c. 履歴データのスムーズな移行

コードシステムには多くの履歴コードデータとビジネスデータがあり、履歴データを新しい分散システムに効率的かつ完全に移行する方法が特に重要になっています。ビジネス利用を意識させないという目標を達成するために、主に次の2つのことを行います。

「軽量」倉庫の移行を優先する: 最初に単一機能の倉庫を移行し、ユーザーのフィードバックに基づいて移行機能を徐々に改善します。
ビジネスディメンションのバッチ移行: 移行バッチはビジネスラインに従って分割され、同様の使用パターンを持つ倉庫は同時に移行され、フィードバックの問題の多様性を回避します。

3.2 ユーザビリティの目標

3.2.1 技術的な課題

ユーザビリティの変革を実行するとき、主にデータセキュリティの課題に直面します。会社の重要な資産の 1 つとして、コードは次の 2 つの要件を満たす必要があります。

コードの一点損失でデータを回復できます。
ユーザー視点で正しいコードデータを読み取ることができます。

3.2.2 スキームの選択

現在、業界には主に次の 3 つの主流のデータ複製モードがあります。

図 9 データ保護スキームの比較

業界のほとんどの分散型 Git システムは、データのセキュリティを確保するためにシングルマスターレプリケーションモデルを使用しています. Meituan の内部 R&D プロセスの段階的な改善により、コードコメントタグを作成する需要が徐々に増加し、読み取り/書き込み比率が初期の 10:1 から現在の 5:1 まで、より高い書き込みパフォーマンスが必要です。

高スループットと強力なデータ整合性の 2 つの目標を比較検討し、シングルマスターレプリケーションアーキテクチャに基づいて、ウェアハウスディメンションのシングルマスターレプリケーションをコアとし、マルチアクティブノードを機能とするレプリケーションモードを採用しました (これにより、データのセキュリティとシステムの可用性が確保されます。

3.2.3 スキーム設計

主に、ストレージモジュール内の 3 つの異なるタイプの Git 読み取り、書き込み、および初期化要求に対応するデータ処理メカニズムを採用し、マルチアクティブレプリケーションモードを組み合わせて、高可用性の目標を達成します。

ストレージモジュール

Git サーバー: 主に Git ウェアハウスデータを保存および管理し、Git 関連の gRPC インターフェースを提供します。このサービスは、GitLab エコロジカルオープンソースコンポーネントの二次開発に基づいており、主に、データ同期メカニズム、災害復旧モジュール、およびいくつかの基礎となるコマンドの適応性を最適化し、次の 4 つのロジックモジュールを含みます。

Replication Manager : データレプリケーションのコアモジュールであり、さまざまな要求 (読み取り、書き込み、または初期化) に従ってさまざまなレプリケーションロジックを実行し、データの整合性を確保します。
Code Core : Git Server のコアサービスモジュールで、主にアップストリームモジュールで使用する Git の gRPC API を提供します。
Git Core : スケーラビリティと高可用性を実現するための重要なコンポーネント. ここでは、GitLab エコロジカルオープンソースコンポーネントがソースコードを通じてプロジェクトに導入され、サードパーティの Git API としてプロジェクトで使用されます。
Git Command Factory : Git コマンドの中央コントローラーであり、Git プロセスの数の制御、パラメーターコンテキストの受け渡し、実行環境の分離、出力データのフォーマットなどの機能を提供します。

各論理モジュール間の関連付けを以下の図 10 に示します。

図 10 ストレージモジュール

Git クラスター: シャーディングとも呼ばれ、3 つの Git サーバーノードで構成されます。3 つのノードは、それぞれの Replication Manager モジュールを介してクラスター内の他のノードの IP およびその他の情報を取得し、gRPC プロトコルを使用してデータのレプリケーションとバックアップを行い、ユーザーの観点からデータの一貫性を確保します. 論理アーキテクチャを図 11 に示します.下：

図 11 Git クラスター

3.2.4 ソリューション

データセキュリティソリューション

コード制度が解決すべき課題の中でも、データのセキュリティは特に重要であり、研究開発プロセスの安全性と信頼性を確保するための鍵となります。データセキュリティソリューションを検討する前に、データの整合性を判断する基準を明確にする必要があります.Code では、2 つのウェアハウスのデータの整合性を判断するために、次の基準を使用します。

データ整合性の判断基準: 倉庫のある2つのノードに保存されているrefsデータが完全に一致している場合、2つのノードの倉庫データが一致していると言えます。

現在のシステムデータセキュリティメカニズムには、主に次の特徴があります。

a. マルチアクティブレプリケーション

現在、Code システムの各シャードには 3 つのノードが含まれているため、コードデータの 3 つのコピーが保証されており、1 つまたは 2 つのノードに障害が発生してデータが回復不能になった場合でも、他のノードを介してデータを回復できます。マルチアクティブレプリケーションモードを採用しました。つまり、必要な条件 (このノード上の現在のアクセスウェアハウスのデータが最新バージョンに再現される) を満たす任意のマシンノードが読み取りおよび書き込み操作を実行できるため、効率が向上します。スループットは、アクティブ/スタンバイ切り替えのコストを節約し、展開、ノードの交換、および異常回復を容易にします。マルチアクティブレプリケーションモードには、次の 2 つの制約があります。

「単一書き込み」メカニズム: 同時に、同じウェアハウスの書き込み操作は同じノードで実行する必要があります。
データセキュリティロックメカニズム: 特定のウェアハウスの基になる Git 操作で異常なエラーが発生した場合、データが復元される前にウェアハウスでの後続のすべての操作がこのノードで実行され、ローカルホットスポットが発生します。

アクティブ-アクティブレプリケーションは、主にデータストレージとデータ圧縮の 2 つの部分で構成されます。

01 データ保存

Git は主に、オブジェクトと参照の 2 種類のデータで構成されています。オブジェクトデータは不変データで、作成後は読み取り専用で、ファイルの形式でローカルディスクに保存されます。refs データは可変データで、更新できます。2 種類のデータは、異なるデータソースに格納されます。
ユーザーがウェアハウスにアクセスしたとき、オブジェクトがどのブランチの関連付けられたチェーンにも含まれていない場合、そのオブジェクトは到達不能と判断されます.到達不能なオブジェクトについては、その一貫性を維持する必要はありません. 到達不能オブジェクトの例は次のとおりです。

図 12 到達不能オブジェクトの例

02 データ圧縮

Code システムでは、システムのデータの一貫性を確保するために、データ再生用の ref の変更ログを記録する必要があります。各ウェアハウスの refs データ変換は比較的頻繁に行われるため、大量のログが生成され、ストレージが圧迫されます。そこで、不要なデータのオーバーヘッドを削減するために、ログ圧縮技術を採用しました. 圧縮方法は、以下の図13に示されています.

図 13 データ圧縮

たとえば、上図のメインブランチでは、初期状態がmain -> a、4 番目のログがmain -> e、5 番目のログがであるmain -> f場合、これら 3 つのログを 1 つのログに圧縮できます。つまり、main -> f初期状態に適用できます。、および圧縮前の再生トリガー結果は一貫しており、main は値 f で commit を指します。

03 関連の最適化

実際には、純粋な Git コマンドを使用してデータレプリケーション操作を実行しても、リソース割り当てを効果的に制御できないことがわかったため、通信方法、同時実行形式、およびレプリケーションの粒度を最適化し、全体的なデータレプリケーションの効率を向上させました。

b. コンピュータルーム間のバックアップ

コードシステムスライスの各グループの 3 つのノードは、少なくとも 2 つの異なるコンピュータールームから取得されます (現在、標準化された展開に従って、それらはすべて 3 つのコンピュータールームに変換されます)。提供された。このアーキテクチャに対象を絞ったディザスタリカバリ訓練を実施しました. 訓練を通じて、ノードのダウンタイムがシステムにほとんど影響を与えないことを確認しました. 柔軟なノード交換機能と組み合わせることで、新しいノードを 30 分以内に起動して、バランスの取れたディザスタリカバリ状態を実現できます.

図 14 コンピュータルーム間のバックアップ

c. データのホットバックアップ

コードはデータのホットバックアップメカニズムを提供します。データレプリケーションにより、書き込まれた新しいデータは基本的に「0」の遅延で他のレプリカノードに即座に同期され、ユーザーの観点から強力な一貫性が確保されます。データ同期メカニズムはホットバックアップの鍵であり、主に次の手順で実装します。

01 書き込み操作フェーズ

ウェアハウスの粒度で書き込みロックを導入することにより、同じウェアハウスが同時に 1 つのノードでしか書き込み操作を実行できないことが保証され、オブジェクトデータの同期が Git 内部フックメカニズムを通じてトリガーされ、 refs データは永続的に記録されます。
レプリカノードは、永続的な参照データを読み取り、操作をリプレイします。これにより、書き込みノードとの参照データの一貫性が維持されます。

図 15 書き込み操作手順

02 読み取り操作ステージ

現在のウェアハウスが書き込みロックを保持している場合は、データを読み取るために書き込みロックを保持しているノードに直接ルーティングされます。
書き込みロックが保持されていない場合は、各ノードのバージョンをデータソースに格納されているバージョンデータと比較し、データソースに格納されている最新バージョン以上のバージョンを持つすべてのノードを候補ルーティングノードとして使用し、ルーティングのロードバランシングアルゴリズム; 条件に一致するノードが存在しない場合は、同期補償が必要であり、補償が成功した後にルーティング選択が実行されます。

図 16 読み取り操作手順

03 関連の最適化

実装当初はステートレス同期を採用し、同期タスクが複数回実行されていたことが判明しましたが、その後、タスクの事前チェックによって不要なデータ同期タスクを回避し、最終的に同期タスクの 50% を削減しました。

d. データ検査

データ検査は、システムの円滑な運用とデータの安全性と信頼性を確保するために不可欠なリンクであり、システムに潜在する潜在的な危険を早期に検出できます。Code システムのコアサービスとして、検査サービスは、データリスクを軽減し、システムサービスの安定性を向上させる上で重要な役割を果たします。検査サービスについては、主に次の側面を考慮します。

透明性: 通常のユーザーリクエストにできるだけ影響を与えないようにし、不要な干渉を減らし、システムへのアクセスをスムーズかつ制御可能にします。
信頼性: データセキュリティの重要なサービスとして、柔軟なスケーリング、マルチポイントディザスタリカバリ、および高可用性も実現する必要があります。
保守性: データ検査で見つかった問題に対して、有効な手段で対処できます。同時に、検査サービスの効率を改善する必要があり、効果的な保護を実現するために、システムアーキテクチャとモジュールのアップグレードを繰り返し、それに応じて検査サービスを更新する必要があります。

上記のポイントに基づいて、ステートレスサービスアーキテクチャを採用し、定点検査、完全検査、定期検査などのモードを提供して、データのセキュリティを確保しています。検査データは、主に次の 2 つのカテゴリに分類されます。

refs データ: データ整合性評価基準によると、refs データは Git のコアデータであるため、その検査は必須です。
バージョンデータ: Code システムはバージョンに基づいて読み取りと書き込みのルーティングを実行するため、バージョンが大きすぎる場合、大量のデータ同期が発生する可能性があります. 同期要求の急激な増加によって引き起こされる特定の IO ジッタを回避するためにシステムにとって、バージョンギャップを監視することが特に必要です。

検査サービスの全体構造を以下の図 17 に示します。

図 17 検査モジュール

4. まとめ

この記事では、コードシステムの進化において Meituan が直面するスケーラビリティとユーザビリティの 2 つのボトルネックを体系的に紹介し、上記の 2 つのタイプのボトルネックと対応する課題をそれぞれ実装する際のソリューションと実際の経験について詳しく説明します。

上記のアーキテクチャ変革の実践に基づいて、現在の Meituan コードホスティングプラットフォームは、倉庫容量の水平拡張と独立した負荷分散の特性を実現し、R&D プロセス仕様の実装を安定してサポートしています。将来的には、研究開発の効率化と研究開発のセキュリティの確保の観点から探求と進化を続け、より価値のある実践的な経験を蓄積するよう努めます。これについては後でお知らせします。

5. 今後の展望

運用・保守の自動化: 現在のシステムの運用・保守の仕組みは自動化が進んでいないため、将来的には、データの修復、自動拡張、ホットスポットの移行などの機能を含め、システムの異常を自動的に検出して復旧できるようになることが期待されます。
コード分野でのベストプラクティスの提供: R&D ツールプラットフォームに依存し、Meituan の R&D プロセス仕様の反復更新を促進し続け、ベストプラクティスを蓄積し、強力なツールサポートを提供します。
コードセキュリティ: 情報セキュリティチームと緊密に連携して、コードスキャン、脆弱性の自動修復、危険な動作の警告など、より完全なセキュリティ管理戦略を提供します。

6. 著者とチームの簡単な紹介

Pan Tao、Fei Xiang、Dandan、Mao Qiang などは、基本的な R&D プラットフォームである R&D の品質と効率のチームのメンバーです。

Meituan R&D Quality and Efficiency Team は、同社の R&D 効率分野におけるプラットフォームとツールの構築を担当しています (R&D 需要管理ツール、CI/CD パイプライン、分散コードホスティングプラットフォーム、多言語構築ツール、パブリッシングプラットフォーム、テスト環境管理リンクを含む)。ストレステストプラットフォームなど）、優れた研究開発コンセプトとエンジニアリングプラクティスを継続的に促進し、一流のエンジニアリングインフラストラクチャを構築することに取り組んでいます。

- - - - - 終わり - - - - -

多分あなたは見たいです

| Meituan BERTの探索と実践

| Meituan 検索ランキングでのトランスフォーマーの実践

| 常識的なコンセプトマップの構築と美団シーンへの応用

続きを読む

フロントエンド |アルゴリズム |バックエンド | データ