進化: Web プロキシ サーバーから分散プッシュ サーバーへの Tengine

テンエンジン

プロキシ サーバーとして、Tengine はグループ内で幅広いアプリケーションを備えています。単一のアプリケーション マシンに展開された Tengine から、クラスター展開の統合アクセスとしての Aserver まで、グループ内のほぼすべてのアプリケーション マシンで Tengine が実行されていると言えます。もちろん、Tengine の展開形式が異なれば、機能も異なります。これは、優れたリバース プロキシ サーバーとしての Tengine が、高性能、低レイテンシ、高可用性という特性を備えているためです。

[[317809]]

次の図は、一般的な統合アクセス モデルを示しています。

HTTP ロング接続サービスの現在の状況

クライアントによって開始されたリクエストが HTTP2 であるか HTTP 1.1 であるかに関係なく、リバース プロキシ サーバーとしての Tengine は、次の図に示すように、アプリケーション サーバーと短時間接続します (Tengine が keepalive で構成されていない場合)。

Tengine は、クライアントとの長い接続を維持し、特定の負荷分散アルゴリズムを使用してアプリケーション サーバーとの短い接続をスケジュールする役割を担います。

現在のHTTPプッシュソリューション

通常、プッシュリクエストは、決まった時間にデータを末端に送信するものです。

投票

クライアントはビジネス データをポーリングするための要求を定期的に送信します。

これは最もシンプルで簡単な方法ですが、実際のプロジェクトで使用される可能性が最も低い解決策であることがよくあります。なぜなら、その欠点は非常に明白だからです。

1. 短い間隔のポーリング要求により、サーバーは目的もなく無駄な QPS を処理することになり、QPS は端末の数に比例します。

2. ポーリング要求のプッシュの適時性は、より長い間隔では保証されません。

アプリケーションサービス処理

つまり、Tengine はリバース プロキシ サーバーとして、基本的な転送機能のみを実行し、HTTP 要求を保持し、必要に応じてそれに応答します。

欠点は明らかです。アプリケーションは、長時間の接続のライフサイクルを自ら維持する必要があり、プッシュ シナリオのユーザーは、超大規模な端末デバイスであることが多いです。超大規模で長い接続は、当然ながら、アプリケーション マシンのリソースを大量に消費します。

HTTP2 プッシュ (サーバー プッシュ)

実際、HTTP2 のプッシュ機能は、単一のリクエストに対して複数の応答があることを意味し、長い接続チャネルでの継続的なデータ転送の要件と一致しません。

以下は RFC によるサーバー プッシュ機能の紹介ですが、ここでは詳しく説明しません。

 HTTP/2では、サーバーが事前に（または  「プッシュ」 ）応答
   （対応する「約束された」リクエストとともに）クライアントに 
   以前のクライアントが開始したリクエストとの関連付け。これは
   サーバーがクライアントがそれらを必要とすることを知っている場合に便利です
   回答は以下で入手可能 注文 応答を完全に処理するために
   元のリクエスト。

テンエンジンシングルマシンプッシュ

現在、主流のオープンソース Nginx モジュールはスタンドアロン プッシュ機能をサポートしています。

プッシュプロセス

実はMQTTのSUB PUBモードと非常に似ていますが、HTTPを使用して実装されています。具体的なプロセスは以下のとおりです。

1. A がリクエストを開始し、Tengine がそのリクエストをハイジャックして保持し、Tengine はそれに対応する KeyA を生成します。

2. B が A にデータをプッシュする場合、KeyA をパラメーター (またはヘッダー) として使用して、指定された Tengine に POST データを送信できます。

3. Tengine は、B から受信した POST データから KeyA に対応する接続​​を取得し、A に返します。

欠点

1. BはAの存在を認識する必要がある

つまり、A のリクエストが Tengine に届いたとき、Tengine はそれをバイパスして B に送信する必要があり、つまり B に A の存在を通知する必要があり、B は A に対応する KeyA を記録する必要があります。

解決策: Tengine の auth_request 関数を使用できます。もちろん、Lua の ngx.location.capture メソッドを使用することもできます。

2. Tengineがクラスタに導入されている場合、Bは集中型ストレージを必要とする

B は通常、非モノリシック アプリケーション、つまり複数のマイクロサービスで構成されます。どのリンクであっても、B が A にメッセージをプッシュする必要がある場合、明らかに Tengine クラスター内のどのマシン A が稼働しているかを知る必要があります。したがって、B アプリケーションでは、どの Tengine にリクエストを送信するかを決定するために、少なくとも 1 つのマイクロサービスを集中ストレージ (redis、memcache など) に保存する必要があります。

Tengine 実装ソリューション

1. Tengineには集中型ストレージが付属

Tengine は、TCP 接続ごとにキー (リクエスト ヘッダーなどもキーとして使用できます) を生成し、キーと対応するマシン IP 間のマッピング情報を集中ストレージに保存します。アプリケーションは、Tengine クラスター内の任意のマシンにデータをプッシュするだけで、Tengine が分散ルーティングを実行します。次の図は、プッシュの観点から Tengine がどのように機能するかを示しています。

1. アプリケーションは、Tengine クラスター内のランダムなマシンにプッシュされます。プッシュには、プッシュ先の接続を示す対応するキーが含まれます。

2. Sc はプッシュ メッセージを受信し、対応するリクエストを保持している Tengine マシンを Tair で検索します。たとえば、プッシュの宛先接続が Sb にあることがわかります。

3. Sc は Sb に転送されます。

4. データを受信した後、Sb は対応するクライアント接続を見つけて、データをクライアントにプッシュします。

アプリケーションは vipserver を使用して Tengine マシンをランダムに検索できます。 Tengine は、ビジネス アクセス用に vip/slb を申請し、vip/slb の負荷分散機能を利用して Tengine にランダムにアクセスすることもできます。

2. ストリーミングをサポート

通常、長い接続では、プッシュ メッセージの終了後に新しいプッシュ メッセージを作成するのではなく、複数のプッシュ メッセージを受信することが予想されます。 Tengine は豊富な HTTP 処理機能に依存しており、multipart/form-data を使用してプッシュ データの境界が明確であることを確認します。複数のプッシュには明確な境界線があり、クライアントは複数のプッシュ データを取得するために 1 つの接続のみを必要とします。

3. マルチプロトコルサポート

Tengine 自体は複数のプロトコルをサポートしています。クライアントが HTTP を開始するか HTTP2 を開始するかに関係なく、上記のプッシュ機能を継承できます。

4. 高いパフォーマンス

プロキシ サーバーとして、Tengine の転送パフォーマンスは業界のベンチマークとなっています。 Tengine が分散ルーティング機能を持つことができるように、Tengine 転送プロセスに集中型ストレージ機能を追加しました。