10億レベルの長時間接続、淘宝網アクセス層ゲートウェイのアーキテクチャ設計

目の前で言った

40 歳の建築家、ニエン氏の読者交換グループ(50 歳以上)では、多くの友人がアリババ、ネットイース、ヨウザン、Xiyin、Baidu、Didi などの一流インターネット企業の面接資格を取得しています。

最近、ニエンは友人の履歴書を案内し、「高同時実行ゲートウェイプロジェクト」を書きました。このプロジェクトのおかげで、この男はByte/Alibaba/Weibo/Autohome から面接の招待状を得ることができました。つまり、これは素晴らしいプロジェクトです。

より多くの面接機会を獲得し、大手企業からより多くの内定を得るために、

Nien は、このプロジェクトのアーキテクチャと実際の操作を紹介するビデオの章「第 33 章: 10Wqps の高同時実行 Netty ゲートウェイのアーキテクチャと実際の操作」を 9 月に公開することを決定し、今月末にリリースされる予定です。そして、マンツーマンで履歴書指導を行い、あなたの履歴書を輝かせ、完全に変えます。

「第 33 章: 10Wqps の高同時実行 Netty ゲートウェイのアーキテクチャと実際の運用」ポスターは次のとおりです。

「第 33 章: 10Wqps の高同時実行 Netty ゲートウェイのアーキテクチャと実際の運用」と併せて、Nien はアーキテクチャおよび設計資料として、いくつかの産業グレードおよびプロダクショングレードのゲートウェイケースを整理します。

前に整理しました

上記の 4 つのケースに加えて、学習ケースを整理する過程で、ニエン氏はもう 1 つの美しい実稼働レベルのケースを発見しました。「10 億レベルの接続、タオバオアクセスレイヤーゲートウェイのアーキテクチャ設計」、

注意してください、これはもう 1 つの非常に素晴らしい、一流の産業グレードおよび生産グレードのゲートウェイケースです。

これらのケースは Nien 独自のものではありません。

これらの事例は、誰もが学び、コミュニケーションできるビデオレッスン「第 33 章: 10Wqps の高同時実行性 Netty ゲートウェイアーキテクチャと実際の操作」の準備中に、インターネットで情報を検索し、Nien が収集したものです。

『Nien Architecture Notes』、『Nien High Concurrency Trilogy』、『Nien Java Interview Guide』の PDF は、公式アカウント [Technical Freedom Circle] から入手してください。

記事ディレクトリ

数十億レベルの接続、淘宝網アクセス層ゲートウェイのアーキテクチャ設計

原作者：ハンドタオチーム

建築への道は山あり谷ありです。

建築への道は反復的かつ進化的です。

モバイルタオバオを例に挙げると、初期の HTTP API ゲートウェイから、ダブルイレブンイベント中の主要なトラフィックを想定した自社開発の高性能、全二重、安全な Alibaba Cloud チャネルサービス ACCS まで、インフラストラクチャの進化を通じて進化してきました。、ネットワークの最適化、私たちはプロトコルの改善、リモートマルチアクティビティ、ネットワークスケジューリングなどで豊富な経験を蓄積してきました。この記事では、この機会にテクノロジーの進化プロセス全体を要約します。

1. 技術的背景

ダブルイレブン期間中にモバイル電子商取引事業が開始された当初を振り返ると、ダブルイレブン当日のモバイル取引量は243億件に達し、総取引量571億件の42.6％を占めた。

ビジネスを急速に発展させるには、ユーザーにリーチするためのより積極的なプッシュが必要です。

一部の新しい形式のインタラクションやゲームプレイでは、購入者と購入者、購入者と販売者、購入者と専門家を結び付ける必要があります。

他のよく知られたシステムと同様に、初期プッシュはポーリングモードで行われました。

効果的なチャネル機能が不足しているため、初期の企業はサーバーを継続的にポーリングする方法を採用していました。

ポーリング方式はサーバーに不必要な負荷をかけるだけでなく、ユーザーの携帯電話に多大な電力とトラフィックの浪費を引き起こします。

ダブルイレブンなどの大規模なプロモーション中は、不要なリクエストが多すぎるとバックエンドクラスターのスロットリングが発生し、ユーザーエクスペリエンスに影響を与える可能性があります。

2. モバイルネットワーク環境における課題は常に存在します

