LiveJournal や eBay など、大規模な Web サイトのアーキテクチャの進化を紹介する記事はこれまでにもいくつかあり、非常に参考になりますが、その理由を詳細に説明するよりも、それぞれの進化の結果について詳しく述べているように感じます。このような進化の後、多くの学生がなぜ Web サイトにこれほど複雑なテクノロジーが必要なのかを理解するのが難しいと感じているという事実に加えて、この記事を書くことを思いつきました。通常の Web サイトから大規模な Web サイトのプロセスにおける比較的典型的なアーキテクチャの進化プロセスと、習得する必要がある知識システムについて説明します。これが、インターネットで働きたいと考えている学生にいくつかの予備的な概念を与えることができれば幸いです。業界:) この記事が新しいアイデアを呼び込む役割を果たすことができるように、記事に間違いがある場合はさらに提案をお願いします。
アーキテクチャ進化の最初のステップ: Webサーバーとデータベースを物理的に分離
最初は、いくつかのアイデアにより、インターネット上にWebサイトを構築しましたが、この時点では、ホストがインターネット上にある可能性さえありました。この記事では、アーキテクチャの進化のみに焦点を当てているため、この時点でホストはすでにホストされており、Web サイトには特定の特性があるため、一定の帯域幅を持っていると仮定します。何人かの人々が訪問し始めますが、徐々にシステムの負荷が高まり、応答速度がどんどん遅くなっていることがわかります。このとき、データベースとアプリケーションが相互に影響を与えていることがより明らかになります。アプリケーションに問題があると、データベースにも問題が発生しやすくなり、データベースに問題が発生すると、アプリケーションにも問題が発生しやすくなります。そこで、アプリケーションとデータベースを物理的に 2 つのマシンに分離するという進化の最初のステップに入りました。現時点では、新しい技術要件はありませんが、影響があることがわかり、システムは以前の応答速度に復元され、データベースとデータベースによって相互に影響を与えることなく、より高いトラフィックをサポートできるようになりました。応用。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
アーキテクチャの進化のこのステップには、基本的に技術的な知識システムの要件はありません。
アーキテクチャの進化の第 2 ステップ: ページ キャッシュの増加
訪問者が増えると、応答速度が再び遅くなり始めることに気づきます。データベースにアクセスする操作が多すぎると、データ接続の競争が激しくなり、応答が遅くなります。ただし、データベース接続をオープンしすぎると、データベース マシンへの負荷が非常に高くなります。したがって、データベース接続リソースの競合とデータベース読み取りの負荷を軽減するために、キャッシュ メカニズムの使用を検討してください。この時点では、まず、Squid および他の同様のメカニズムを使用して、システム内の比較的静的なページ (ページなど) をキャッシュすることを選択できます。 1 ~ 2 日で更新されます) (もちろん、ページを静的にするソリューションを使用することもできます)。これにより、プログラムを変更せずに、Web サーバーへの負荷を大幅に軽減し、データベース接続リソースの競合を減らすことができます。 . それで、比較的静的なページをキャッシュするために Squid を使い始めました。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
Squid などのフロントエンド ページ キャッシュ テクノロジ。それをうまく使いたい場合は、イカメソッドやキャッシュ無効化アルゴリズムなどの実装を深くマスターする必要があります。
アーキテクチャ進化の第 3 ステップ: ページ フラグメント キャッシュの追加
キャッシュ用に Squid を追加した後、システム全体の速度は確かに向上し、Web サーバーへの負荷も減少し始めましたが、アクセス数が増加すると、システムが再び少し遅くなり始めることがわかりました。Squid などの動的キャッシュの利点を味わった後、現在の動的ページの比較的静的な部分もキャッシュできるのではないかと考え始めました。 , そこで、ESI などのページ フラグメント キャッシュ戦略のようなものを使用することを検討しました。そこで、動的ページの比較的静的なフラグメント部分をキャッシュするために ESI を使用し始めました。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
ESI などのページ フラグメント キャッシュ テクノロジ。これをうまく使用したい場合は、 ESI などの実装もマスターする必要があります。;
アーキテクチャ進化の第 4 ステップ: データ キャッシュ
ESI などのテクノロジーを使用してシステムのキャッシュ効果を再度改善した後、システムへの負荷は実際にさらに軽減されましたが、アクセス数が増加すると、検索後にシステムの速度が低下し始める可能性があります。ユーザー情報の取得など、データ情報を繰り返し取得する箇所があったので、このデータ情報もキャッシュできないかと検討し、変更後のデータをローカルメモリにキャッシュしました。システムの応答速度は再び回復し、データベースへの負担も大幅に軽減されました。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
マップデータ構造、キャッシュアルゴリズム、選択したフレームワーク自体の実装メカニズムなどを含むキャッシュテクノロジー。
アーキテクチャ進化の 5 番目のステップ: Web サーバーの追加
好調な時期は長くは続かず、システムのアクセス数が再び増加すると、Web サーバー マシンへの負荷が相対的に上昇することがわかりました。この時点で、Web サーバーを追加することを検討し始めました。これは、可用性の問題を解決すると同時に、単一の Web サーバーがダウンした場合に使用できなくなることを防ぐためでもあります。 Web サーバーを追加する場合、次のような問題が発生します。
1. この時点で通常考えられる解決策は、Apache 独自の負荷分散ソリューションです。 LVS などのソフトウェア負荷分散ソリューション; 2. ユーザーセッションなどのステータス情報の同期を維持する方法。現時点で検討されるソリューションには、データベースへの書き込み、ストレージへの書き込み、またはセッションの同期が含まれます。情報およびその他のメカニズム
3. 以前にキャッシュされたユーザー データなどのデータ キャッシュ情報の同期を維持する方法。現時点で通常考慮されるメカニズムには、次のような同様の機能を作成する方法が含まれます。ファイルのアップロードは引き続き正常に動作します。現時点で通常考えられるメカニズムは、共有ファイル システムまたはストレージの使用です。これらの問題を解決した後、最終的に Web サーバーの数が 2 つに増加し、システムは最終的に以前の速度に戻りました。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
しばらくの間、システムのアクセス数が急速に増加するという幸福を味わった後、システムが再び速度を落とし始めていることに気付きました。検索した結果、データベースの書き込みおよび更新操作中にデータベース接続リソースの競合が非常に激しく、システムの速度が低下することがわかりました。現時点で利用できるオプションにはデータベースのクラスタリングとサブが含まれます。 - データベース戦略に関しては、データベースのサポートがあまり優れていないため、サブデータベースを実現するには元のプログラムを変更する必要があることがより一般的になります。 -データベース、はい、目標は達成され、システムの回復は以前よりもさらに速くなりました。
このステップが完了した後のシステムの図を見てください:このステップには次の知識システムが含まれます:
しかし同時に、データ量の増加とサブデータベースの進歩に伴い、データベースのより適切な設計、チューニング、メンテナンスを行う必要があるため、これらの側面におけるテクノロジーが必要になります。はまだ非常に要求が厳しいです。
アーキテクチャ進化の 7 番目のステップ: テーブル シャーディング、DAL、分散キャッシュ
システムが実行を続けると、データ量が大幅に増加し始めますが、この時点ではクエリがまだ少し遅いことがわかります。データベースが分割された後、サブデータベースのアイデアに従って、サブテーブルの作業を開始します。おそらく、この時点で、必然的にプログラムにいくつかの変更が必要になることがわかります。アプリケーション自体は、サブデータベースやサブテーブルなどのルールを考慮する必要があり、まだ少し複雑なので、さらに追加するかどうかを考えました。 サブデータベースとサブテーブルへのデータアクセスの実装には、一般的なフレームワークが使用されます。これは eBay のアーキテクチャにおける DAL に相当します。もちろん、この一般的なフレームワークは、テーブルが完成した後に作業を開始するまで待機する可能性もあります。同時に、この段階で以前のキャッシュ同期ソリューションでは問題が発生する可能性があります。データ量が多すぎるため、キャッシュをローカルに保存して、分散キャッシュを使用する必要があります。計画が立てられたため、さらなる調査と拷問の後、最終的に大量のデータ キャッシュが分散キャッシュに転送されました。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
サブテーブルもビジネス部門のようなもので、関連するテクノロジーは動的ハッシュになります。アルゴリズム、一貫性のあるハッシュ アルゴリズムなど。
DAL には、データベース接続管理 (タイムアウト、例外)、データベース操作制御 (タイムアウト、例外)、データベースとテーブルのシャーディング ルールのカプセル化など、多くの複雑なテクノロジが含まれます。
アーキテクチャ進化の 8 番目のステップ: Web サーバーを追加します
サブデータベースとテーブル サブデータベースの作業が完了した後、データベースへの負荷は比較的低いレベルに下がりました。再び毎日のアクセス数を監視し始めました。ある日突然、システムへのアクセスが再び遅くなり始めたことがわかりました。それは正常でした。その後、Web サーバーを確認したところ、Apache が多くのリクエストをブロックしており、各リクエストの数も比較的高速であることがわかりました。列に並んで待つ必要があり、応答速度が遅いため、一般的に、この時点ではある程度のお金があるので、ここに Web サーバーを追加します。課題:
1. Apache のソフト ロードまたは LVS ソフト ロードは、膨大な Web アクセス (要求された接続数、ネットワーク トラフィックなど) のスケジュールに耐えることができません。資金が許せば、解決策は購入することになります。 F5、Netsclar、Athelon などのハードウェア負荷。資金が許可されない場合、解決策は、アプリケーションを論理的に分類し、負荷クラスター内の別のソフトウェアに分散することです。
2.同期、ファイル共有、その他のソリューションにはボトルネックがあり、改善する必要があるかもしれません。おそらく、この時点で、Web サイトのビジネス ニーズを満たす分散ファイル システムが状況に応じて作成されるでしょう。 Web サイトのトラフィックが増加したとき、解決策は Web サーバーを継続的に追加することでした。
アーキテクチャ進化の第9ステップ: データの読み書きの分離と安価なストレージソリューション
ある日突然、この完璧な時代が終わりに近づいていることに気づき、データベースの悪夢が現れました。追加により、データベースとテーブルがデータベースとテーブルに分割されています。現時点では、データベースの読み取りと書き込みの比率が非常に高いことに気づくかもしれませんが、もちろん、データの読み取りと書き込みを分離するソリューションを実装するのは簡単ではありません。データベースに保存されたデータは無駄であるか、データベース リソースを過剰に消費するため、この段階で形成される可能性のあるアーキテクチャの進化は、データの読み取りと書き込みを分離し、BigTable などのより安価なストレージ ソリューションを作成することです。 。 このステップが完了した後のシステムの図を見てください:データの読み取りと書き込みの分離には、データベースのレプリケーション、スタンバイ、その他の戦略の深い理解と自己実装テクノロジも必要です。
安価なストレージ ソリューションには、OS ファイル ストレージの深い理解と理解が必要です。また、ファイルで使用される言語の実装を深く理解していることも必要です。
アーキテクチャ進化の第10ステップ: 大規模分散アプリケーションの時代と安価なサーバー群の夢の時代へ
上記の長くて苦痛なプロセスを経て、私たちはついに再び完璧な時代を迎えました継続的な増加により、Web サーバーはより高いアクセス数をサポートできるようになります。人気が高まるにつれて、さまざまな機能の需要も急激に増加し始めます。 Web サーバー上に元々デプロイされていた Web アプリケーションがすでに非常に大きく、複数のチームがそれに変更を加え始めたとき、それは非常に不便であり、基本的にどのチームも多かれ少なかれそれを繰り返す必要があることがわかりました。巨大なアプリケーションパッケージを N 台のマシンにコピーして起動するには時間がかかり、問題が発生したときの確認も容易ではないため、デプロイとメンテナンスも非常に面倒です。特定のアプリケーションのバグによりサイト全体が利用できなくなる可能性が非常に高く、チューニングが不十分であるなどの他の問題もあります (マシンにデプロイされたアプリケーションがすべてを行う必要があるため、基本的にターゲットを絞ったチューニングを実行することができません) ) などの分析に基づいて、システムを責任に応じて分割することを決定し始めたので、通常、このステップには時間がかかります。多くの課題:
1. 分散化した後は、高性能で安定した通信フレームワークを提供する必要があり、さまざまな通信およびリモート呼び出し方法をサポートする必要があります。
2. 巨大なアプリケーションを変換するには、長時間かかるため、ビジネス組織とシステムの依存関係の制御が必要です。
3. この巨大な分散アプリケーションの運用と保守の方法 (依存関係の管理、運用状況の管理、エラー追跡、チューニング、監視と警報など)。
このステップの後、システム アーキテクチャは比較的安定した段階に入ります。同時に、このアーキテクチャと学習した経験を組み合わせて、大量の訪問とデータをサポートするために多数の安価なマシンの使用を開始することもできます。増加するトラフィックをサポートするさまざまな方法が他にもあります。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
このステップには多くの知識システムが含まれており、通信、リモート通話、メッセージメカニズム、深く理解して習得するには、理論、ハードウェア レベル、オペレーティング システム レベル、および使用される言語の実装を明確に理解する必要があります。
運用と保守には、多くの場合、分散並列コンピューティング、レポート、監視テクノロジー、ルールと戦略などを習得する必要があります。
ウェブサイト全体のアーキテクチャの古典的な進化プロセスは、上記の比較と同様です。 もちろん、各ステップで実行される計画と進化の手順は異なる場合があります。さらに、Web サイトのビジネスが異なるため、専門的および技術的なニーズも異なります。もちろん、このブログでは、データベース クラスターやデータ マイニングなど、ここで言及されていないテクノロジーの進化プロセスについて詳しく説明します。 、検索などがありますが、実際の進化のプロセスでは、より多くのトラフィックをサポートするために、ハードウェア構成、ネットワーク環境のアップグレード、オペレーティング システムの変更、CDN ミラーリングなども使用されます。実際の開発プロセスでは、大規模な Web サイトでは、上記のことだけでなく、セキュリティ、運用と保守、運用、サービス、ストレージなども行う必要があります。この記事を書くのは実際には簡単ではありません。これは、大規模な Web サイト アーキテクチャの進化に関するさらなる紹介につながる可能性があります。:)追記: 最後に、LiveJournal アーキテクチャの進化に関する記事をいくつか紹介します:
LiveJournal のバックグラウンド開発から大規模な Web サイトのパフォーマンス最適化手法を検討する
http://blog.zhangjianfeng.com/article/743
またここから: http://www.danga.com/words/現在の LiveJournal Web サイトのアーキテクチャに関する詳細情報を見つけることができます。

