Mysql の大規模 Web サイトの技術アーキテクチャのコアケース分析

7. オンデマンド: Web サイトのスケーラブルなアーキテクチャ

拡張性 (Extensibility):既存のシステムへの影響を最小限に抑えたシステムを指します。機能を継続的に拡張または改善するため。これは、システムのアーキテクチャ設計レベルでの開閉原理であり、将来の機能拡張を考慮したアーキテクチャ設計を行うため、システムに新機能を追加する際に、既存システムの構造やコードを変更する必要がありません。

スケーラビリティ (スケーラビリティ): は、システム自体のリソースの規模を拡大 (縮小) することによって、システム自体のコンピューティングおよび処理能力を強化 (縮小) する能力を指します。

A. スケーラブルな Web サイト アーキテクチャを構築する

1. ソフトウェア アーキテクトの最大の価値は、高度なテクノロジーをどれだけ習得したかではなく、その能力にあります。大規模システムを複数の部分に分割する機能 システムを N 個の低結合サブモジュールに分割する機能 これらのサブモジュールには、水平ビジネス モジュールと垂直基本技術モジュールが含まれます。

2. 中心となるアイデアはモジュール化であり、これに基づいてモジュール間の結合が軽減され、モジュールの再利用性が向上します。

B. 分散メッセージ キューを使用してシステム結合を軽減する

1. イベント駆動型アーキテクチャ

• イベント駆動型アーキテクチャ(イベント駆動型アーキテクチャ): 低結合モジュール間でイベント メッセージを送信してモジュールの疎結合を維持し、イベント メッセージ通信の助けを借りてモジュール間の連携を完了することにより、分散メッセージ キューが一般的に使用されます。
  

• #メッセージ キューはパブリッシュ/サブスクライブ モデルを使用して動作します。メッセージ送信者がメッセージをパブリッシュし、1 つ以上のメッセージ受信者がメッセージをサブスクライブします。
  

2. 分散メッセージ キュー

• キューは先入れ先出し構造であり、アプリケーションは次のメッセージ キューにアクセスできます。リモート経由のインターフェイス 分散メッセージ キューを使用してメッセージ アクセス操作を実行し、分散非同期呼び出しを実現します。
  

• メッセージ プロデューサー アプリケーションは、リモート アクセス インターフェイスを介してメッセージ キュー サーバーにメッセージをプッシュします。メッセージ キュー サーバーは、メッセージをローカル メモリ キューに書き込み、すぐに成功メッセージを返します。メッセージプロデューサーへの応答。メッセージ キュー サーバーは、メッセージ サブスクリプション リストに基づいてメッセージをサブスクライブするメッセージ コンシューマ アプリケーションを検索し、先入れ先出しに従って、リモート通信インターフェイスを介してメッセージ キュー内のメッセージをメッセージ コンシューマ プログラムに送信します。 (FIFO) 原理。
  

• 分散メッセージ キューは非常に複雑になる場合があり、たとえば、ESB (エンタープライズ サービス バス) や SOA (サービス指向アーキテクチャ) をサポートしたり、非常に複雑なメッセージ キューをサポートしたりすることもできます。 MySQL レコードを使用するだけで簡単: メッセージ プロデューサー プログラムはメッセージをデータ レコードとしてデータベースに書き込み、メッセージ コンシューマー プログラムはデータベースにクエリを実行し、レコード書き込みタイムスタンプによってメッセージを並べ替えることにより、事実上の分散メッセージ キューを実現します。
  

C. 分散サービスを使用して再利用可能なビジネス プラットフォームを作成する

1. 分散サービスは、インターフェイスやさまざまなサブシステムを介してシステムの結合を分解します。 Desert Rose のインターフェース記述を通じてサービス呼び出しを行います。

2. Big Mac システムの問題: コンパイルとデプロイメントの難しさ、コードブランチ管理の難しさ、データベース接続の枯渇、新しいサービスの追加の難しさ;

3. 解決策

• 垂直分割: 大規模なアプリケーションを複数の小さなアプリケーションに分割
  

