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

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

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

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

技術的な課題

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

業界ソリューション

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

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

もっと読んで少なく書く

ユーザーごとに分ける

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

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

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

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

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

1. このバックエンドは、企業の社内運用部門が使用するために提供されており、リストの保守、アプリケーションのアップロード、リストの削除などの機能にも多くの「書き込み」が含まれています。
3. ビジネスの可用性を評価すると、アプリケーション ストア (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ライブラリです。いくつかの欠点があります:

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

そのため、特定の企業向けに、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 サービスは、ユーザーを検索します。 ユーザー データがこのコンピューター ルームにある場合、データは直接返されます。それ以外の場合、ユーザーの要求は適切なコンピューター ルームにリダイレクトされ、再開始されます。リクエスト。

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

概要:

この記事では、主に Meizu の複数コンピュータ室の災害復旧計画とその導入過程で遭遇した問題点と対策、Meizu の中核となるコンピュータ室の移行計画と問題の解決策を紹介します。

複数のコンピューター室の展開に関してどのような洞察と経験をお持ちですか?コメントでお気軽に共有してください。

http://www.bkjia.com/PHPjc/1071769.htmlwww.bkjia.comtru​​ehttp://www.bkjia.com/PHPjc/1071769.html技術記事 Meizu マルチ コンピュータ ルーム展開計画 なぜマルチ コンピュータ ルーム展開を行う必要があるのですか? 2014 年から 2015 年にかけて Meizu が変革し売上が爆発的に増加した後、インターネット サービス ビジネスがますます増え、ユーザーは...