データベースストレージセッションを使用することの主な利点には、持続性、スケーラビリティ、セキュリティが含まれます。 1。永続性:サーバーが再起動しても、セッションデータは変更されないままになります。 2。スケーラビリティ:分散システムに適用され、セッションデータが複数のサーバー間で同期されるようにします。 3。セキュリティ:データベースは、機密情報を保護するための暗号化されたストレージを提供します。

PHPでのカスタムセッション処理の実装は、SessionHandlerInterfaceインターフェイスを実装することで実行できます。具体的な手順には、次のものが含まれます。1)CussentsessionHandlerなどのSessionHandlerInterfaceを実装するクラスの作成。 2)セッションデータのライフサイクルとストレージ方法を定義するためのインターフェイス(オープン、クローズ、読み取り、書き込み、破壊、GCなど)の書き換え方法。 3)PHPスクリプトでカスタムセッションプロセッサを登録し、セッションを開始します。これにより、データをMySQLやRedisなどのメディアに保存して、パフォーマンス、セキュリティ、スケーラビリティを改善できます。

SessionIDは、ユーザーセッションのステータスを追跡するためにWebアプリケーションで使用されるメカニズムです。 1.ユーザーとサーバー間の複数のインタラクション中にユーザーのID情報を維持するために使用されるランダムに生成された文字列です。 2。サーバーは、ユーザーの複数のリクエストでこれらの要求を識別および関連付けるのに役立つCookieまたはURLパラメーターを介してクライアントに生成および送信します。 3.生成は通常、ランダムアルゴリズムを使用して、一意性と予測不可能性を確保します。 4.実際の開発では、Redisなどのメモリ内データベースを使用してセッションデータを保存してパフォーマンスとセキュリティを改善できます。

