1 日あたり 200 億コール、ヒマラヤゲートウェイのアーキテクチャ設計

前もって言う

40 歳の建築家 Nien の読者コミュニティ(50 歳以上) では、多くの友人が Alibaba、NetEase、Youzan、Xiyin、Baidu、Didi などの一流インターネット企業の面接資格を取得しています。

最近、ニエンは小規模パートナーの履歴書を指導し、「API ゲートウェイプロジェクト」を書きました。このプロジェクトのおかげで、この男はByte/Ali/Weibo/Autohome から面接の招待状を得ることができました。これは素晴らしいプロジェクトです。

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

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

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

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

前に整理しました

ここにもう 1 つの美しい実稼働レベルのケースがあります。「Ximalaya が自社開発した 10 億レベルの API ゲートウェイテクノロジーの実践」、これも非常に素晴らしい産業グレードおよび実稼働グレードのゲートウェイケースです。

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

記事ディレクトリ

Ximalaya が自社開発した 10 億レベルの API ゲートウェイテクノロジーの実践

ゲートウェイは比較的よく開発された製品であり、継続的に発生する公共のビジネスニーズに対応し、迅速に反復および更新するためのミドルウェアとして、大手インターネット企業によって広く使用されています。

ゲートウェイがなければ、公開機能を更新する場合、すべてのビジネスパーティにその更新とリリースを強制する必要があり、これは間違いなく非常に非効率的です。ただし、ゲートウェイを使用すると、これは問題になりません。

ヒマラヤでも同様で、ユーザー数は 6 億人に増加し、Web サービスの数は 500 を超えています。現在、当社のゲートウェイは毎日 200 億件以上の通話を処理し、単一マシンのピーク QPS は 40,000 に達することがあります。 +。

ゲートウェイには、基本的なリバースプロキシ機能の実装に加えて、ブラックリストとホワイトリスト、フロー制御、認証、サーキットブレーク、API 公開、監視とアラームなどの多くの共通機能もあります。ビジネス側のニーズに応じて、トラフィックスケジューリング、トラフィックレプリケーション、プレリリース、インテリジェントアップグレード、トラフィックプリヒートおよびその他の関連機能も実装しました。

技術的に言えば、Ximalaya API Gateway のテクノロジー進化ロードマップはおおよそ次のとおりです。

注: 画像をクリックすると鮮明な画像が表示されます。

この記事では、Ximalaya API Gateway が数億のトラフィックに直面したときにどのように技術進化を実行するか、および実際の経験の概要を紹介します。

1、第1版：Tomcat NIO+Async Servlet

アーキテクチャ設計におけるゲートウェイの重要なポイントは、リクエストを受信してバックエンドサービスを呼び出すときに、それをブロック (Block) できないことです。そうしないと、ゲートウェイの処理能力が制限されてしまいます。

これは、最も時間がかかる操作は、バックエンドサービスをリモートで呼び出すプロセスであるためです。

ここでブロッキングが発生すると、すべての Tomcat ワーカースレッドがブロックされ、バックエンドサービスからの応答を待っている間は他のリクエストを処理できなくなるため、ここでは非同期処理を使用する必要があります。

アーキテクチャ図は次のとおりです。

注: 画像をクリックすると鮮明な画像が表示されます。

このバージョンでは、ゲートウェイが応答を受信した後にクライアントに応答するために使用される別のプッシュレイヤーを実装し、このレイヤーを通じてバックエンドサービスと通信します。

このレイヤーは HttpNioClient を使用し、ブラックリストとホワイトリスト、フロー制御、認証、API 公開などのビジネス機能をサポートします。

ただし、このバージョンはゲートウェイの要件を機能的に満たしているだけであり、処理能力がすぐにボトルネックになりました。スタンドアロン QPS が 5K に達すると、フル GC が頻繁に発生します。