3G、4G、5G モバイルネットワークの普及により、ネットワーク速度は大幅に向上しました。

しかし、ネットワーク環境の多様性や差異によりモバイルネットワーク環境は複雑化しており、ダブルイレブンなどの繁忙期にはモバイルネットワークハイジャックなどの問題が多発しています。

このような問題の解決効率は非常に低く、ユーザーを追跡し、シーンを再作成し、さらにはネットワークエンジニアやオペレーターに連絡してトラブルシューティングを行う必要があり、長い時間がかかります。

パブリックオピニオンフィードバックでは、ユーザーから「特定のページの読み込みが遅い、ページが開けない、リクエスト速度が遅い、特定の機能が開くのが遅い」などの問題がよく報告されます。

以前は、これらの問題に対処する方法はあまりなく、1 つずつ調査することしかできず、非常に消極的でした。ネットワークの問題の多くは散発的であり、一度見逃すと追跡するのが困難です。

このような問題の背後には多くの理由があります。

1) オペレーターの問題。
2) コンピュータ室導入の理由。
3) クライアント SDK のバグ。
4) 弱いネットワークとネットワークジッター。
5) DNS ハイジャックとデータ改ざん。

PC 時代では、Web サイトにアクセスするネットワーク状態は比較的安定しているため、開発プロセスにおいてネットワークがユーザーエクスペリエンスに与える影響はほとんど考慮されません。

しかし、モバイル APP の場合は状況が異なり、特に我が国では、基本的なモバイルネットワーク環境がまだ完全ではなく、多くのユーザーが地下鉄やバスなどのモバイル環境でアクセスしており、モバイル基地局の頻繁な切り替えにより、ネットワークの不安定性がさらに悪化しています。

モバイルタオバオのデータから判断すると、毎日のアクティブユーザーの大部分はネットワーク環境の悪い地域から来ています。エンドツークラウド接続が不安定で遅延が大きい場合、ユーザーエクスペリエンスは問題外になります。

基本的なネットワーク効率は電車に似ており、遅延は電車の速度 (出発時間)、帯域幅は電車の車両容量、伝送物理リンク全体は電車のレールに似ています。

現在の複雑なモバイルネットワーク環境において、私たちの目標は、すべてのユーザーがモバイルタオバオでスムーズな体験を楽しめるようにすることです。

下の図は、誰もが私の国のモバイルネットワーク環境をより直観的に理解するのに役立ちます。

ユーザーから IDC までのエンドツーエンドのルーティングを指します。データ送信に時間がかかり、パケット損失率が高く、セキュリティが不十分です。我が国では、DNS ハイジャックやコンテンツハイジャックなどの問題がよく発生します。

したがって、ネットワークチャネルの最適化という点では、通信事業者の基本ネットワークの制限を突破し、ユーザーに完璧なショッピングエクスペリエンスを提供する方法を模索するために、やるべきことがたくさんあります。

3. 全体的な技術アーキテクチャ

モバイル電子商取引ビジネスの急速な発展のニーズに応えるため、当社は世界クラスのネットワークアクセスサービスを構築し、無線ネットワークの下に「水、電気、石炭」インフラを構築することを決定しました。

このようなインフラストラクチャは、次の 4 つの目標を達成する必要があります。

1) 全二重。
2) 低遅延。
3) 高いセキュリティ。
4) 開きます。

これら 4 つの目標に加えて、このアクセスサービスを取り巻く運用保守システムは、エンドユーザーが優れた端末エクスペリエンスを得るのを支援し、開発者が独自のビジネスを迅速に構築できるように設計されています。

上の図に示すように、アクセスサービス全体を 2 つの層に分割します。

1)アクセスゲートウェイ: 接続の維持、メッセージの解析、配布を担当します。
2)アプリケーションゲートウェイ: API、SYNC、RPC、PUSH などのさまざまなアプリケーション層プロトコルを実装します。アプリケーションゲートウェイの背後には、特定のビジネスシステムがあります。

同時に、従来の DNS の代わりに統合スケジューリングサービスを使用しており、コントロールセンターとしてスケジューリングサービスが効果的にクライアントに指示を出し、DNS 汚染の影響を回避できます。

