Meizu マルチコンピュータルーム展開ソリューション_PHP チュートリアル-PHPチュートリアル-php.cn

Meizu マルチコンピュータールーム展開計画

なぜマルチコンピュータールーム展開を行う必要があるのか

2014 年から 2015 年にかけて Meizu が変革し、売上が爆発的に増加した後、インターネットサービスビジネスがますます増加し、ユーザーベースが拡大しました。サイズが大きくなると、従来の 1 つのコンピュータルームの拡張アーキテクチャでは Meizu の開発に対応できなくなります。また、国内の複雑なネットワーク環境では、1 つのコンピュータルームでは信頼性のニーズを満たすことができなくなります。近年、光ケーブルが掘り返されたり、コンピューター室の停電が頻繁に発生しています。例えば、アリペイの光ファイバーが掘削されて事業が停止したほか、昨年は微信も大規模な障害が発生し、光ファイバーも掘削された。単一のコンピューター室が故障するリスクに加えて、ユーザーは近くのアクセスに対する強い要求も持っています。

技術的な課題

コンピュータールーム間のネットワーク遅延と帯域幅の制限、オペレーターの専用回線のレンタルは非常に高価であり、信頼性が保証できない
コンピュータールーム間のトラフィックの正確なスケジューリング。変化が大きすぎてはいけません。
マルチコンピュータールームソリューションの最大の課題は、一貫性など、コンピュータールーム間のネットワーク遅延によって引き起こされる一連の問題です。もちろん、業界には、アリババの統合ソリューションなど、いくつかの成熟したソリューションもあります。ここでは、Tencent のセットソリューションと Weibo のクロスコンピュータルームソリューションは主に集中型で書かれており、迅速な切り替えソリューションを提供します。

業界ソリューション

Meizu マルチコンピュータールームソリューション

上記のソリューションから教訓を引き出し、ビジネスを整理し、次の 2 つのビジネスにマッピングします:

もっと読んで少なく書く

ユーザーごとに分ける

もっと読む書くことはまれです
このタイプのビジネスは主に読み取りで、書き込みはほとんどないため、このタイプのビジネスは読み取り専用ビジネスとして分類されます。

アプリケーションストアの単一マシンルームの構造は次のとおりです:

アクセスエンドは、API、開発者コミュニティ、および操作バックエンドの 3 つのビジネスに分かれています。

API は、モバイルアプリストアが使用するインターフェイスを提供します。主にリストデータを読み取り、ユーザーに表示します。この部分の「読み取り」については、基本的にキャッシュから読み取り、データベースへの依存度は非常に低くなります。 ; そして、「書き込み」は統計やコメントなどから得られます。

開発者コミュニティは、開発者とアプリメーカーにアプリケーションをアップロードして保守する機能を提供し、大量のデータを書き込み、基本的に読み取りと書き込みのバランスがとれています。

このバックエンドは、企業の社内運用部門が使用するために提供されており、リストの保守、アプリケーションのアップロード、リストの削除などの機能にも多くの「書き込み」が含まれています。
ビジネスの可用性を評価すると、アプリケーションストア (API インターフェイス) の可用性要件が最も高くなりますが、運用バックエンドと開発者コミュニティの可用性要件はわずかに低くなります。

上記の分析に基づいて、アプリケーションストア (API インターフェイス) にマルチマシンルームソリューションを提供するだけで済みます。アプリケーションストアのマルチコンピュータールームのアーキテクチャは次のとおりです。

コアコンピュータールームの展開は基本的に変更する必要はありません。中国東部のコンピュータールームのデータは、の同期機能を通じて複製されます。 MySQL。リストデータの読み取りはコアコンピュータールームと一致しており、Redis Pick から読み取られます。 Redis によってキャッシュされたデータは DB から取得され、スケジュールされたタスクを使用して定期的に Redis にフラッシュされます。

データの一貫性を確保するために、「書き込み」は依然としてシングルポイント書き込みであり、コンピュータールーム全体でコアコンピュータールームに直接書き込まれます。 2 つのタイプがあります。1 つは、メッセージキューを介してリモートコンピュータールームに書き込む方法です。コンピュータールームのネットワークに問題がある場合でも、「書き込み」は MQ に蓄積されるため、基本的にユーザーエクスペリエンスには影響しません。蓄積されたデータはネットワークがスムーズになった後に取り出されます。もう 1 つの種類の「書き込み」では、「書き込み」が成功したかどうかをすぐに知る必要があるため、この部分のネットワークに問題がある場合は、書き込みが失敗する可能性があるため、コンピュータルーム全体のデータベースに直接書き込まれます。ダウングレード処理を行います。

また、コンピューター室のトラフィックのスケジュールには GSLB を使用していますが、これについては後で詳しく説明します。

読み書きバランスのとれたビジネス

ここでの読み書きバランスのとれたビジネスの重要な特徴は、すべてのデータをユーザーの次元に従ってセグメント化できることです。それらの間にはほとんど相関関係がありません。たとえば、当社の同期サービスは、携帯電話を紛失したり、更新して消去する必要がある場合に、携帯電話上のすべてのデータ (連絡先、テキストメッセージ、設定、Wi-Fi、入力方法の設定など) をクラウドに同期します。、いつでもデータを取得できるので、データが失われないようにしてください。

