私たちの友人が淘宝網や NetEase などの大規模な Web サイトを訪問するとき、ホームページ、製品詳細ページ、ニュース詳細ページがどのように扱われるかを考慮したことがありますか? これほど大量の訪問トラフィックをどのようにサポートできるのでしょうか?
多くの友人は、静的ソリューションを採用して、ユーザーがデータベースにアクセスせずに静的データ HTML を直接取得するように要求すると、パフォーマンスが大幅に向上し、Web サイトの SEO 最適化も向上することを提案するでしょう。そこで今日は、Lao Gu が静的化についてお話しします。Lao Gu が以前の作業シナリオで静的ソリューションで遭遇した問題と、それがどのように発展したかを友人と共有してください。
静的ファイルに関連する CDN テクノロジーについては、Lao Gu はここでは説明しません。この大規模な Web サイトは間違いなくこれを使用します。CDN が何であるかをオンラインで確認できます。CDN は比較的単純です。ここでは技術的なソリューションに焦点を当てます。
解決策 1: Web ページの静的 HTML
このソリューションは老谷が使用した最も初期のソリューションです。NetEase に似たニュース Web サイトの CMS システムを例に挙げます。コア フローチャート
上の図の核となるアイデア:
1) 管理バックグラウンドが記事を作成するためにニュース サービスを正常に呼び出した後、メッセージをメッセージ キューに送信します。
2) 静的サービスはメッセージをリッスンし、記事を静的にします。つまり、HTML ファイルを生成します。
3) 静的サーバーにファイル同期ツールをインストールします このツールの機能は、変更されたファイルの同期、つまり増分同期のみ可能です (Lao Gu は長い間使用していなかったので、ツールの名前を忘れました)
4) 同期ツールを使用して HTML ファイルをすべての Web サーバーに同期します。
このように、ユーザーがあまり変更のないページにアクセスした場合、HTML ファイルに直接アクセスして Web サーバーに直接返すため、データベースにアクセスする必要がなく、システムのスループットが比較的高くなります。
このソリューションの問題点:
1. Web ページのレイアウト スタイルは固定されており、変更できません。
ニュース詳細ページのレイアウトを調整する必要がある、現在のものでは十分に美しくない、または他のモジュールを追加する必要があるとプロダクト マネージャーが感じた場合、それは詐欺です。すべての静的 HTML 記事を再び静的にする必要があります。 。これは非現実的です。なぜなら、NetEase ほど大きなニュースの量は膨大であり、潰されてしまうからです。
2. ページ上の時間に一時的な不一致が発生します。
ユーザーが最新のニュースを視聴したというメッセージが表示されますが、更新するとこのメッセージは表示されなくなります。これは、同期ツールが Web サーバーと同期するのに時間がかかるためで、Web サーバー A とは同期しましたが、Web サーバー B はまだ同期する時間がありません。ユーザーがアクセスすると、nginx を通じて負荷分散が行われ、リクエストがランダムに Web サーバーに割り当てられます。もちろん、nginx の負荷分散戦略を調整して問題を解決することもできます。
3. HTML ファイルが多すぎて管理できません。
これは明らかな問題であり、HTML ファイルはますます増え、大量のストレージ スペースを必要とし、Web サーバーはすべて同じであるためディスク スペースを無駄に消費し、将来の移行やメンテナンスにも多くの問題が発生します。
4. 同期ツールの不安定性
ファイルが多すぎると、同期ツールの安定性に問題が生じるためです。
このソリューションはより伝統的なものである必要があります (推奨されません)
オプション 2: 擬似静的
擬似静的状態とは何ですか?
たとえば、通常、記事にアクセスします。一般的なリンク アドレスは次のとおりです。 http://www.xxx.com/news?id=1 は、ID 1 の記事へのリクエストを表します。ただし、このリンク方法は SEO にはあまり適していません (Web サイトにとって SEO は重要すぎるため)、通常は次のように変換されます: http://www.xxx.com/news/1.html この方法では、静的ページのように見えます。 。通常、nginx を使用して URL を書き換えることができます。興味があれば、比較的簡単に自分で調べることができます。
擬似静的である理由は、実際には動的処理が必要であるためです。
プラン 1 の上記の問題点に対応して、プランは以下のようにさらに進化しました。
この計画の核となる考え方
1) 管理バックグラウンドが記事を作成するためにニュース サービスを正常に呼び出した後、メッセージをメッセージ キューに送信します。
2) キャッシュ サービスはメッセージをリッスンし、記事のコンテンツをキャッシュ サーバーにキャッシュします。
3) ユーザーがリクエストを開始すると、Web サーバーは ID に基づいてキャッシュ サーバーに直接クエリを実行します。
4) データを取得してユーザーに返す
このソリューションは、ソリューション 1 の大きな問題である HTML ファイルが多すぎる問題を解決します。これは、HTML を生成する必要がなく、キャッシュを使用してデータベースにアクセスせずに問題を解決し、システムのスループットを向上させるためです。
ただし、この解決策には次のような問題があります。
1. このソリューションではすべてのコンテンツがキャッシュに保存されるため、Web ページのレイアウト スタイルのメンテナンス コストが比較的高くなります。レイアウトを変更する必要がある場合は、キャッシュをリセットする必要があります。
2. 分散キャッシュには大きな負荷がかかり、キャッシュに障害が発生すると、すべてのリクエストがデータベースにクエリを実行するため、システムがクラッシュします。
また、リアルタイムのデータ処理という小さな問題もあります。つまり、ページ上の価格と在庫をバックグラウンドで読み取る必要があります。もちろん、友人はそれも対応できると言うでしょう ユーザーが商品コンテンツをリクエストした後、ブラウザを使用して非同期 ajax リクエストを送信し、商品数量を取得できます。これは目に見えないリクエストの増加です。(この質問は無視して構いません)
このソリューションは、Tongcheng Travel などの多くの企業で使用されているものと似ています。
解決策 3: レイアウト スタイル テンプレート
オプション 2 の問題を解決するには、openresty 技術ソリューションを採用し、http テンプレート プラグイン lua スクリプトを使用して解決します。Lao Gu はここでは openresty+lua テクノロジを紹介しません。興味のある友人は https://www にアクセスしてください。 .roncoo .com/view/139 このビデオコース。
以下に示すように:
ここで説明させていただきますが、友人たちは上の図のすべてを理解する必要はありません。これは、3 レベル キャッシュの概念を含む、製品詳細ページに対する比較的完全なソリューションです。3 レベル キャッシュについては説明しません。ここ。
私たちが主に注目するのは、ngnix にディストリビューション層とアプリケーション層という 2 つの層があることです。これは何を意味するのでしょうか?
アプリケーション層nginx
Lao Guはまず、アプリケーション層nginxとは何を意味するのかを紹介します。nginx は一般的にロード バランシングに使用されます。実際、nginx には多くの機能があり、特にその openresty 拡張機能と lua スクリプト言語を組み合わせることで、多くの機能を完成させることができます。友人は、lua スクリプト言語が Java 言語に似ており、ビジネスを動的に処理できることを理解できます。例: ローカル キャッシュ処理、リモート http アクセス、Redis へのアクセスなど。
アプリケーション層の nginx は http テンプレートを使用し、lua スクリプトを通じて Web ページのレンダリングをキャッシュします。
httpテンプレート
1) アプリケーション層の nginx は、まず Lua スクリプト言語を通じてローカル製品データを取得し、次にそれを http テンプレートでレンダリングして最終的な製品詳細ページを形成し、ユーザーに返します。
2) アプリケーション層の nginx のローカル キャッシュにこの製品データがない場合、Lua スクリプトを通じて http リクエストを開始し、Web サーバーにアクセスして製品データを取得します。
3) Web サーバーは Redis またはローカル ehcache から製品データを要求します (ここには 3 レベルのキャッシュの概念が含まれます)。製品データが存在する場合はユーザーに直接返され、存在しない場合はユーザーに返されます。マイクロサービスにデータベースへのアクセスを要求します。
このアイデアは、解決策 2 のレイアウト スタイルの問題を http テンプレートによって解決するもので、レイアウトを調整する必要がある場合は、テンプレートを変更するだけで済み、非常に便利です。リアルタイムの問題も解決します。ここで使用される nginx ローカル キャッシュは、実際にはデータベースにアクセスする必要をなくし、システムのスループットを向上させるためのものです。openresty と lua を知らない場合は、オンラインで自分で学ぶことも、Lao Gu に連絡することもできます。
ディストリビューション層 ngnix
なぜ最上位にディストリビューション層があるのでしょうか? これは、大規模な Web サイトでは製品が多すぎるため、アプリケーション層 nginx のローカル キャッシュが制限されているためです。すべての製品データを同じサーバーのローカル キャッシュにキャッシュすることは不可能であり、アプリケーション層 nginx は製品データの一部しかキャッシュできません。 . この時点で、友人の皆さん、その理由が分かるはずですよね? ハッシュ一貫性アルゴリズムを使用して、製品 ID に基づいて製品を同じアプリケーション層の ngnix サーバーにルーティングおよび配布します。
ディストリビューション層における ngnix の役割は、ハッシュ戦略の負荷分散を行い、製品 ID が固定アプリケーション層サーバーに確実にルーティングされるようにすることです。
3 次キャッシュはシステムの安定性を保証し、たとえ Redis キャッシュがクラッシュしたとしても、他に 2 つのキャッシュ保証があります。
要約:
オプション 3 は比較的完全なソリューションであり、多くの大手メーカーが使用しており、数億のトラフィックに耐えることができますが、システムはより複雑です。
リアルタイム要件が高くなく、レイアウト スタイルの調整が頻繁に行われない場合は、オプション 2 を検討できます。システムは比較的シンプルです。