サーバーの階層化されたアーキテクチャに対応するのがクライアントの SDK であり、最下位の統合ネットワークライブラリ SDK はネットワーク最適化戦略を統合し、ゲートウェイテクノロジーを適用する各 SDK に API を提供します。

このオープンアーキテクチャに基づいて、ビジネスパーティは、ネットワークの背後にある詳細を知らなくても、特定のバックエンドサービスを直接開いたり、さまざまなアプリケーションゲートウェイに接続したり、アプリケーションゲートウェイによって提供される開発ツール (API など) を通じてクライアントコードを迅速に生成したりできます。ゲートウェイ）。

ビジネス関係者は、このアクセス層に基づいて独自のプロトコルを設計することもできます。

ユニファイドアクセス層は、ユーザーのデバイスとオンラインステータスを一元管理し、双方向の情報送信機能を提供します。

以下に示すように:

このゲートウェイは、中間ネットワークの通信問題を解決し、上位層サービスに高品質の双方向通信機能を提供することに特化します。

4. 安定性と災害復旧

安定性と災害復旧はサーバー側ミドルウェアが常に注意を払う問題であり、ユニファイドアクセスレイヤーはゲートウェイの利点とリスクを統合します。

ひとたび入り口に障害が発生すると影響を受けるユーザーの範囲は想像を絶するものとなり、より高い安定性をいかに実現するかは大きな課題となります。

4.1 ゲートウェイアーキテクチャの最適化

ユニファイドゲートウェイの場合、サービスゲートウェイが異なれば、情報送信特性も異なります。

ほとんどのビジネスは 1 日を通じて比較的安定していますが、一部のマーケティングビジネスでは短期間に大量の情報をリリースする場合があり、この種の情報リリースはゲートウェイ上の多くのリソースを消費し、通常のユーザーアクセスに影響を与えます。

たとえば、プッシュサービスはゲートウェイ経由で 2 億のメッセージをプッシュする必要があり、これらすべてのメッセージは短時間内に送信される必要があります。同時に、ゲートウェイは通常のユーザーインタラクション用のサービスを提供し続けています。大量の情報プッシュが通常のユーザーインタラクションとリソースをめぐって競合し、最終的に通常のユーザーインタラクションが失敗する可能性があります。これはビジネスにとって容認できません。

上記の状況に基づいて、ゲートウェイ全体は展開の観点から 2 つのクラスターに分割されます。

1) クラスターは通常のオンラインユーザーアクセスを処理します。
2) クラスターは大量の情報のプッシュを処理します。

以下の図に示すように、この導入方法では、ユニファイドゲートウェイに対する異なるビジネスフォームの影響を回避し、異なるビジネスフォームの分離を実現します。

4.2 さまざまな場所にもっと住む

リモートアクティブマルチアクティブソリューション全体では、ユニファイドゲートウェイがトラフィックを迅速にガイドする責任を負います。これは、ソリューションの実装を確実に成功させるための重要なリンクです。

遠隔地でのマルチアクティビティは、複数のコンピュータ室の総合的なソリューションです。

リモートマルチアクティブアーキテクチャは主に、複数の地域に同時に複数の同等のコンピュータルームが存在し、ユーザーの規模で分割され、複数のコンピュータルームがすべてのユーザーのトラフィックを共同で負担することを意味します。

1 つのコンピュータルームに障害が発生した場合、障害のあるコンピュータルームからのトラフィックは利用可能なコンピュータルームにすぐにリダイレクトされるため、障害の回復時間が短縮されます。

4.2.1 無線アクセス層のユニット化のためのネゴシエーションメカニズム:

まず、このリモートのマルチアクティビティ環境で Web 側がどのように実装されているかを見てみましょう。

上の図からわかるように、ブラウザーのビジネスリクエストは CDN に送信され、CDN に保存されている分散ルールに従ってトラフィックが後続のサイトに分散されます。

ワイヤレス端末もこれを行いますか?

1) クライアントは強力な機能を備えており、より柔軟に処理できます。
2) CDN ディストリビューションノードによりハードウェアコストが増加します。
3) 双方向通信機能を必要とするクライアントの場合、情報転送はより複雑になります。

こういったことがWebとは違うことを考えているのですが、何か別の選択ができないでしょうか？

上の図に示すように、クライアントの強力な機能に依存し、ネゴシエーションメカニズムを使用してユーザーリクエストをさまざまなユニットに正しく割り当てます。