• 水平分割: 再利用されたビジネスを分割、分散サービスとして独立してデプロイ、新規企業はこれらの分散サービスを呼び出すだけでよく、特定のモジュール コードに依存する必要はありません
  

4. Web サービスとエンタープライズ レベルの分散サービス

欠点: 肥大化した登録および検出メカニズム、非効率的な XML シリアル化手段、比較的高いオーバーヘッドの HTTP リモート通信、複雑な展開およびメンテナンス手段;

5. 大規模な Web サイトの分散 分散サービスの要件と特性

負荷分散、フェイルオーバー、効率的なリモート通信、異種システムの統合、アプリケーションへの最小限の侵入、バージョン管理、リアルタイム監視

6. 分散サービス フレームワークの設計: Thrift、Dubbo

D . 拡張可能なデータ構造

NoSQL データベースで使用される ColumnFamily (カラムファミリー) を使用して設計されています。

#E. オープン プラットフォームを使用して Web サイトのエコシステムを構築する

1. オープン プラットフォームは、Web サイトの内部と外部の対話、および外部側のインターフェイスです。多数のサードパーティ開発者に対応する必要があるか、Web サイト内の多くのビジネス サービスに内部的に対応する必要があります。

2. アーキテクチャ: API インターフェイス、プロトコル変換、セキュリティ、監査、ルーティング、プロセス

8. 難攻不落: Web サイトのセキュリティ アーキテクチャ

A. Web サイト アプリケーションの攻撃と防御

1.XSS 攻撃

• 攻撃方法は、Web ページを改ざんしたり、悪意のある HTML スクリプトを挿入したり、ユーザーが Web を閲覧するときに悪意のある操作を実行するようにユーザーのブラウザを制御します。

  
  

#攻撃の 1 つのタイプはリフレクション型であり、攻撃者は悪意のあるスクリプトが埋め込まれたリンクをクリックするようにユーザーを誘導し、攻撃の目的を達成します

• 
  

もう 1 つのタイプの攻撃は永続的な XSS 攻撃です。ハッカーは悪意のあるスクリプトを含むリクエストを送信し、それを攻撃対象の Web サイトのデータベースに保存します。ユーザーが Web ページを閲覧すると、通常のページに悪意のあるスクリプトが含まれており、攻撃の目的を達成します。フォーラムやブログなどの Web アプリケーションでよく使用されます。
• #予防策には、危険な文字の駆除とフィルタリング、およびページ JS が HttpOnly 属性を持つ Cookie にアクセスすることを禁止することが含まれます

  ##2. インジェクション攻撃
  

SQL インジェクションと OS インジェクションに分けられます

• ##データベース構造を取得するための SQL インジェクション: オープンソース ソフトウェア プログラムの使用、エラー エコー、ブラインド インジェクション

  
  

• SQL インジェクション防止: 駆除、パラメータ バインド、プリコンパイル メソッドの使用、パラメータのバインド;

  
  

• 3. CSRF 攻撃

  
  

CSRF (Cross Site Request Forgery) は、攻撃者がクロスサイト リクエストを通じて正規のユーザーとして不正な操作を実行します。主な方法は、クロスサイト リクエストを使用してユーザーの知らないうちにユーザーの ID を使用したリクエストを偽造し、ブラウザーの Cookie またはサーバー セッション ポリシーを使用してユーザーの ID を盗むことです。

• 予防策: フォーム トークン、検証コード、リファラー チェック (HTTP リクエスト ヘッダーのリファラー フィールドに記録されているリクエスト ソースを確認します)

  
  

• 4. その他の攻撃の脆弱性

  
  

エラー コード: エラー エコー、HTML コメント、ファイル アップロード、パス トラバーサル

5. Web アプリケーション ファイアウォール: ModSecurity

• 6. Web サイトのセキュリティ脆弱性スキャン
  

B. 情報暗号化技術と鍵セキュリティ管理

1. 1. 1. -way ハッシュ暗号化: md5、sha など、salt を追加

2. 対称暗号化: DES アルゴリズム、RC アルゴリズムなど、暗号化に同じキーを使用

3. 非対称暗号化: RSA アルゴリズム

4. 鍵セキュリティ管理