オンラインヒープを分析したところ、Tomcat が大量の HTTP リクエストをキャッシュしていることが問題であることがわかりました。Tomcat はデフォルトで 200 個の requestProcessor をキャッシュし、各プロセッサがリクエストに関連付けられているためです。

さらに、Tomcat の Servlet 3.0 の非同期実装により、メモリリークが発生する可能性があります。その後、この構成を減らしたところ、その効果は明らかでした。

ただし、この調整によりパフォーマンスが低下します。要約すると、Tomcat をアクセス端末として使用すると、次の問題があります。

Tomcat 自体の問題:

1) キャッシュが多すぎます。Tomcat は多くのオブジェクトプールテクノロジを使用します。メモリが限られている場合、トラフィックが増加すると GC がトリガーされやすくなります。
2) メモリコピー。Tomcat のデフォルトメモリはヒープメモリを使用するため、データはヒープから読み取る必要があります。バックエンドサービスは Netty であり、オフヒープメモリを使用し、複数のコピーが必要です。
3) Tomcat のもう 1 つの問題は、ボディの読み取りがブロックされることです。Tomcat の NIO モデルはリアクターモデルとは異なります。ボディの読み取りはブロックされます。

Tomcat バッファの別の関係図を次に示します。

注: 画像をクリックすると鮮明な画像が表示されます。

上の図から、Tomcat のカプセル化機能は非常に完全であることがはっきりとわかりますが、内部のデフォルト設定では 3 つのコピーが存在します。

HttpNioClient の問題: 接続の取得と解放のプロセス中にロックが必要です。ゲートウェイなどのプロキシサービスシナリオでは、これにより接続の確立と終了が頻繁に行われることになり、間違いなくパフォーマンスに悪影響を及ぼします。

Tomcat のこれらの問題を考慮して、その後、アクセスエンドを最適化し、アクセス層およびサービス呼び出し層として Netty を使用しました (2 番目のバージョン)。これにより、上記の問題が解決され、理想的なパフォーマンスが実現されました。

2. バージョン 2: Netty+ 完全非同期

Netty の利点に基づいて、完全に非同期でロックフリーの階層型アーキテクチャを構築しました。

まず、Netty に基づいたアクセス端末のアーキテクチャ図を見てみましょう。

注: 画像をクリックすると鮮明な画像が表示されます。

2.1 アクセス層

Netty の IO スレッドは、主に HTTP プロトコルのエンコードとデコードを担当し、プロトコルレベルで異常な状況を監視し、警告します。

HTTPプロトコルのエンコードとデコードを最適化し、異常なリクエストや攻撃的なリクエストを監視および可視化しました。

たとえば、HTTP リクエスト行とリクエストヘッダーのサイズには制限がありますが、Tomcat はリクエスト行とリクエストヘッダーを一緒に計算し、合計サイズは 8K を超えませんが、Netty は両方に個別にサイズ制限を設定します。

クライアントから送信されたリクエストが設定されたしきい値を超えた場合、Cookie を含むリクエストはこの制限を簡単に超える可能性があり、通常の状況では、Netty はクライアントに直接 400 を応答します。

最適化後は、通常サイズの部分のみを取り出してプロトコル解析の失敗をマークし、ビジネス層がどのサービスにそのような問題があるかを判断できるようにします。

ボディを送信せずにリクエストヘッダーのみを送信する、またはコンテンツの一部のみを送信するなど、他の積極的なリクエストの場合は、監視と警告が必要です。

2.2 ビジネスロジック層

この層は、API ルーティング、トラフィックスケジューリングなど、ビジネスをサポートする一連のパブリックロジックの実装を担当します。この層は責任連鎖モデルを採用しており、この層では IO 操作は実行しません。

業界や大企業のゲートウェイ設計では、通常、ビジネスロジック層は責任連鎖モデルで設計され、パブリックビジネスロジックもこの層に実装されます。

この層でも同様の操作を実行し、次の機能をサポートします。