APIなどのステートレス環境でのセッションの管理は、JWTまたはCookieを使用して達成できます。 1。JWTは、無国籍とスケーラビリティに適していますが、ビッグデータに関してはサイズが大きいです。 2.cookiesはより伝統的で実装が簡単ですが、セキュリティを確保するために慎重に構成する必要があります。

セッション関連のXSS攻撃からアプリケーションを保護するには、次の測定が必要です。1。セッションCookieを保護するためにHTTPonlyとセキュアフラグを設定します。 2。すべてのユーザー入力のエクスポートコード。 3.コンテンツセキュリティポリシー(CSP)を実装して、スクリプトソースを制限します。これらのポリシーを通じて、セッション関連のXSS攻撃を効果的に保護し、ユーザーデータを確保できます。

PHPセッションのパフォーマンスを最適化する方法は次のとおりです。1。遅延セッション開始、2。データベースを使用してセッションを保存します。これらの戦略は、高い並行性環境でのアプリケーションの効率を大幅に改善できます。

thesession.gc_maxlifettinginttinginphpdethinesthelifsessessiondata、setinseconds.1)it'sconfiguredinphp.iniorviaini_set()。 2)AbalanceSneededToAvoidPerformanceIssues andunexpectedLogouts.3)php'sgarbagecollectionisisprobabilistic、影響を受けたBygc_probabi