鍵とアルゴリズムを独立したサーバーまたは専用のハードウェア デバイスに配置し、サービス コールを通じてデータの暗号化と復号を実現します。 。

復号アルゴリズムをアプリケーションシステムに、鍵を独立したサーバーに置き、実際の保管時には鍵をいくつかに分割し、暗号化して別の場所に保管します。ストレージメディアの重要なセキュリティを考慮しながらパフォーマンスが向上します。

• 
  

• C. 情報フィルタリングとスパム対策

  
  

  1. テキスト マッチング: 機密ワード フィルタリングの問題の解決

少量のコンテンツには通常の置換を使用してください

ワード数が多く、同時実行性が高い場合は、トライ ツリー アルゴリズムを使用します (ダブルarray Trie アルゴリズム)

• 
  

テキスト マッチング用のハッシュ テーブルの構築

• 
  

ノイズ リダクション処理を実行する必要がある場合があります。 、「Arab_Arab_ 」など。

• 
  

2。分類アルゴリズム: ベイジアン アルゴリズム、TAN アルゴリズム、ARCS アルゴリズム

• 3。ブラックリスト: ハッシュ テーブル、ブルーム フィルター
  

  #D. 電子商取引のリスク管理

##1. リスク: アカウントのリスク、購入者のリスク、販売者のリスク、取引のリスク

2. リスク管理

機械は、高リスクの取引と情報を自動的に識別し、手動レビューのためにリスク管理監査人に送信します。機械リスク管理の技術と方法は、発見された新しいリスクタイプによって常に徐々に改善されています。手動で。

ルール エンジン: トランザクションの特定の指標が特定の条件を満たす場合、不正行為のリスクが高いと見なされます。

• 
  #統計モデル: 分類アルゴリズムまたはより複雑な機械学習アルゴリズムを使用して、インテリジェントな統計を実行します。過去の取引における不正取引情報に基づいて分類アルゴリズムがトレーニングされ、収集および処理された取引情報が分類アルゴリズムに入力されて取引リスク スコアが取得されます。

• 
  

  9. タオバオのアーキテクチャ進化の事例分析

• 1.LAMP->JAVA/ORACLE->MySQL/NoSQL
  

  2. ビジネスはテクノロジーの継続的な進歩を推進します

10. Wikipedia の高性能アーキテクチャ設計分析

A.Wikipedia の Web サイトとしてアーキテクチャ全体:

LAMP オープン ソース製品、GeoDNS、LVS、Squid、Lighttpd、PHP、Memcached、Lucene、MySQL

B.Wikipedia パフォーマンス最適化戦略

1. フロントエンドのパフォーマンスの最適化

フロントエンド アーキテクチャの中核はリバース プロキシ サーバー Squid クラスターであり、LVS によって負荷分散され、リバース プロキシの前に CDN を通じて返されます。 。

Wikipedia CDN キャッシュ ガイドライン: コンテンツ ページには動的情報は含まれません。各コンテンツ ページには一意の REST スタイル URL があり、キャッシュ制御情報は HTML 応答ヘッダーに書き込まれます。

• 
  2. サーバー側のパフォーマンスの最適化: APC、Imagemagick、Tex を使用し、PHP の文字列検索関数 starter() をより最適化されたアルゴリズムに置き換えます

3. バックエンドのパフォーマンスの最適化:

• 
  キャッシュ

特に集中したホット スポットのデータは、アプリケーション サーバーのローカル メモリに直接キャッシュされます。

キャッシュされたデータの内容は、アプリケーション サーバーで直接使用できる形式である必要があります。

• 
  #キャッシュ サーバーを使用してセッション オブジェクトを保存する

• 
  データベースと比較すると、Memcached の永続接続は非常に安価です。必要に応じて作成してください

• 
  

  MySQL

• 
  

  より大きなサーバー メモリを使用します

通常のアクセスには RAID0 ディスク アレイを使用します

• 
  データベース トランザクションの整合性をより低いレベルに設定します。

• 
  Master データベースがダウンした場合は、アプリケーションをすぐに Salve に切り替えます。データベースを作成し、書き込みサービスをシャットダウンします