以下の点が含まれます。

1) クライアントのリクエストには、現在のユーザーが所属するユニットに関する情報が含まれている必要があります。
2) リクエストがサーバーに到着すると、サーバーはユーザーが所属するユニットが正しいかどうかを判断し、そうでない場合はユーザーを正しいユニットにリダイレクトします。
3) 現在のリクエストは、ビジネスの正確性を保証するために、サーバー上のゲートウェイを介してユニット間呼び出しが行われます。
4) クライアントが所属するユニットが更新されると、以降のリクエストは正しいユニットに送信されます。

4.2.2 無線アクセス層のユニット化されたバイパススケジューリング:

交渉メカニズムは非常にうまくいっているように見えますが、ここで爆弾が投げ込まれます。コンピューター室の入口ネットワークが切断されています。

上図のように、外部ネットワークが利用できない場合、ネゴシエーションの機会がなくなり、障害が発生したユニットのユーザーは復旧できなくなります。このとき、バイパススケジューリングサービスが登場します。

上の図に示すように、私たちが設計した配車センターは、統合されたバイパス配車の責任を引き受けるようになりました。

アプリがアクセスしたユニットにアクセスできない場合、アプリは別のユニットの配車センターを訪問し、ユーザーのホームユニットに問い合わせます。

このようにして、利用可能なユニットノードが取得され、ユーザーは正しいユニットに切り替えられます。

このソリューションは、単一のコンピュータ室のアクセス層ゲートウェイが使用できない状況にも適用できます。

4.2.3 アプリケーション層ゲートウェイが利用できない:

特定のユニットのコンピューター室のアプリケーション層ゲートウェイが利用できません。現時点では、アプリケーションゲートウェイが問題をトラブルシューティングするまでに長い時間がかかります。最速の障害回復を達成するために、アクセスの転送ルールを変更します。スイッチを介してレイヤーを通過し、利用可能なトラフィックへのトラフィックをカットします。

以下に示すように:

5. エンドツーエンドのネットワーク最適化

5.1 統合ネットワークライブラリ

ネットワーク最適化の初期の頃、私たちの目標は、ポリシー、httpDNS、SPDY プロトコルなど、すべてのシステムのネットワーク最適化に必要なすべての側面を含むユニバーサルネットワークライブラリを作成することでした。

上位層の API ゲートウェイのリクエストロジック、プッシュロジック、アップロードおよびダウンロードロジックはすべて、このような一般的なネットワークライブラリのビジネスです。

ネットワークを長期的に継続的に最適化するには、一般的なネットワークライブラリを上位層のアプリケーションロジックから層レベルで分離し、完全に切り離すことが非常に必要です。

アーキテクチャを次の図に示します。

このアーキテクチャの分離により、ワイヤレスネットワークの最適化において、より集中的かつ体系的に取り組むことが可能になります。

統合ネットワークアクセスライブラリのいくつかの重要な機能:

1) クライアントのネットワーク動作戦略 (接続の確立、タイムアウト処理、要求プロトコル、暗号化するかどうか) を柔軟に制御します。
2) HTTPDNS が含まれます。
3) 異なる場所での複数の生活をサポートします。
4) よりきめ細かい制御とスケジューリング (ドメイン名レベルとドメイン名下のパラメータレベル)。

1、2、3、および 4 はすべて、ネットワークディスパッチセンターのクラスターによって制御されます。これがビジネスから独立できることを願っています。アリババのビジネス属性の一部を削除すると、誰もがこのモジュールを HTTPDNS として理解できるようになり、次のことが可能になります。ネットワークの最適化に関しては、エンドツーエンドの多くの作業が行われています。

5.2 できるだけ早くアクセスする

ネットワークライブラリに基づいて、一連のインテリジェントな学習ネットワーク戦略を実装しました。

この戦略は、さまざまなネットワーク環境におけるクライアントの接続戦略に基づいてインテリジェントに学習できます。ユーザーがこのネットワーク環境に戻ると、迅速な接続のための最適な戦略が提供され、ローカルにキャッシュされた過去の最適な戦略が定期的に更新または削除されます。ネットワーク戦略。

各ネットワークへのより高速な浸透を実現し、より優れたアクセスパフォーマンスを提供するために、アクセスサーバーはさまざまなプロトコルとポートをサポートし、クライアントは接続を確立するときにネットワークへの高速アクセスを実現できます。

