php - トラフィックの多い Web サイトに推奨される構造

Question

私は非常に堅実なアーキテクチャを必要とする大きなウェブサイトを書き直しています。ここに私のいくつかの質問があります。リンゴとオレンジ、そしておそらくキウイも混ぜてしまったことを許してください:)私は多くの調査を行い、完全に混乱してしまいました.

主な質問: あらゆる面で成長が見込まれる大規模な Web サイトを構築するには、どのアプローチを採用しますか?

1. 単一のエントリ ポイント、データベース内のページ データ、GET 変数をデータベース エントリに関連付けることによって取得 (?pageid=whatever)

2. GET 変数 (?pageid=whatever would include anything.php) に基づいて含まれる、単一のエントリ ポイント、個別のファイル内のページ データ

3. MVC (わかりました、私は大賛成ですが、そこにあるすべてのチュートリアルとフレームワークをチェックする以外に概念を理解することはできません。データベースに「ビュー」を保存しますか?例から、1000 ページの同じものがある場合1つのモデルで形作ることができますが、それでも1000の「ビュー」ファイルが必要ですか?)

4. PAC - これは私にはさらに論理的に聞こえますが、あまりリソー​​スが見つかりませんでした。これが良い方法である場合は、本やリンクをお勧めできますか?

5. DAL/DAO/DDD - 質問を投稿する前にスタック オーバーフローを注意深く読んで、これらの用語について学びました。このリストに属しているかどうかわからない

6. 座って、自分のアーキテクチャを作成してください (ここで誰も教えてくれなければそうするでしょう:)

7. 言及されていないもの...

ありがとう。

Answer 1

Web サイトのスケーラビリティ/可用性 (iow.high-traffic) は、あなたが言及した項目のいずれによっても最もよく対処されます。特にポイント1と2。ページ定義をデータベースに保存することは絶対に禁止です。MVC やその他の同様のパターンは、スケーラビリティのためではなく、コードの明確さとメンテナンスのためのものです。

欠落している重要な情報は、予想される同時ヒット数/秒の種類です。トラフィックの多い Web サイトを構築したことがない人は、実際には「スケーラビリティの悪夢」を構成するヒット率に驚くことがあります。

スケーラブルなアーキテクチャを設計する方法に関する書籍があるため、SO の投稿ではトピックを正しく説明することはできませんが、いくつかの非常にトップレベルの概念を順不同で以下に示します。

• スケーラビリティは、ハードウェア ベースのソリューションを検討することによって最初に処理するのが最適です。SSD ディスクのアレイを備えた強力なサーバーは、長い道のりを歩むことができます。
• 静的にできるものはすべて静的にします。DB ではなく、Web サーバーから可能な限りサービスを提供します。たとえば、Web サイトの多くのページでは、ほとんどまたはまったく変更されないデータ ストアから、データベースからデータ リストを動的に生成します。
• あまり変更されない出力をキャッシュし、キャッシュの更新を調整します。
• 動的ページをステートレスまたは非同期に構築します。スケーリングを支持/促進するパターンについては、CQRS とイベント ソーシングを調べてください。
• クエリを調整します。DB は共有リソースであるため、通常は大きなボトルネックになります。多くの Web アプリ ビルダーは、不適切なクエリを作成する ORM を使用しています。
• データベース エンジンを調整します。バックアップ、レプリケーション、スイープ、ロギング、これらすべてに必要なリソースは、エンジンからほんのわずかです。それを調整することで、DB を高速化し、スケールアウトから時間を稼ぐことができます。
• クライアントからの HTTP 要求の数を減らします。各 HTTP 接続にはオーバーヘッドがあります。ページをチェックして、個々のリクエストの全体数を減らすために、各リクエストのペイロードを増やすことができるかどうかを確認してください。

この時点で、1 つのサーバーで動作を最適化したので、「スケールアウト」する必要があります。さて、物事は非常に急速に複雑になります。さまざまなタイプの負荷分散シナリオ (シャーディング、DNS ドリブン、ダム バランシングなど)、異なる DB での読み取りデータと書き込みデータの分離、Google Apps などの仮想化ソリューションへの移行、静的コンテンツの大きな CDN サービスへのオフロード、 Erlang や Scala などの言語とアプリの並列化など...