11. 大規模分散ストレージ システムである Doris の高可用性アーキテクチャ設計分析

データ ストレージ システムの場合、高可用性とは次のことを意味します。サービス、信頼性の高いデータ

A. 分散ストレージ システムの高可用性アーキテクチャ

1. 冗長性: サーバーのホット バックアップ、複数のデータ ストレージ

2. システム全体の部門:

• アプリケーション サーバー: ストレージ システムのクライアントがシステムへのデータ操作要求を開始します
  

• データストレージサーバー: ストレージシステムの中核であり、データを保存し、アプリケーションサーバーからのデータ操作要求に応答します。
  

• 管理センターサーバー: 2 台のマシンで構成されるメインマスター Aホット バックアップ小規模サーバー クラスターは、クラスター管理、データ ストレージ クラスターのヘルス ハートビート検出、クラスター拡張と障害回復管理、アプリケーション サーバーへのクラスター アドレス構成情報サービスの提供などを担当します。
  

#B. さまざまな障害状況における高可用性ソリューション

1. 分散ストレージ システムの障害分類: 瞬間障害、一時障害、永続障害

2一時的な障害の解決: 複数の再試行

3. 一時的な障害の解決: 手動介入が必要、問題のあるサーバーは一時ストレージ サーバーを使用します

4. 永続的な障害の解決: バックアップ サーバーの交換を有効にする 永続的に無効サーバー

12. オンラインショッピングフラッシュセールシステムアーキテクチャ設計事例分析

A. フラッシュセール活動の技術的課題:既存ウェブサイトビジネスへ影響、同時実行性の高いアプリケーション、データベースの負荷、ネットワークとサーバーの帯域幅の突然の増加、直接注文

##B. フラッシュ セール システムの対応戦略

##フラッシュ セール システムの独立展開

• 
  静的フラッシュ セール製品ページ

• 
  フラッシュ セール用のネットワーク帯域幅のレンタルアクティビティ

• 
  ランダムな注文ページの URL を動的に生成する

• 
  

  C. フラッシュ セール システム アーキテクチャの設計

1. フラッシュセール商品ページの購入ボタンの点灯を制御する方法: JS ファイルを使用する、冒頭の内容を変更する、毎回リクエストする、CDN にキャッシュされないなど、ランダムなバージョン番号を使用します。 2. 最初に送信された注文のみが注文サブシステムに送信されるようにする方法: 注文ページへの入り口を制御して、少数のユーザーのみが入力でき、他のユーザーはフラッシュ セール終了に直接アクセスできるようにします。ページ。たとえば、サーバーが 10 台あり、それぞれが 10 個のリクエストを処理します。リクエストの数が 10 を超えると、他のサーバーはエラーを返し、グローバル キャッシュ レコードをリクエストします。最初のサーバーであれば、注文ページに入り、他のものは失敗を返します。

##13. 大規模 Web サイトの典型的な障害ケースの分析

##A. ログの書き込みも障害の原因となる可能性があります

#アプリケーション独自のログ出力構成とサードパーティ コンポーネントのログ出力は、個別に構成する必要があります

ログ構成ファイルを確認して、ログを操作してみましょう。 Michelle は、少なくとも警告を考慮しています

• 
  

一部のサードパーティ コンポーネントが出力する可能性のある多すぎるエラー ログをオフにする必要があります

• 
  

• #B. データベースへの同時アクセスによって発生する高レベルの障害

  
  

ホームページはデータベースにアクセスすべきではありません

ホームページは静的である必要があります

• 
  

• C. 同時実行性が高い条件下でのロックによって引き起こされる障害

  
  

  ロック操作を使用する場合は注意してください

D. 原因となるキャッシュ障害

キャッシュ サーバーはすでに Web サイト アーキテクチャの不可欠な部分であり、データベースと同じレベルで管理する必要があります

E. 非同期のアプリケーション起動によって引き起こされる障害

F. 大きなファイルの排他的なディスク読み取りおよび書き込みによって引き起こされる障害

小さなファイルと大きなファイルのストレージを共有しないでください。

G .本番環境の悪用による障害

