1. 大規模 Web サイト アーキテクチャの進化
A. 大規模 Web サイト ソフトウェア システムの特徴
高い同時実行性、大規模トラフィック、高可用性、大量のデータ、広範囲に分散したユーザーと複雑なネットワーク条件、劣悪なセキュリティ環境、要件の急速な変化と頻繁なリリース、漸進的な開発、
B. 大規模なシステムの進化と開発プロセススケール Web サイト アーキテクチャ
1. 初期段階: 1 台のサーバー、LNMP
2. アプリケーション サービスとデータ サービスの分離: アプリケーション サーバー (CPU)、データベース サーバー (高速ディスク検索とデータ キャッシュ)、ファイル サーバー (大容量のハードディスク) ;
3. キャッシュを使用して Web サイトのパフォーマンスを向上させる: アプリケーション サーバーにキャッシュされたローカル キャッシュ (高速アクセス、アプリケーション サーバーのメモリによる制限、データ量の制限)、リモート分散キャッシュ (クラスタを使用して大容量メモリを展開) サーバーは専用のキャッシュ サーバーとして機能します)
4. アプリケーション サーバー クラスター: 負荷分散によるスケジューリング
5. データベースの読み取りと書き込みの分離
6. リバース プロキシと CDN アクセラレーションの使用 : CDN (最も近いネットワーク コンピューター ルームに展開)、リバース プロキシ (中央のコンピューター ルームに展開)
#7. 分散ファイル システムと分散データベースの使用システム8. NoSQL と検索エンジンを使用します9. 事業分割10. 分散サービスC. の値大規模 Web サイト アーキテクチャの進化
1 。大規模 Web サイト アーキテクチャ技術の核となる価値は、Web サイトのニーズに柔軟に対応することです。2。開発を推進する主力大規模 Web サイト技術の開発は Web サイトのビジネス開発です。#D.Web サイト アーキテクチャ設計の誤解#1. 大企業のソリューションに盲従する
2. テクノロジーのためのテクノロジー##3. あらゆる問題をテクノロジーで解決しようとする: テクノロジーはビジネス上の問題を解決するために使用され、ビジネス上の問題はビジネス手段によっても解決できます
#2. 大規模な Web サイト アーキテクチャ モデル
各モデルは、継続的に繰り返される問題と、その問題のソリューション コアを表します。こうすることで、作業を重複させることなく、ソリューションを何度も使用できます。パターンの鍵となるのは、パターンの再現性です。#A. Web サイト アーキテクチャ パターン
1. 階層化
階層化: エンタープライズ アプリケーション システムで最も一般的です。システムを水平方向にいくつかの部分に分割し、各部分が比較的単一の責任を担い、その後、下位層に対する上位層の依存と呼び出しを通じて完全なシステムを形成するアーキテクチャ パターン。
キャッシュとは、処理を高速化するために、計算に最も近い場所にデータを保存することです。
#キャッシュを使用するための 2 つの前提条件: 1 つ目は、データ アクセス ホットスポットのバランスが取れていないこと、2 つ目は、データが一定期間内に有効であること、
6. 非同期
ビジネス間のメッセージ受け渡しは同期呼び出しではなく、ビジネス操作が複数のステージに分割され、各ステージが共有されます。データは非同期で実行され、共同作業が行われます。
一般的な生産者/消費者モデルでは、生産者と消費者の間に直接の呼び出し関係はなく、システムの可用性を向上できることがこのモデルの特徴です。 、Web サイトの応答速度を向上させ、同時アクセスのピークを排除します。
非同期メソッドを使用してビジネスを処理すると、ユーザー エクスペリエンスとビジネス プロセスに影響を与える可能性があり、製品設計のサポートが必要になります。
7. 冗長性
サーバーがダウンしてもデータを失わずに Web サイトが引き続きサービスを提供できるようにするには、ある程度のサーバー冗長化運用とデータ冗長化バックアップが必要です。
小規模な Web サイトでもクラスターを構築するには少なくとも 2 台のサーバーが必要です。コールド バックアップを実現するための定期的なバックアップとストレージに加えて、データベースもマスターとサーバー間で共有する必要があります。スレーブ、リアルタイム同期、ホット バックアップ。
#大企業では、データ センター全体をバックアップし、ローカルの災害復旧センターと同期する場合があります。
8. 自動化
主にリリースの運用と保守に焦点を当てます。
リリース プロセスの自動化: 自動コード管理、自動テスト、自動セキュリティ検出、自動デプロイメント。
自動監視: 自動アラーム、自動フェイルオーバー、自動障害回復、自動機能低下、自動リソース割り当て。
9. セキュリティ
B. 新浪微博におけるアーキテクチャ パターンの適用
#3 、大規模 Web サイトの中核となるアーキテクチャ要素
アーキテクチャ: 最高レベルの計画であり、変更が難しい決定。
ソフトウェア アーキテクチャ: ソフトウェアの全体的な構造とコンポーネントの抽象的な説明。大規模なソフトウェア システムのあらゆる側面の設計をガイドするために使用されます。
#A. パフォーマンス
スケーラビリティとは、クラスタにサーバーを継続的に追加することで、同時ユーザー アクセスのプレッシャーの高まりとデータ ストレージへの需要の増大を緩和することを指します。新しいサーバーを追加した場合に、元のサーバーと同じサービスを提供できるかどうか。
測定基準: Web サイトにビジネス製品を追加したときに、それが達成できるかどうか既存の製品は透過的で影響がない、異なる製品間の結合がほとんどないかどうか、
4. 即時応答: Web サイト高-パフォーマンス アーキテクチャ
A. Web サイトのパフォーマンス テスト
1. さまざまな視点からの Web サイト
性能テストは、システムの性能指標、最大負荷容量、および最大圧力耐久性を取得するために、システムに継続的に負荷を加えるために実行されます。いわゆるアクセス圧力の増加とは、テスト プログラムに対する同時リクエストの数が継続的に増加することを意味します。
5. パフォーマンス最適化戦略
パフォーマンス分析: リクエスト処理の各リンクのログを確認し、どのリンクが応答時間が不当であるか、または期待を超えているかを分析します。監視データを確認してください。
B. Web フロントエンドのパフォーマンスの最適化
1. ブラウザ アクセスの最適化: http リクエストの削減 (CSS/JS/ のマージ)画像 )、ブラウザーのキャッシュを使用 (HTTP ヘッダーのキャッシュ制御と有効期限)、圧縮 (Gzip) を有効にし、CSS をページの上部に配置し、JS をページの下部に配置し、Cookie の送信を削減します
2 .CND アクセラレーション
3. リバース プロキシ: キャッシュ機能を設定することで Web リクエストを高速化します。 (実サーバーの保護や負荷分散機能の実装も可能)
#C. アプリケーションサーバーのパフォーマンスの最適化##1. 分散キャッシュ
#Web サイトのパフォーマンス最適化の第一法則: キャッシュの使用を優先してパフォーマンスを最適化する
1. データベースは主に 2 レベルのインデックスを持つ B ツリーを使用します。 、ツリーには最も多くのレベルがあり、3 つのフロアがあります。レコードを更新するには、5 回のディスク アクセスが必要になる場合があります。
2. 非常に多くの NoSQL 製品は、N 次マージ ツリーとみなせる LSM ツリーを使用しています。 3. RAID (安価なディスクの冗長アレイ)、RAID0、RAID1、RAID10、RAID5、RAID6 は、従来のリレーショナル データベースおよびファイル システムで広く使用されています。 4.HDFS (Hadoop 分散ファイル システム) は、MapReduce と連携してビッグ データを処理します。5. 確実: Web サイトの高可用性アーキテクチャ
A. Web サイトのユーザビリティの測定と評価
1 . Web サイトの可用性の測定
Web サイトが利用できない時間 (ダウンタイム時間) = 障害修復時点 - 障害発見 (レポート) 時点
#2. Web サイトのユーザビリティ評価
障害スコア: Web サイトの障害を分類および重み付けして、障害の責任を計算する方法を指します
障害スコア = 障害時間 (分) * 障害の重み
主な方法は、データとサービスの冗長バックアップとフェイルオーバーです。アプリケーション層とサービス層はクラスター負荷分散を使用して高可用性を実現し、データ層はデータ同期レプリケーションを使用して冗長バックアップを実現します。
C. 高可用性アプリケーション1. 負荷分散によるステートレス サービスのフェイルオーバー: アプリケーションのアクセスが非常に小さい場合でも、少なくとも 2 台のサーバーをデプロイする必要があります。負荷分散を使用すると、小さなクラスターが構築されます。 2. アプリケーション サーバー クラスターのセッション管理
セッション レプリケーション: サーバー間のセッション同期、小規模クラスター
#セッション バインディング: ソース アドレス ハッシュを使用して、同じ IP から発信されたリクエストを同じサーバーに分散します。これは高可用性に影響します。
#Cookie を使用してセッションを記録します。サイズ制限があり、各リクエストの応答を送信する必要があります。Cookie をオフにすると、アクセスできなくなります
D . 高可用性サービス
2. タイムアウト設定: アプリケーション内のサービス呼び出しのタイムアウト期間を設定します。タイムアウトが経過すると、通信フレームワークは例外をスローします。サービス スケジュール ポリシーに基づいて、アプリケーションは再試行を続行するか、サービスを転送するかを選択できます。他のサーバー上で同じサービスを提供するサーバーにリクエストを送信します。
アプリケーションは、サービスの失敗時にアプリケーションのリクエスト全体が失敗する状況を回避するために、メッセージ キューなどの非同期メソッドを通じてサービスへの呼び出しを完了します。
4. サービスの低下: サービスを拒否し、優先度の低いアプリケーションからの呼び出しを拒否するか、一部の要求呼び出しをランダムに拒否します。機能を閉じるか、一部の重要でないサービスを閉じるか、一部の重要でない機能を内部で閉じます。
5. 冪等設計: サービス層では、サービスを繰り返し呼び出しても 1 回呼び出した場合と同じ結果が得られることが保証されており、サービスは冪等です。
#E. 高可用性データ
1.CAP 原則
1. Web サイトrelease
2. 自動テスト: Selenium
ツールは、プレリリース サーバー上でプレリリース検証を実行します。まず、開発エンジニアが使用できるように、プレリリース マシンにリリースします。テストエンジニアです。構成、環境、データセンターなどは本番環境と同じである必要があります
4. コード管理: svn、git; トランク開発、ブランチリリース; ブランチ開発、トランクリリース (メインストリーム);
5. 自動リリース
#6. グレースケール リリース: クラスター サーバーをいくつかの部分に分割し、毎日一部のサーバーのみをリリースし、動作が安定していて障害がないことを確認します。期間中に問題が見つかった場合は、リリースされたサーバーの一部をロールバックするだけで済みます。ユーザーテスト(ABテスト)にもよく使われます。
G. Web サイトの動作監視1. 監視データの収集
Web サイトのいわゆるスケーラビリティとは、 Web サイトを変更する必要はありません ソフトウェアとハードウェアの設計により、導入されているサーバーの数を変更するだけで、Web サイトのサービス処理能力を拡張または縮小できます。
A. Web サイト アーキテクチャのスケーラビリティ設計
1. スケーリングを実現するためのさまざまな機能の物理的な分離: 垂直方向の分離 (階層化後の分離)、ビジネス処理プロセスの異なる部分を分離するシステムの拡張性を実現するための導入、水平分離(事業分割後の分離)、システムの拡張性を実現するための異なるビジネスモジュールの個別の導入。
2. 単一の機能はクラスター スケールを通じて拡張可能
B. アプリケーション サーバー クラスターのスケーラビリティ設計
1. アプリケーション サーバーは次のとおりである必要があります。シームレスなステートフルになるように設計されており、リクエストのコンテキスト情報は保存されません。
2. 負荷分散:
HTTP リダイレクト負荷分散: ユーザーの HTTP リクエストに基づいて実際の Web サーバー アドレスを計算し、ユーザーのサーバー アドレスに返されるサーバー アドレスを書き込みます。 HTTP リダイレクト応答内のブラウザ。このソリューションには利点もありますが、欠点としては、2 つのリクエストが必要であること、リダイレクト サーバー自体の処理能力が制限される可能性があること、さらに 302 ジャンプが SEO に影響を与える可能性があることです。
DNS ドメイン名解決の負荷分散: 異なる IP を指すように DNS サーバー上の複数の A レコードを構成すると、負荷分散作業が DNS に転送されるという利点があります。多くは地理的位置もサポートしており、最も近いサーバーを返します。欠点は、A レコードがキャッシュされる可能性があり、制御はドメイン ネーム サービス プロバイダーにあることです。
リフレクティブ プロキシ ロード バランシング: ブラウザによって要求されたアドレスはリバース プロキシ サーバーです。リバース プロキシ サーバーはリクエストを受信した後、負荷に基づいて実サーバーを計算します。バランシングアルゴリズム. 物理サーバーのアドレスを指定してリクエストを実サーバーに転送し、処理が完了するとレスポンスがリバースプロキシサーバーに返され、リバースプロキシサーバーはユーザーにレスポンスを返します。アプリケーション層 (HTTP 層) 負荷分散とも呼ばれます。その導入は簡単ですが、リバース プロキシのパフォーマンスがボトルネックになる可能性があります。
IP 負荷分散: ユーザー要求データ パケットが負荷分散サーバーに到達すると、負荷分散サーバーはオペレーティング システムのカーネル プロセスでネットワーク データ パケットを取得し、負荷分散アルゴリズムに基づいて実 Web サーバーにロード バランシング アルゴリズムを実行し、ユーザー プロセスによる処理を必要とせずに、データの宛先 IP アドレスを実サーバーに変更します。実サーバーの処理が完了すると、応答パケットは負荷分散サーバーに戻り、負荷分散サーバーはパケットの送信元アドレスを独自の IP アドレスに変更してユーザーのブラウザに送信します。
データリンク層の負荷分散: トライアングル送信モード。負荷分散サーバーのデータ分散プロセス中に IP アドレスは変更されず、宛先 MAC アドレスのみが変更されます。すべてのサーバーの仮想 IP を経由する アドレスは負荷分散サーバーの IP アドレスと一致します データ パケットの送信元アドレスと宛先アドレスは変更されません IP が一致しているため、応答データ パケットを直接返すことができますユーザーのブラウザ。ダイレクト ルーティング (DR) とも呼ばれます。製品LVS (Linux Virtual Server)を表します。
3. 負荷分散アルゴリズム:
ラウンド ロビン (RR): すべてのリクエストがプールされ、各アプリケーションに分散されます。サーバー
1. Memcached 分散キャッシュ クラスターのアクセス モデル# #KEY を介してルーティング アルゴリズム モジュールに入り、ルーティング アルゴリズムは、読み取りと書き込みのために Memcached サーバーを計算します。
2. Memcached 分散キャッシュ クラスターのスケーラビリティの課題単純なルーティング アルゴリズムは、キャッシュされたデータ KEY のハッシュ値をサーバーの数で割って、剰余ハッシュ法を使用することです。残りは対応するサーバー番号です。うまくスケールできません。 3. 分散キャッシュの一貫性のあるハッシュ アルゴリズム
まず、ノードに従って長さ 2 の 32 乗の整数リング (一貫性のあるハッシュ リング) を構築します。名前のハッシュ値により、キャッシュ サーバー ノードがこのハッシュ リングに配置されます。次に、キャッシュする必要があるデータの KEY 値に基づいてハッシュ値を計算し、ハッシュ リング上で時計回りに KEY のハッシュ値に最も近いキャッシュ サーバー ノードを検索して、KEY からキーへのハッシュ マッピングの検索を完了します。サーバ。D. データ ストレージ サーバー クラスターのスケーラビリティ設計
1. リレーショナル データベース クラスターのスケーラビリティ設計データ レプリケーション (マスター/スレーブ)、スプリットテーブル、データベース、データ シャーディング (Cobar)
2. NoSQL データベースのスケーラビリティ設計NoSQL はリレーショナル代数と SQL (Structured Query Language) に基づく正規化を放棄します データ モデルもトランザクションを保証しません一貫性 (ACID)。高可用性と拡張性が強化されました。 (Apache HBase)以上がmysql 大規模 Web サイトの技術アーキテクチャの中核となる原則は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。