1)ユーザー認証とログイン検証はインターフェイスレベルの設定をサポートします。
2)ブラックリストとホワイトリスト: グローバルおよびアプリケーションのブラックリストとホワイトリスト、および IP およびパラメータレベルの制限が含まれます。
3)トラフィック制御: 自動制御と手動制御を提供し、自動制御は過剰なトラフィックを遮断でき、トークンバケットアルゴリズムを通じて実装されます。
4)インテリジェントサーキットブレーカー: Histrix をベースに改良され、自動アップグレードとダウングレードをサポートします. 全自動方式を採用し、即時サーキットブレーカーの手動設定もサポートします。サーキットブレーカーが自動的に作動します。
5)グレースケールリリース: 新しく起動したマシンのトラフィックに対して、TCP と同様のスロースタートメカニズムをサポートし、マシンのウォームアップ時間を提供します。
6)統合ダウングレード: 転送に失敗したすべてのリクエストに対して統合ダウングレード操作を実行します. ビジネス側がダウングレードルールを設定している限り、ダウングレードされます. 値を含むパラメータレベルまでのダウングレードルールの調整をサポートしますリクエストヘッダー内で、これは非常に詳細であり、粒度に加えて、ワニスの適切な劣化をサポートするためにワニスと統合します。
7)トラフィックスケジューリング: フィルタリングルールに従ってトラフィックを該当マシンに割り当てるビジネスをサポートし、フィルタリングされたトラフィックのみマシンへのアクセスを許可することもサポートします。これは、トラブルシューティングや新機能のリリースの検証時に非常に役立ちます。トラフィックの一部を最初に検証し、それを大規模にオンラインで解放することができます。
8)トラフィックコピー: ルールに従って元のオンラインリクエストのコピーをコピーし、それを MQ またはその他の上流に書き込み、オンラインでクロスマシンルーム検証やストレステストを行うことをサポートします。
9)リクエストログサンプリング: 失敗したすべてのリクエストをサンプリングし、ビジネス側が問題を解決できるようにディスクに保存します。また、ビジネス側がルールに従ってパーソナライズされたサンプリングを実行できるようにサポートします。ライフサイクル全体のデータをサンプリングしました。リクエストを含む、レスポンスに関連するすべてのデータ。

上記のすべての関数はトラフィックの管理に使用されます。各関数はフィルターとして機能します。処理の失敗は転送プロセスには影響せず、これらすべてのルールのメタデータはゲートウェイの起動時に初期化されます。

実行プロセス中、IO 操作は実行されません。現在、一部のデザインでは複数のフィルターが同時に実行されます。操作はすべてメモリ内で実行され、オーバーヘッドが大きくないため、現時点では同時実行はサポートされていません。

さらに、ルールは変更される可能性があるため、ルールを動的に更新する必要があります。

ルールを変更すると、リアルタイム更新を実行するようにゲートウェイサービスに通知し、IO 操作がビジネススレッドに影響を与えるのを防ぐために、独立したスレッドを通じて内部メタデータ更新リクエストを処理します。

2.3 サービスコール層

プロキシゲートウェイサービスにとってサービスの呼び出しは非常に重要であり、このリンクでは、パフォーマンスが非常に高くなければならず、非同期である必要があります。

この目標を達成するために Netty を使用し、また Netty が提供する接続プールを最大限に活用して取得と解放のロックフリー操作を実現しました。

2.3.1 非同期プッシュ

サービス呼び出しを開始した後、ゲートウェイはワーカースレッドがサーバーからの復帰を待たずに他のリクエストの処理を続行できるようにします。

この設計では、リクエストごとにコンテキストを作成します。リクエストを送信した後、リクエストのコンテキストを対応する接続にバインドします。Netty がサーバーから応答を受信すると、接続上で読み取り操作を実行します。

デコード完了後、接続から対応するコンテキストを取得し、そのコンテキストを介してアクセス側のセッションを取得することができる。

