Mysql の大規模 Web サイトの技術アーキテクチャのコアケース分析-mysql チュートリアル-php.cn

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 を閲覧するときに悪意のある操作を実行するようにユーザーのブラウザを制御します。
#予防策には、危険な文字の駆除とフィルタリング、およびページ JS が HttpOnly 属性を持つ Cookie にアクセスすることを禁止することが含まれます
##2. インジェクション攻撃

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

##データベース構造を取得するための SQL インジェクション: オープンソースソフトウェアプログラムの使用、エラーエコー、ブラインドインジェクション
SQL インジェクション防止: 駆除、パラメータバインド、プリコンパイルメソッドの使用、パラメータのバインド;
3. CSRF 攻撃

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

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

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

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

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

4. 鍵セキュリティ管理

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

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

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

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

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() をより最適化されたアルゴリズムに置き換えます
キャッシュ

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

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

#キャッシュサーバーを使用してセッションオブジェクトを保存する
データベースと比較すると、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. ログの書き込みも障害の原因となる可能性があります

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

#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 サイトの他の関連記事を参照してください。