以下は同期ビジネスのシングルマシンルームアーキテクチャです:

私たちのユーザーアクセスインターフェイスも2つの部分に分かれており、1つの部分は携帯電話用の実用的なAPIであり、もう1つの部分は直接操作（変更）用です。連絡先の）Web 側。 Web インターフェースで取得したリクエストは、連絡先同期、メッセージ同期、設定項目同期などのバックエンドサービスに転送されます。バックエンドサービスは、ユーザーのルーティング情報を別の DB シャードに保存します。

ここでクロスコンピュータールームソリューションを作成すると、ユーザーに応じてグローバルルーティングを直接実行し、異なるコンピュータールームにルーティングできるため、より便利です。

マシンルーム間のアーキテクチャ図は次のとおりです:

ビジネスデータとサービスを 1 つのユニットにパッケージ化しており、1 つのユニットが一定数のユーザーにサービスを提供します。各ユニットには完全なデータとサービスが含まれており、個別に展開できます。各コンピュータ室には複数のユニットがあり、各ユーザーのデータはローカルバックアップとリモートバックアップがあります。コンピューター室に障害が発生した場合、バックアップデータを取り出してユーザーに提供できます。

ユーザーがAPIを通じて当社のサービスにアクセスする場合、GSLBはスケジューリングに使用され、ユーザーはまずGSLBからユーザーデータの場所を取得します（ユーザーデータは同時に特定のコンピュータールームでのみ提供されます）。次に、クライアント要求をスケジュールします。適切なコンピューター室に移動します。

Web サービスは GSLB を使用できないため、ユーザーのリクエストを正確にスケジュールできないため、Web リクエストは困難です。この計画については、後の交通スケジュールで説明します。

コンピューター室のトラフィックの正確なスケジューリング

複数のコンピューター室になると、トラフィックのスケジューリングが必要になります。トラフィックをスケジュールする最も簡単な方法は、スマート DNS サービスを使用することです。以下に示すように:

LocalDNS からのリクエスト内の IP に基づいて、どの地域のどの ISP とユーザーを決定し、対応する地域の対応する ISP とコンピュータールームにスケジュールすることができるのは DNS のみです。スマートDNSのIPライブラリです。いくつかの欠点があります:

DNS ハイジャック私たちの国では、特に第 2 層および第 3 層都市の事業者によって、DNS ハイジャックが時々発生します。これは基本的にスマートDNSでは解決できません
ローカルDNSが8.8.8.8などユーザーが指定したDNSサーバーに設定されている場合、スマートDNSサーバーが取得するLocalDNSは米国のアドレスとなりISPに対応できません。スマート DNS サービスは、設計者の好みにのみ基づくことができ、分析が提供されると、ユーザーは間違った ISP や間違ったコンピュータールームを見つける可能性があります。
ユーザー情報に基づいてスケジュールを設定することはできません。一部のデータは、特定のコンピューター室でのみ利用可能です。DNS プロトコルはユーザー識別子を運ぶことができないため、正確な分析を行うことは困難です。
サーバーのダウンタイムを検出できません。

そのため、特定の企業向けに、GSLB サービスにアクセスしました。

このサービスは、リクエストを開始する前に、独自の GSLB サービス (または HttpDNS) にアクセスすることで、ユーザーを連れて行くことができます。データがどのコンピュータ室にあるかを特定し、IP を使用してビジネスサービスにアクセスするための識別。

はいくつかの明白な利点をもたらします:

* 可以根据IP或者UID等等信息精确调度。* 避免DNS劫持。* 用户手工设置DNS也不会调度错误。

ログイン後にコピー

現在、上記のアプリケーションセンター、ユーザー同期 API アクセスなど、すべてのクライアントアクセスは GSLB に接続されています。

しかし、この解決策はクライアント側の HTTP および HTTPS リクエストにのみ適しており、ブラウザーは GSLB が何であるかを認識しません。ユーザー同期 API アクセスは GSLB を使用して実行できますが、Web にアクセスする場合、ブラウザーが GSLB を認識しないため、GSLB をトラフィックスケジュールに使用できません。また、スマート DNS を使用している場合は、ユーザー ID に基づいてトラフィックを正確にスケジュールできません。

上記の考慮事項に基づいて、私たちは 3 番目のソリューションである GSLB + スマート DNS を提案しました。

ユーザーがサービスを要求する前に、DNS によって解決されたサーバーを見つけてデータを取得します。 GSLB サービスは、ユーザーを検索します。ユーザーデータがこのコンピュータールームにある場合、データは直接返されます。それ以外の場合、ユーザーの要求は適切なコンピュータールームにリダイレクトされ、再開始されます。リクエスト。

この解決策により、ユーザーのブラウザーのドメイン名が変更され、ユーザーエクスペリエンスに影響を与える可能性があります。また、ドメイン名のハイジャックは回避できません。