このように、プッシュはセッションを通じて応答をクライアントに書き戻します。この設計は、HTTP 接続の排他性に基づいています。つまり、接続と要求コンテキストはバインドされています。

2.3.2 接続プール

接続プールの原理は次のとおりです。

注: 画像をクリックすると鮮明な画像が表示されます。

サービス呼び出し層は、リモート呼び出しを非同期に開始するだけでなく、バックエンドサービスへの接続を管理する必要もあります。

HTTP は RPC とは異なります。HTTP 接続は排他的であるため、接続を解放するときは注意が必要です。サーバーの応答を待ってから解放する必要があります。また、接続を閉じるときも注意する必要があります。

要点をまとめると次のようになります。

1）接続: 閉じる;
2) アイドルタイムアウト、接続を閉じます。
3) 読み取りタイムアウトにより接続が閉じられます。
4) タイムアウトを書き込み、接続を閉じます。
5）フィン、リセット。

接続を閉じる必要がある上記のいくつかのシナリオでは、主に接続について説明します。クローズとアイドル書き込みタイムアウト、その他の状況 (読み取りタイムアウト、接続アイドルタイムアウト、フィンの受信、リセットコードなど) がより一般的です。

2.3.3 接続:閉じる

バックエンドサービスはTomcatを使用しており、接続の再利用回数に規定があり、デフォルトは100回です。

制限 100 に達すると、Tomcat は応答ヘッダーにConnection:close を追加し、クライアントに接続を閉じるよう要求します。そうでないと、接続を再度使用してリクエストを送信すると 400 エラーが発生します。

また、フロントエンドリクエストがConnection:closeを伝送する場合、Tomcat は接続が 100 回再利用されるまで待機しません。つまり、接続を 1 回閉じます。

応答ヘッダーにConnection:close を追加すると、接続は短い接続になります。

Tomcat で長時間接続を維持する場合は注意が必要で、接続を使用したい場合は close ヘッダーを積極的に削除する必要があります。

2.3.4 書き込みタイムアウト

まず、ゲートウェイはどの時点でサービスのタイムアウトの計算を開始しますか?

writeAndFlush の呼び出し時間から計算すると、実際には Netty の HTTP エンコード時間と、キューからリクエストを送信する時間、つまりバックエンドサービスにとって不公平なフラッシュ時間が含まれます。

したがって、サーバーに最も近い、実際のフラッシュが成功してからタイミングを開始する必要があります。もちろん、ネットワークのラウンドトリップ時間やカーネルプロトコルスタックの処理時間も含まれます。これは避けられないことですが、基本的には安定した。

したがって、フラッシュコールバックが成功した後にタイムアウトタスクを開始します。

フラッシュが迅速にコールバックできない場合、たとえば、大きな POST リクエストに遭遇した場合、ボディ部分が大きく、Netty は送信時にデフォルトで 1k サイズのみを送信することに注意してください。

送信が完了していない場合は送信サイズを増やして送信を続行します Netty が 16 回送信しても送信が完了していない場合は送信は続行されず、タスクキューにフラッシュタスクが投入されます次回の実行後に送信されます。

このとき、フラッシュコールバックに時間がかかるため、リクエストのクローズが間に合わず、バックエンドサービスである Tomcat のボディ部分の読み取りが常にブロックされてしまうため、上記の分析に基づいて、書き込みタイムアウト。大きな本文リクエストの場合、時間内に書き込みタイムアウトになります。接続を閉じます。

3. 完全なリンクタイムアウトメカニズム

注: 画像をクリックすると鮮明な画像が表示されます。

上の図は、リンク全体でタイムアウトを処理するメカニズムです。

1) プロトコル解析タイムアウト。
2) キューがタイムアウトするのを待ちます。
3) 接続タイムアウト。
4) 接続タイムアウトを待機しています。
5) 書き込む前にタイムアウトするかどうかを確認します。
6) 書き込みタイムアウト。
7) 応答タイムアウト。