Answer 2

単一のエントリ ポイント、データベース内のページ データ、GET 変数をデータベース エントリに関連付けることによって取得 (?pageid=whatever)

メンテナンスの潜在的な悪夢。また、2 ～ 3 人以上のチームを持っている場合の開発にも使用できます。全員が遵守するための一連の厳格なルールを作成する必要があります。MVC を使用する場合、その労力ははるかに有効です。2も同様です。

MVC (わかりました、私は大賛成ですが、そこにあるすべてのチュートリアルとフレームワークをチェックする以外に概念を理解することはできません。データベースに「ビュー」を保存しますか?例から、1000 ページの同じものがある場合1つのモデルで形作ることができますが、それでも1000の「ビュー」ファイルが必要ですか?)

ページ レイアウトの数によって異なります。ほとんどの MVC フレームワークでは、構造化されたビュー (つまり、メイン ページ ビュー、サブビュー) を操作できます。ビューは、Web ページの HTML テンプレートと考えてください。必要なテンプレートとサブテンプレートの数は、まさにビューの数です。ほとんどの Web サイトでは、最大 50 のメイン ビューと最大 100 のサブビューを使用できると思いますが、それらは非常に大規模なサイトです。私が運営しているいくつかのサイトを見ると、合計で 50 回以上のビューがあります。

DAL/DAO/DDD - 質問を投稿する前にスタック オーバーフローを注意深く読んで、これらの用語について学びました。このリストに属しているかどうかわからない

します。メタビューやメタモデルが必要な場合は、DDD が最適です。たとえば、すべてのモデルの構造が非常に似ていて、使用するデータベース テーブルのみが異なり、ビューがほぼ 1:1 でモデルにマッピングされているとします。その場合は、DDD に適した時期です。良い例は、すべてのデータベース テーブルに対して個別の設計を必要としない ERP ソフトウェアです。統一された方法を使用してすべての CRUD 操作を実行できます。この場合、おそらく 1 つのモデルといくつかのビューで済むでしょう。これらはすべて、データベースの列、型、およびルールをプログラミング言語のロジックにマップするメタモデルを使用して、実行時に動的に生成されます。ただし、アプリケーションがハッキングされた MS Access プログラムのように見えないように、高品質の DDD エンジンを構築するには、ある程度の時間と労力がかかることに注意してください。

座って、自分のアーキテクチャを作成してください (ここで誰も教えてくれなければそうするでしょう:)

一般向けの Web サイトを構築している場合は、MVC を使用するとうまくいく可能性が高くなります。非常に良い出発点は、CodeIgniter ビデオ チュートリアルを見ることです。これは、MVC とは何か、またどの HOWTO やマニュアルよりも優れた使用方法を理解するのに役立ちました。そして、全部で 29 分しかかかりません。

http://codeigniter.com/tutorials/

楽しみ。

Answer 3

私は MVC のファンです。なぜなら、すべてに適切な場所があり、適切に区分化されていると、チームの規模を拡大しやすいからです。慣れるまで少し時間がかかりますが、それを処理する最も簡単な方法は、飛び込むことです。

そうは言っても、地元の図書館でスケーリングに関する O'Reilley の本があるかどうかを確認してください: http://oreilly.com/catalog/9780596102357は、始めるのに適した場所です。

Answer 4

「大きな」Web サイトを作成していて、MVC や Web フレームワークを完全に把握していない場合は、必要に応じてプラグインで拡張できるので、CMS の方が適している可能性があります。このルートを使用すると、プラットフォームよりもコンテンツとページ構造について心配することができます. 適切な CMS を選択する限り。

Answer 5

実際に使用されている Web mvc フレームワークのいくつかを使用してモック アプリを作成し、開発が十分にスムーズに行われたものを選択することをお勧めします。mvc の概念を理解し、Web に新しい機能を簡単に追加する準備ができている場合は、コードをしっかりと確立することが基本です。