PHPでは、session_name()関数を使用してセッション名を構成できます。特定の手順は次のとおりです。1。session_name()関数を使用して、session_name( "my_session")などのセッション名を設定します。 2。セッション名を設定した後、session_start()を呼び出してセッションを開始します。セッション名の構成は、複数のアプリケーション間のセッションデータの競合を回避し、セキュリティを強化することができますが、セッション名の一意性、セキュリティ、長さ、設定タイミングに注意してください。


ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

Video Face Swap
完全無料の AI 顔交換ツールを使用して、あらゆるビデオの顔を簡単に交換できます。

人気の記事

ホットツール

VSCode Windows 64 ビットのダウンロード
Microsoft によって発売された無料で強力な IDE エディター

ZendStudio 13.5.1 Mac
強力な PHP 統合開発環境

MantisBT
Mantis は、製品の欠陥追跡を支援するために設計された、導入が簡単な Web ベースの欠陥追跡ツールです。 PHP、MySQL、Web サーバーが必要です。デモおよびホスティング サービスをチェックしてください。

メモ帳++7.3.1
使いやすく無料のコードエディター

mPDF
mPDF は、UTF-8 でエンコードされた HTML から PDF ファイルを生成できる PHP ライブラリです。オリジナルの作者である Ian Back は、Web サイトから「オンザフライ」で PDF ファイルを出力し、さまざまな言語を処理するために mPDF を作成しました。 HTML2FPDF などのオリジナルのスクリプトよりも遅く、Unicode フォントを使用すると生成されるファイルが大きくなりますが、CSS スタイルなどをサポートし、多くの機能強化が施されています。 RTL (アラビア語とヘブライ語) や CJK (中国語、日本語、韓国語) を含むほぼすべての言語をサポートします。ネストされたブロックレベル要素 (P、DIV など) をサポートします。

ホットトピック