4. 監視と警報

ゲートウェイのビジネス側にとって、彼らが見ることができるのは監視とアラームの機能です。私たちは第 2 レベルのアラームと監視を実装でき、監視データを管理システムに定期的にアップロードできます。管理システムは統計を要約して保存する責任があります。 InfluxDBの真ん中。

当社では、HTTP プロトコルに関する包括的な監視とアラートを提供し、プロトコル層とサービス層の問題の両方をカバーしています。

プロトコル層:

1) 攻撃的なリクエストの場合、ヘッダーのみが送信される、送信されない、または本文の一部のみが送信され、サンプリングして録画し、シーンを復元し、アラームをトリガーします。
2) ライン、ヘッド、ボディが大きすぎるというリクエストに対しては、サンプリングして録音し、シーンを復元し、時間内にアラームを発します。

アプリケーション層:

1)時間消費の監視: 遅いリクエスト、タイムアウトリクエスト、tp99、tp999 などを含みます。
2) OPS を監視し、適時にアラームを発行します。
3)帯域幅の監視とアラーム: 要求行と応答行、ヘッダー、本文の個別の監視をサポートします。
4)応答コード監視: 特に 400 と 404。
5)接続監視: アクセスエンドへの接続、バックエンドサービスへの接続、バックエンドサービス接続で送信されるバイトサイズを監視します。
6)失敗したリクエストの監視。
7)トラフィックジッターアラーム: これは非常に必要です。トラフィックジッターは問題であるか、差し迫った問題の前兆である可能性があります。

全体的なアーキテクチャ:

注: 画像をクリックすると鮮明な画像が表示されます。

5. パフォーマンス最適化の実践

5.1 オブジェクトプールテクノロジー

同時実行性の高いシステムの場合、オブジェクトを継続的に作成するとメモリリソースが占有されるだけでなく、ガベージコレクションプロセスに圧力がかかります。

この問題を解決するために、スレッドプールタスクや StringBuffer などの頻繁に使用されるオブジェクトを実装プロセスで再利用し、メモリ割り当てのコストを削減します。

5.2 コンテキストの切り替え

同時実行性の高いシステムでは、通常、非同期設計が採用されます。非同期化後は、スレッドのコンテキスト切り替えの問題に注意する必要があります。

私たちのスレッドモデルは次のとおりです。

注: 画像をクリックすると鮮明な画像が表示されます。

私たちのゲートウェイには I/O 操作は含まれませんが、ビジネスロジック処理で Netty の I/O エンコーディングおよびデコーディングスレッドの非同期メソッドを使用します。

これには主に 2 つの理由があります。

1) 開発者が作成したコードがブロックされるのを防ぎます。
2) 突然の状況で、ビジネスロジックが大量のログレコードを生成する可能性があるため、スレッドをプッシュする際の代替として Netty の I/O スレッドの使用を許可します。このアプローチにより、CPU コンテキストスイッチの数が減り、全体のスループットが向上します。非同期にするためだけに非同期にすることはできません。Zuul2 の設計哲学は私たちのアプローチに似ています。

5.3 GCの最適化

同時実行性の高いシステムでは、ガベージコレクション GC の最適化が不可欠です。

オブジェクトプールテクノロジとオフヒープメモリを使用するため、オブジェクトが古い世代に入ることがほとんどなくなり、若い世代の設定は比較的大きく、SurvivorRatio は 2 に設定され、昇格年齢は最大 15 に設定されています。物品が可能な限り若い世代にリサイクルされるようにすること。

ただし、監視の結果、古い世代のメモリは依然としてゆっくりと増加していることがわかりました。ダンプ分析を通じて、各バックエンドサービスはリンクを作成し、常にソケット (ソケットの AbstractPlainSocketImpl) が存在し、AbstractPlainSocketImpl は Object クラスの Finalize メソッドを書き換えます。

実装は次のとおりです。