本番環境にアクセスするときは特に注意してください。専任の DBA にデータベースを保守してもらいます。

H.標準以外のプロセスが原因で発生する障害

diff コマンドを使用して、コードを送信する前にコードを比較し、コードがないことを確認します。提出すべきではないものは提出されます。コード レビューを強化し、提出前に少なくとも 1 人の他のエンジニアにコード レビューを実施させ、コードによって引き起こされた障害の責任を共有します

I. 不適切なプログラミングによって引き起こされる障害習慣

#空のオブジェクトや null 値などの処理に注意してください。

##14. アーキテクト リーダーシップの芸術

##A. 製品ではなく人に焦点を当てる

1. 好きなことをやっている優秀な人々のグループは間違いなく成功を収めます

2. 最良のソフトウェア管理は、プロジェクトチームの各メンバーの優れた可能性

#3. 共に努力する価値のある目標を見つけ、全員が自己価値を最大限に発揮できる仕事を創造します。人の卓越性

1. 人が物を作るのではなく、物が人を作る

2. 私たち自身を含むほとんどの人は、私たちが思っているよりも優れています。いくつかの卓越性が必要です。何か挑戦的なことをする、より優れた人々と協力する、自分自身を超える勇気を持つなど、適切な環境で刺激を受ける

3. 優秀な人材を発見することは、優れた人材を発見することよりもはるかに有意義です

##C. 美しいブループリントの共有

#1. ブループリントには、製品が行うべきこと、すべきではないこと、および製品が達成すべきビジネス目標を明確に記載する必要があります

2. ブループリントは視覚的なものでなければなりません: 製品がユーザーにどのような価値を生み出すことができるか、どのような市場目標を達成できるか、そして製品は最終的にどのようなものになるでしょうか?

3. ブループリントは次のようにする必要があります。シンプル: 一文で理解: 私たちは何をしているのですか?

4. アーキテクトは目標の青写真に焦点を当て続け、青写真から逸脱する設計や決定に注意を払う必要があります。誤った逸脱は適時に修正する必要があります。必要な変更は全員で議論し、全員の承認を得る必要があります。

D. アーキテクチャに共同で参加する

1. アーキテクチャを所有する唯一のアーキテクトにならないでください

2. 他の人にアーキテクチャのメンテナンスを任せてくださいフレームワークとアーキテクチャのドキュメント

E. 妥協することを学ぶ

アーキテクチャおよび技術ソリューションに対する意見は、基本的に、これらのソリューションに注意を払い、理解して受け入れようとしています。アーキテクトは過敏になりすぎず、意見を率直に共有し、相違点を留保しながら共通点を模索する必要があります。

2. 技術的な詳細に関する議論は、議論を続けるのではなく、すぐに検証されるべきです。

3.アーキテクチャについて議論しているのではありません。明確にしてください。アーキテクチャはプロジェクト、システム、開発者に統合されています。アーキテクトが忘れられるのが早ければ早いほど、アーキテクチャはより成功します。

F. 他者を達成する

1. 私たちの仕事は製品を作るだけではなく、人、そして最終的には私たち自身を実現することです。

2. プロジェクトを完了するには、顧客のための価値を創造し、利益を生み出すだけでなく、

3. チームの技術リーダーとして、アーキテクトはプロジェクト プロセス中に何もコントロールしようとすべきではなく、柔軟な計画と青写真を持ってチームを進めます。

#15. ウェブサイト アーキテクト キャリア ガイド

• #ソフトウェア開発の目的は現実世界の問題を解決することですが、多くの場合、人々は本当の問題が何なのかを知りません。
  

• ソフトウェア開発プロセスでは、多くの問題が発生します。最大限のサポートを得るには、すべての関係者の利益を調整する必要があります。顧客とのバランスをとる必要があります。ニーズ、ソフトウェア出力、開発リソース間の関係により、ソフトウェア設計の元の青写真を実現するには多くのことを行う必要があります。
  

#A. 問題を発見し、突破口を見つける

