記事のディレクトリ
本稿では、「大規模なWebサイトの技術フレームワーク：コア・プリンシプルやケーススタディ、」から参照二本の章や他のオンラインの記事は、任意の漏れや間違いならば、私たちと尖ったを許します。ありがとうございます！
グッドデザインは模倣ではなく、丸暗記パターンに間違いはありませんが、創造性と革新性、でも「マイクロ革新」の問題を深く理解した上で、また、お馴染みの爽やかされます。コテージとイノベーションの最大の違いはありませんか、模倣するかどうかではなく、本当の問題やニーズを理解し、把握するかどうかの盗作。
- 「大規模なWebサイトの技術フレームワーク：コア・プリンシプルとケーススタディ」
1.定義モード
「各パターンは、私たちと、問題の周りの繰り返し発生の中核問題の解決策を説明しています。このように、あなたは繰り返しの作業を行うことなく、何度も何度もプログラムを使用することができます。」
キーは、パターンの再現性は、解決策をもたらすシーンモードの再現性に問題が再利用できることです。
そのようなフィールドのバックエンドの開発は非常に要約の使用の前の拡張性、信頼性、および容易さのためにプログラムを設計、ならびにこれらの古典的なデザイン・パターンのための多くの古典的なソフトウェアフレームワークの参照、およびでする方法であるとして23のデザインパターンこれは上の多くの技術革新を行いました。
技術を習得するために、同じことが（どのように？）現実的な問題を解決するための技術を使用する方法を知っていることが不可欠である、しかし、もっと重要な点は、どのように問題を解決するためにされて最終的に技術を理解することですが、その背後にある考え方は、どのようなモードが何である（なぜ？ ）、その後、独自の技術やビジネスを適用します。巨人のイノベーションの肩の上に立ちます。
II。一般的なアーキテクチャモデル
1.層別化
階層化は、さまざまな技術仕様によっては、そのようなコンピュータネットワークとして、思考の共通領域におけるコンピュータであり、7つの層に分けられ、上位レイヤサービスへの下から、上位層にのみに関係なく、同様に自分のことを行うことができます下部は、インタフェースの上層と下層との間のちょうど良い一致は、結合の程度を低減するのに十分であり、サービスを提供する方法です。
Java Webサービス開発プロセスのように、多くの場合、プロジェクト全体をすることができ、彼らは様々な問題を解決するためにあるように、レベル制御層、ビジネス層とデータ層との対話に分かれていることが必要です。このような論理は、コードの明確な、低依存効果を再生することができます
2.分割
スライスは、セグメンテーションのレベルを投影するように行うことができ、そしてセグメンテーション垂直セグメンテーションのためのプロジェクトとみなすことができます。
セグメンテーション等カート、ビジネス、商品管理サービス、ユーザー管理サービスを、お買い物、異なるビジネスホーム事業に分け、その後、別の開発チームによって可能なショッピングサイトとして、さまざまなビジネスラインとモジュールにプロジェクトを分割することを指します。
3.分散
この時点では、より多くのアプリケーションへのより多くの大規模な、同時アクセスがので、この場合には分散サービスがあった、多くの圧力ので、モノマーに耐えることができなかったため、要求を処理するためのマシンにすることはできません他のマシンの処理に配布。
分散システムは、一緒にコンポーズサービスを異なるホストの複数のリソースの提供を意味します。
一般的なプログラムは、いくつかの周りに分布しています：
1.分散アプリケーションとサービス：別々に配備複数の小さなアプリケーションまたはサービスへの大きなアプリケーション
2.分散静的リソース：静的リソースなどJS、CSS、画像やファイルなどのサイトや他の独立した展開
記憶された前記分散データ：データベースとアプリケーションの分離、個々の展開
4.分散コンピューティングは：例えば、単一の大規模な展開データ解析、機械学習や他のトレーニングセットのように、コンピューティングリソースとサービスの多くを取ります
分散システムの課題や問題発生は何ですか？
1.分散ホスト間のネットワーク接続の必要性は、ネットワーク分散型システムの状態が大きく影響かもしれません。ネットワークパーティション（パーティション）が発生したときにCAP理論によると、ホストデータ及び（Avaliable）サービスの可用性の間に分布の整合性（一貫性）は、唯一の保証することができます。それとも我々は一貫性、可用性など、または保証されていないことを保証することはできません。
異なるマシン上に分散サービスとリソースの2 A品種、機械のダウンタイムやデータ復旧サービスの消失しないための方法。
4.クラスタ
やると同様の分散するもののクラスタは、許容圧力の可用性を向上し、サービスへのアクセスを確保することである一方で、上記の異なるマシンにシステム、サービス分割の異なる役割分散;しかし、クラスタのための、クラスタ別のマシンには、同じサービスを提供しています。
例えばRedisのクラスタ2台のサーバーが、サーバーが提供する各サービスは、ロードバランシングアルゴリズムの必要性によって決定されるクライアント・サーバ・プロセスの特定の要求と同じであり、1台のマシンがダウンしているとき、まだありますマシンは、サービスを提供し続けることができます。
5.キャッシュ
キャッシュは、より迅速にアクセスを高速化するためにプットを介してデータにアクセスできるようにする場所です。
キャッシュは、次のカテゴリに分けることができます。
1.CDN：コンテンツ配信ネットワークは、ユーザーに最も近いサーバーに要求を転送し、直接アクセスリソースまですでに存在しているデータ、スピードを返すことができます。
2.リバースプロキシ：通常、プロキシサーバーのキャッシュの静的リソースのウェブサイトを逆（例えばnginxのような）は、アクセスを高速化することができます
3.ローカルキャッシュ：キャッシュ、ローカルサーバ上のローカルキャッシュデータやアプリケーションに存在する、技術のehcacheをを実装するために使用することができます
4.分散キャッシュ：多数の要求とキャッシュデータの多くの場合、より多くの一般的な方法は、Redisのクラスタなどの分散キャッシングサービス、などを使用することです
キャッシュを使用すると、2つの施設があります。
1.キャッシュ頻繁にアクセスされるデータはする必要がありますが、変更は非常に頻繁にホットデータではありません。
2.キャッシュされたデータは、一定の年齢を持っていますが、すぐに期限切れに、またはダーティリード現象を生じさせるべきではありません
前記非同期処理
大規模ウェブサイトアーキテクチャだけでなく、階層的セグメンテーションによって、性能を改善する方法をデカップリングと分散は、非同期処理を使用することができ、非同期処理は、異なるメッセージ・キュー・システムまたはマシン（例えば、カフカ、ActiveMQの）を構築するために主に、メッセージキューの両端間の通信は、以下のように、その主な役割は、プロデューサとコンシューマアプリケーションと呼ばれます。
店舗注文データへのメッセージ・キューを使用している場合、システムは、サーバーが突然ダウンし、その後、注文データが処理されないことが受注の多数が、失われ処理され、今回のようなシナリオを想像し、：システムの可用性を向上させるために1。システムがダウンした場合、その後、メッセージキュー、データが失われないように、機械、永続化機構を備えたメッセージキューを再起動しますが、消費者が支出し、システムの可用性を向上させる、処理することを継続することができる後。
2.サービスのレスポンスを高速化：データのプロデューサーを受け、全体のビジネスプロセスを待たずに応答を返すために、メッセージキューに配置が完了すると、メッセージは、実際の動作のための消費者にアクセスできるようになります。
ピーク時の同時アクセスの3撤廃：時々突然、通常のアクセスの上に現れたシステムは、システム容量よりも大きく、発生する可能性があり、ブロッキングまたはシステムは、他の操作を購入すると、ダウンしました。このとき、要求は消費者が個別に処理されるメッセージ・キューにキューイングすることができる、アプリケーションが過剰な負荷を持っていません。
7.冗長性
24時間を操作する必要があるため、サイトが、要求が大きすぎるか、または何らかの理由であることは、マシンにつながることができますダウンし、ダウンタイムのようなMySQLのケースが発生し、それは外のデータサービスを提供することはできません。
マシンがダウンし保証するために、システムはまだそれがすぐに他のマシンにサービスを提供し始めたマシンの後にハングアップすることができますように、そして、サービスの外に残っているデータの冗長性とバックアップのために練習することができます。
ので、任意の緊急時に、バックアップデータがあることを、Microsoftなど、地震やシステム障害によって引き起こされる自然災害の影響を防ぐために、深層水の数千人にサーバーにデータを分割します。
8.オートメーション
すべてのアプリケーションのために、最良の場合は完全に自動化されたスイッチングは、コードの自動、自動化された管理された後、例えば自動展開コードの更新のために、試験は試験、機械のダウンタイムを自動化され、エラー、アラームインターフェイスを自動化することができ、大きなオートメーションは現在、運用・保守の方向における最新の動向であるので、上のダウングレードを要求することができます。
9.セキュリティ
サイト等着陸など、そのシーンの安全性を確保する必要性、特に、そのようなので、上のXSS攻撃、DDoS攻撃、CSRF攻撃、SQLインジェクション攻撃ととしてハッカーの攻撃、より脆弱に大きいが、支払いのシナリオは、検証コード検証を導入する必要があります署名検証要求などが挙げられます。