/**
 * Cleans up if the user forgets to close it.
 */
protected void finalize() throws IOException {
    
    
    close();
}

これは、リンクを積極的に閉じていないため、予防策として行ったものであり、gc がリサイクルされると、対応するリンクリソースが最初に解放されます。

ファイナライズメカニズムは JVM のファイナライザースレッドを通じて処理されるため、その優先順位は高くなく、デフォルトは 8 です。Finalizer スレッドが ReferenceQueue オブジェクトに対応するファイナライズメソッドの実行を完了するまで待機し、オブジェクトをリサイクルする前に次のガベージコレクションまで待機する必要があります。その結果、リンクを作成するこれらのオブジェクトは若い世代ですぐにリサイクルできず、古い世代に入り、そのため古い世代はゆっくりと成長し続けます。

5.4 ログ

同時実行性の高いシステム、特に Netty の I/O スレッドでは、I/O 読み取りおよび書き込み操作の実行に加えて、非同期タスクやスケジュールされたタスクも実行する必要があります。I/O スレッドがキュー内のタスクを処理できない場合、受信した非同期タスクは拒否される可能性があります。

どのような状況でこれが発生する可能性がありますか? 非同期の読み取りと書き込みは、主に CPU の消費量が増えるため、大きな問題にはなりません。I/O スレッドをブロックする可能性が最も高いのはログ記録です。現在、Log4j の ConsoleAppender ログのimmediateFlushプロパティのデフォルトはtrueです。つまり、ログが記録されるたびに同期的にディスクに書き込まれ、メモリ操作が遅くなります。

同時に、AsyncAppender のログキューがいっぱいになると、スレッドはブロックされます。Log4j のデフォルトのバッファサイズは 128 で、ブロック化されています。つまり、バッファサイズが 128 に達すると、ログ書き込みスレッドがブロックされます。同時ログ書き込みの量が多く、スタックが深い場合、Log4j の Dispatcher スレッドが遅くなる可能性があるため、フラッシュする必要があります。この方法では、バッファーをすぐに消費することができず、ログイベントで簡単にいっぱいになり、Netty I/O スレッドがブロックされてしまいます。したがって、ログを記録するときは、簡潔さに注意する必要があります。

6. 今後の計画

現在、私たちは皆 HTTP/1 に基づくプロトコルを使用しています。

HTTP/1 と比較すると、HTTP/2 は接続レベルでサービスを実装します。つまり、1 つの接続で複数の HTTP リクエストを送信できます。

これは、HTTP 接続を複数の接続を確立することで RPC 接続と同じように確立できることを意味し、繰り返しの接続確立によるオーバーヘッドと、HTTP/1 接続を再利用できないことによって引き起こされる起動の遅さを完全に解決します。

Netty ベースの HTTP/2 へのアップグレードを行っており、技術的なアップグレードに加えて、ビジネス側に正確でエラーのないアラームを提供するために監視アラームの最適化を継続的に行っています。また、サイト全体の障害が発生した場合でもゲートウェイを介して速やかにダウングレードできるよう、ユニファイドアクセスゲートウェイとビジネスサイドとして総合的なダウングレード対策を実施しており、これも当社の重要な業務です。

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

建築の道は山あり谷あり

アーキテクチャは高度な開発とは異なります。アーキテクチャに関する質問はオープン/オープンであり、アーキテクチャに関する質問に対する標準的な回答はありません。

このため、多くの友人は多大なエネルギーとお金を費やしたにも関わらず、残念ながら一生のうちにアーキテクチャのアップグレードを完了することができません。

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

少し前まで小さなパートナーだった彼は、専攻を超えて Java を担当しており、現在はアーキテクチャ変更の問題に直面していますが、Nien からの数回の指導の後、Java アーキテクト + ビッグデータアーキテクトのオファーを獲得することに成功しました。したがって、キャリア上で困難に直面した場合は、経験豊富な建築家に助けを求める方がスムーズです。