期待に応えられないとき、人々は何かが間違っていると感じます。問題は経験と期待との間のギャップです。問題を解決するには 2 つの方法があります。エクスペリエンスを向上させるか、期待値を下げることです。期待値を下げるだけでは問題は解決しませんが、逆に期待値と実際の経験との違いに直面することで問題を特定し、突破口を見つけることができます。

2. 新入社員が最初に行う必要があるのは、チームに溶け込むことです。

3. 新入社員が最後に行う必要があるのは、自分の能力を証明することです。

B. 質問してサポートを求める

1. 問題が見つかりました。必要に応じて、それは問題発見者の問題であり、問​​題所有者の問題ではありません。問題を解決するには、問題を提起し、問題の所有者に問題の存在を知らせる必要があります。

2. 質問を提起するためのヒント:

• 「私の問題」を「私たちの問題」として表現します

  
  

• 上司に限定形式の質問をし（上司がどちらが良いかを選択できるように AB の選択肢を与える）、部下には自由形式の質問をする

  
  

#次の点を指摘します。相手を批判するのではなく問題を解決する

• 
  

同意の得られる方法で質問する

• 
  

#3. いわゆる率直な態度「言いたいことを直接言わなければならない」という意味ですので、ご理解いただき、堂々巡りではなく、表現方法に気を付け、当事者の気持ちを考慮してください。 C. 問題を解決してパフォーマンスを達成する

1. 私の問題を解決してください 問題を解決する前に、まず自分の問題を解決してください

他の人が問題を解決できるように支援する場合は、問題があれば、他の人もあなたの問題解決を手伝ってくれるでしょう

• 他の人が問題を解決するのを手助けする過程で、私は次の状況に精通しました
  

• あなたは自分の解決策を使って他の人の問題を解決しており、この解決策はあなたの管理下にあります
  

• 2. 問題から適切に回避する
  

16. 中国語ウェブサイトアーキテクト

A. 機能別アーキテクト

デザインアーキテクト、消防アーキテクト、エバンジェリストアーキテクト、ギークアーキテクト

B. アーキテクトを効果によって分ける

シェルパ アーキテクト: 通常、プロジェクト内で技術的に最も難しく挑戦的なモジュールを開発します。スパルタ アーキテクト、高名なアーキテクト

C. 報道部門の責任と役割 アーキテクト

プロダクト アーキテクト: 製品のライフサイクル全体に参加し、基本サービス アーキテクト (プラットフォーム アーキテクト)、インフラストラクチャ アーキテクト

#D .関心のレベルによってアーキテクトを分ける

機能のみに焦点を当てるアーキテクト、非機能に焦点を当てるアーキテクト、チームの組織と管理に焦点を当てるアーキテクト、製品の運用に焦点を当てるアーキテクト、アーキテクト

E. アーキテクトを口コミで分ける

最高のアーキテクト、優れたアーキテクト、平均的なアーキテクト、下手な建築家と最悪の建築家

#F. 建築家を分ける非主流の方法#普通の建築家、文芸建築家、1 1 建築家

付録 A: 大規模 Web サイト テクノロジーの概要

A. フロントエンド アーキテクチャ

ブラウザ最適化テクノロジー、CDN、静的および動的分離、静的リソース、イメージ サービス、リフレクション プロキシ、DNS

B. アプリケーション層アーキテクチャ

の独立したデプロイメント

開発フレームワーク、ページ レンダリング、負荷分散、セッション管理、動的なページの静的化、ビジネス分割、仮想化サーバー

C. サービス層アーキテクチャ

分散メッセージング、分散サービス、分散キャッシュ、分散構成

D. ストレージ層アーキテクチャ

分散ファイル、リレーショナル データベース、NoSQL データベース、データ同期

E. バックエンド アーキテクチャ

検索エンジン、データ ウェアハウス、レコメンデーション システム

F. データ収集 (ログ) と監視

ブラウザデータ収集、サーバー業務収集、サーバーパフォーマンスデータ収集、システム監視、システムアラーム

G. セキュリティアーキテクチャ

Web攻撃、データ保護

H. データセンターのコンピュータ ルームのアーキテクチャ

コンピュータ ルーム、キャビネット、サーバー

以上がMysql の大規模 Web サイトの技術アーキテクチャのコアケース分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。