当社が重点を置く重要な指標は、クライアントを開いてから 30 秒以内のネットワークリクエストの成功率であり、これにより接続速度が向上し、ユーザーエクスペリエンスが向上します。

ディスパッチセンターをベースに、インテリジェントなビッグデータ分析プラットフォームを構築しました。

インテリジェントなビッグデータ分析プラットフォームは、ネットワークリクエストプロセス中にクライアントから次のような重要なデータを収集します。

接続時間、
最初のパケット受信時刻、
荷物の受け取り時間全体、
SSLハンドシェイク時間など

このデータを分析することで、異常なネットワーク領域を特定し、短距離高速アクセスのルールを調整したり、IDC構築やCDNレイアウトの最適化を推進したりすることができます。

5.3 弱いネットワークの最適化とジッター対策

弱いネットワーク最適化の観点から、QUIC プロトコルを試したところ、ネットワーク遅延が大きく、パケット損失が深刻な場合には、そのパフォーマンスが TCP よりも優れていることがわかりました。

オンラインモバイルタオバオのグレースケールバージョンで実際にテストしたところ、QUIC に切り替えた後、平均 RT 収益が 20% 近く増加しました。

ただし、モバイルネットワークでは QUIC の普及に問題がある可能性があることを考慮し、将来的には SPDY を主な方式として使用し、QUIC を補助として使用してネットワーク接続戦略を改善する予定です。

「SPDY」（「スピーディ」と同じ発音）は、ネットワーク遅延を最小限に抑え、ネットワーク速度を向上させ、ユーザーのネットワークエクスペリエンスを最適化するために Google が開発している新しいネットワークプロトコルです。

SPDY は HTTP を置き換えるために使用されるプロトコルではなく、HTTP プロトコルの拡張機能です。新しいプロトコルの機能には、ストリーム多重化、リクエストの優先順位付け、HTTP ヘッダー圧縮が含まれます。Google は、プロトタイプ Web サーバーと、SPDY プロトコルをサポートするバージョンの Chrome ブラウザを開発しました。

Googleは、SPDYプロトコルの導入後、実験室テストでページの読み込み速度が以前より64％速くなったと発表した。このデータは、世界の上位 25 の Web サイトのダウンロードテストに基づいています。現在、SPDYチームは使用可能なプロトタイプ製品を開発しており、Googleはこのプロジェクトをオープンすることを決定し、「オンラインコミュニティが積極的に参加し、フィードバックを提供し、支援してくれることを期待している」としている。

ネットワーク環境が劣悪な場合には、長いリンクと短いリンクを組み合わせる戦略を採用しました。

長いリンクでリクエストのタイムアウトや透過性の低下が発生した場合、短いリンク HTTP を使用してデータをリクエストします (モバイルネットワーク環境では、HTTP プロトコル、特に HTTP1.0 の方が透過性が優れています)。ユーザーエクスペリエンスは最大限に保証されます。

データは以下のとおりです。

ネットワークスイッチングやネットワークジッターの場合の技術的な最適化も非常に重要な側面です。モバイルデバイスのネットワークスイッチングや信号の不安定性が発生する状況によく遭遇します。このような状況でユーザーエクスペリエンスを確保するにはどうすればよいでしょうか?

このような状況に対し、私たちは戦略的かつ合理的な方法でリトライを増やすことを考えています。

ネットワークリクエストをソケットバッファに送信するかどうかで分割し、ネットワークリクエストのライフサイクルを「リクエストの開始からソケットバッファに送信されるまで」と「リクエストが送信されてから」の2段階に分けます。リクエストの最後までソケットバッファに送信されます。」

リクエストがフェーズ 1 で失敗した場合、ビジネスリクエストはビジネスニーズに基づいて再試行されます。フェーズ 2 の要求失敗では、読み取り操作の再試行機能のみが提供されます。

シナリオを想像してみてください。

ユーザーがエレベーターに入るときにデータの更新要求を開始すると、ネットワークのジッターにより、エレベーター内のネットワーク接続が切断されます。

この場合、合理的な戦略を採用して再試行できます。

