10設計と大規模なWebサイトのアーキテクチャの生産は、問題を考慮する必要があります

.NET環境では、我々は問題のアーキテクチャの側面を見て、言語の実装が問題ではない、言語の利点は、実装ではなく、良いか悪いかに関係なく、任意の言語のあなたの選択の、アーキテクチャは、顔にする必要がありますです。

　　1. 膨大なデータの処理

我々はすべて知っているように、いくつかの比較的小さなサイトでは、データの量は非常に大きいではありませんが、選択し、更新は、我々が直面する問題を解決することができます、負荷自体は非常に大きくはない、せいぜいいくつかのより多くのインデックスを処理することができます追加します。大規模なサイトでは、毎日のデータ量は、貧しい人々の設計多対多の関係は、初期の段階では問題ありませんが、ユーザーの増加に伴い、データの量は幾何学的な成長される場合、数百万人かもしれません。この時点で我々は、選択と更新のテーブルのために（マルチテーブル共同クエリを言及しないように）コストは非常に高いです。

　　2. 強 データ並行性の取り扱い

ある時、2.0CTOが持つ帝王剣、それはキャッシングです。キャッシングでは、高コンカレンシー、高処理になると、やはり大きな問題になります。キャッシュはアプリケーション全体でグローバルに共有されていますが、変更を加える際に、2つ以上のリクエストが同時にキャッシュの更新を行った場合、アプリケーションは単純に死んでしまうのです。この時点で、優れたデータ並行性戦略とキャッシュ戦略が必要です。

さらに、普段はあまり感じないかもしれませんが、データベースのデッドロックの問題もあり、並行性が高い場合にはデッドロックの確率が非常に高く、ディスクキャッシングが大きな問題となります。

　　3. 強 ファイル保存の問題

ファイルのアップロードをサポートするいくつかの2.0サイトでは、ハードディスクの容量が増加していることに感謝しつつ、ファイルをどのように保存し、効率的にインデックスを作成すべきかをもっと考える必要があります。一般的な解決策は、ファイルを日付とタイプ別に保存することです。しかし、ファイルの量が膨大になると、ハードディスクに500Gものつまらないファイルを保存していると、帯域は十分でもディスクが対応できないことがあり、ディスクIoの維持・利用が大きな問題になる。この時、アップロードも絡むと、ディスクは簡単にオーバーしてしまう。

レイドや専用ストレージサーバーを使えば目の前の問題は解決するのかもしれませんが、どこにでもアクセスできるという問題もあります。サーバーが北京にあるとして、雲南や新彊のアクセススピードをどうするか。また、分散処理を行う場合、ファイルのインデックス付けやアーキテクチャをどのように計画すればよいのでしょうか。

ですから、ファイルストレージは非常に難しい問題であると認めざるを得ません。

　　4. データ関係の取り扱い

多対多の関係で満たされた第3のパラダイムに準拠したデータベースを計画し、INDENTIFY COLUMNをGUIDに置き換えることは容易にできる。 しかし、多対多の関係があふれる2.0時代には第3のパラダイムが真っ先に捨て去られることになる。複数テーブルの結合クエリは、効果的に最小化されなければならない。

　　5. {5. データ索引の問題

ご存知のように、インデックスは、データベース効率化クエリを改善するための最も安価で実装しやすいソリューションという側面を持っています。しかし、高いUPDATEの場合には、UPDATEとDELETEのコストが考えるには高すぎるでしょう、私はそれが焦点のインデックスを更新するときに完了するために10分かかる状況に遭遇した、その後、サイトのために、これらは基本的に耐えられないです。

インデックスと更新は天敵で、A,D,Eはアーキテクチャを考える上で考慮しなければならない問題であり、最も時間のかかる問題かもしれません。

　　6. 強 分散処理

2.0のウェブサイトは、その高いインタラクティブ性のために、CDNは基本的に0効果を達成し、コンテンツがリアルタイムで更新され、我々は日常的に対処している。どこでもアクセス速度を確保するために、我々は圧倒的な問題に直面する必要がありますどのように効果的にデータの同期と更新を達成するために、どこでもサーバー間のリアルタイム通信を実現するために考慮しなければならない問題がある。

　　7. Ajaxの長所と短所の分析

成功もAJAX、敗北もAJAXは、AJAXが主流の傾向となっている、突然XMLHTTPベースのポストと取得は非常に簡単であることを発見した。クライアントは、サーバーのデータを取得または投稿、サーバーは非常に正常なAJAXリクエストです戻り値の後にデータの要求を受け取った。しかし、AJAXの処理では、我々はパケットキャプチャツールを使用する場合は、データが返され、処理は一目瞭然です。いくつかの計算されたAJAXの要求のために、その後、我々はパケット送信機を構築することができ、それは、Webサーバを取り出すのは簡単です。

　　8. 強 データセキュリティの分析

HTTPプロトコルでは、パケットは平文で送信され、おそらく我々は、ああ、暗号化を使用することができると言うことができますが、Gの問題は、暗号化プロセスは、平文（我々はQQを知っているような、簡単に彼の暗号化を決定し、効果的に暗号化と彼のうち復号化の方法を書くことができる）可能性があります。あなたのサイトのトラフィックは、誰もあなたのことを気にしないが、あなたがアップトラフィックするときに非常に大きいではありませんが、その後、いわゆるプラグインは、いわゆるグループの髪は（QQグループの髪の初めから見える）発生します。おそらく我々は非常に意図的に我々はより高いレベルの判断または達成するためにさえHTTPSを使用することができると言うことができる、あなたがこれらの処理を行うときにデータベース、ioとCPUの膨大な量のコストを支払うことに注意してください。一部の大量配信では、基本的に不可能です。著者は、Baiduの空間とqqの空間のグループ投稿のために達成することができますされています。人々は挑戦することを望んでいる、それは実際には難しいことではありません。

　　9. 強 データの同期とクラスタの取り扱いの問題

データベースサーバーに負荷がかかると、データベースベースの負荷やクラスタリングが必要になります。そして、これが一番厄介な問題でしょう。データベースの設計にもよるが、データの遅延は恐ろしくて避けられない問題なので、遅延の数秒以内、あるいはもっと長い分単位で効果的なインタラクションを確保するための別の手段が必要だ。例えば、データのハッシュ化、セグメンテーション、コンテンツ処理、その他の問題などです。

　　10. 強 データ共有のためのチャネルとOPENAPIの動向

Openapiは必然的なトレンドとなっており、Google、Facebook、MyspaceからHainai Schoolまで、この問題を検討している、それは、ユーザーを保持し、より多くのユーザーの関心を刺激し、より多くの人々が最も効果的な開発を行うために役立つことができるようにするために効果的です。今回の効果的なデータ共有プラットフォーム、データのオープンプラットフォームが不可欠な方法となり、オープンインターフェイスの場合、データのセキュリティとパフォーマンスを確保するために、我々は真剣に考えなければならない問題である。