このようにして、ユーザーがエレベータを降りたときに、ネットワーク要求が正常に再試行される可能性が高く、ユーザーが必要なデータを取得できるようになり、ユーザーエクスペリエンスとクライアントのネットワークジッター防止機能が向上します。

5.4 暗号化通信の1秒ルール

ご存知のとおり、従来の HTTPS ハンドシェイクプロセスは面倒で、ネットワークの品質が低いと、接続速度の低下、ユーザーエクスペリエンスの低下、さらには安全なハンドシェイクを完了できなくなる可能性があります。

ただし、セキュリティの観点からは、ユーザーの個人データを保護するための安全な伝送チャネルが必要です。

セキュリティとネットワークエクスペリエンスの矛盾に直面して、私たちはテクノロジーの進歩を遂げる必要があります。

そのため、私たちは TLS1.3 プロトコルを参照して一連の軽い ssl テクノロジーを開発し、最終的に、リクエストのマージ、暗号化アルゴリズムの最適化、セッションチケットやその他の戦略の使用を通じて、セキュリティとエクスペリエンスのバランスを見つけました。

ユーザーエクスペリエンスを犠牲にすることなく、安全な送信という目標が達成され、サーバーのパフォーマンスも大幅に向上します。

技術革新により、無線ネットワーク暗号化通信における1秒ルールを実現しました。

最後に: 質問がある場合は、古いアーキテクチャにアドバイスを求めることができます。

建築への道は山あり谷ありです。アーキテクチャは高度な開発とは異なります。

アーキテクチャの問題はオープン/オープンです。
建築に関する質問に対する標準的な答えはありません。

このため、多くのパートナーは変革に向けて多大なエネルギーと資金を費やしていますが、残念ながら、一生のうちにアーキテクチャのアップグレードを完了することはありません。

したがって、アーキテクチャのアップグレード/変革のプロセスにおいて、どうしても効果的な解決策が見つからない場合は、40 歳の建築家 Nien に助けを求めることができます。

少し前に、17 年の経験を持つ友人が、専攻を超えて Java で働いていましたが、アーキテクチャを切り替えるという問題にも直面していました。数か月間オファーがなく、非常に不安でした。

しかし、Nien からの数回の指導の後、Java Architect + Big Data Architect の内定を得ることができました。

そのため、もしキャリア上で困難に遭遇し、一人では対処できない場合には、ニエンに助けを求めることができ、よりスムーズに解決することができます。

推奨読書

「100 億回の訪問、キャッシュアーキテクチャの設計方法」

「多層キャッシュアーキテクチャ設計」

「メッセージプッシュアーキテクチャ設計」

「Alibaba 2: ノードは何台導入していますか?」1000W の同時実行を導入するにはどうすればよいですか? 》

「Meituan 2 Sides: Five Nines 高可用性 99.999%。それを達成するにはどうすればよいですか?」》

「NetEase 側: シングルノード 2000Wtps、Kafka はどうやってそれを行うのですか?」》

「バイト側: トランザクション補償とトランザクション再試行の関係は何ですか?」》

「NetEase 側: Mysql 書き込み 25Wqps の高スループット、100W データは 4 秒で書き込まれます。これを達成するにはどうすればよいですか?」》

「10億レベルのショートビデオをどのように構成するか？」》

「爆上げ、「自慢」に頼ってJD.comを乗り切る、月給4万」

「あまりに過酷なので、『自慢』に頼ってSFエクスプレスを乗り切り、月収は3万です」

「爆発しました...Jingdongは片側で40の質問を要求し、それを通過した後、それは500,000以上でした」

「質問するのはもううんざりです...アリは命を懸けて27の質問をしました、そしてそれを通過した後の質問は60万以上です」

「Baidu で 3 時間質問し続けた結果、大手企業からオファーをもらいました。この男は本当に残酷です!」》

「Ele.me は残酷すぎる: 高度な Java に直面して、それがどれほど困難で残酷な作業であるか」

「Byteに1時間尋ねた後、その男はオファーを受け取りました。それはとても残酷です!」》

「Didi のオファーを受け入れます: 若い頃の 3 つの経験から、何を学ぶ必要があるかわかりますか?」》

『Nien Architecture Notes』、『Nien High Concurrency Trilogy』、『Nien Java Interview Guide』PDF は、下記公式アカウント【Technical Freedom Circle】から入手してください ↓↓↓