1大規模なサイトシステムの望ましい特性
1.1 高并发、大流量
高並行性、高流量：高ユーザーの同時実行性に直面する必要性、高流量のアクセス。
例えば、ドバイのチケットに200機があるが、人々は、この1つはチケットのリアルタイム更新を見ることができる作るチケットを購入し、滑らかにするためにどのようにチケットを100ワット、100ワットを購入するシステムに圧迫されている、ありますウェブサイトの建築家が問題を考慮する必要があります。これはおそらく、1分の量「二から一一は」淘宝網の千ワットは、無視できる数字であるためのユニーク訪問者ですが、サイトの評判とユーザーエクスペリエンスのために、それは小さな挑戦ではありません。
1.2 高可用
高可用性：高並行処理は、いくつかの点で、彼は何の理由がダウンしていたではない、パラメータがより定期的に持っている、高可用性、7 * 24は、すべてのサイトの夢ですが、あなたは知らない、相対的です。
1.3 海量数据
大規模なデータ：保存するには、膨大な量のデータを管理するには、多数のサーバーを使用する必要があります。大規模なストレージ・サーバをサポートしていませんでし千万近くのFacebookの毎週の写真は、ユーザーが量が急上昇されなかったであろうと信じています。
1.4 用户分布广泛，网络情况复杂
ユーザーが広く、分散型ネットワークの複雑さ：多くの大規模なインターネットサービスを世界中のユーザーに提供され、利用者の分布の広い範囲は、ネットワークの状態を中心に広く異なります。相互運用性のさまざまな演算子の間で、データ接続、および各国そう。
1.5 安全环境恶劣
悪いのセキュリティ環境：インターネットのオープンな性質に起因して、様々な地方のカード情報が盗まれ、他のイベントが共通しているさを含め、攻撃にインターネットがより脆弱になって。
1.6 渐进式发展
プログレッシブ開発：ほとんどすべての主要なインターネットサイトの漸進的な、優れたインターネット製品が徐々に出て動作している開発スモールスタートからサイトが、あります。
2サイトアーキテクチャの進化
2.1 传统架构
伝統的なプロジェクトでは、3層アーキテクチャ、ビジネスロジック層、データベースアクセス層、プロジェクトに配置された制御層、またはSSMはSSH技術を使用してに分かれています。
長所：大規模な開発チームに適していない個人や小規模な開発チーム、に適しています。
2.2 分布式架构
Nサブシステムへのビジネスニーズ分割によると、複数のサブシステムは、リモートRPCサブシステムのビジネス・プロセスを使用した通信技術の間の通信を完了するために協働します。
利点：
- 分割されたモジュール、モジュール間の結合を低減するために、インタフェースを使用して通信を行います。
- いくつかのサブプロジェクト、別のサブプロジェクトを担当する別のチームにプロジェクトを分割するには。
- ただ、機能性を高め、サブプロジェクトを追加し、他のシステムのインタフェースが可能呼び出す必要があります。
- 分散配置の柔軟性。
長所短所がありますが、以下のように、欠点は以下のとおりです。
- システム間の相互作用は、遠隔通信の使用を必要とする、インターフェイスの開発は、作業負荷を増加させました。
- 各モジュールは、いくつかの一般的なビジネス・ロジックを共有することはできませんがあります。
上記の欠点分散アーキテクチャを解決するために、我々は、SOAアーキテクチャを導入している、SOA：サービス指向アーキテクチャサービスのアーキテクチャを指向します。プロジェクトは、サービス層、プレゼンテーション層2つのプロジェクトに分割されます。サービス層は、ビジネスロジックが含まれている、あなただけのサービスを提供する必要があります。相互作用は、ビジネスロジックとプレゼンテーション層のみを達成するために、すべてのページのコールサービス層を処理する必要があります。
2.3 SOA架构
SOAは、別のサービスにカプセル化ソフトウェアアーキテクチャモデル、抽出された共通のビジネス・ロジック、です。
各コンポーネントは独立して、離散、自律、再利用可能なサービス機能を提供できるように、ビジネスシステムは、いくつかの成分に分解された
トップクラスのビジネス・プロセスのオーケストレーションとサービスの組み合わせによって達成すること。
役割：簡素化、メンテナンスおよび全体的なリスク、拡張性と柔軟性を減らします。
2.4 微服务架构
マイクロサービスは、単一の小さなが、ビジネスサービスの開発を指し、各サービスは、独自の処理や光の通信メカニズムは、プロの人々が、プロのことを行うようにすることを、単一のサーバー上に展開することができました。
マイクロサービスSOA、より軽量と比較すると。
2.5 SOAサービスとマイクロアーキテクチャの違い
エンタープライズクラスのアーキテクチャの主OA、ESBサービス（ESBエンタープライズ・サービス・バス）を使用して、非常に重いは、XMLトランスポート・フォーマットでシリアル化と逆シリアル化を必要とします。
マイクロアーキテクチャの主要なインターネットサービス会社、軽量、コンパクト、スタンドアローンは、http +休憩+ JSON形式ベースのトランスポート。
ESBは、ミドルウェア技術とXMLの伝統的なWebサービスやその他の技術が互いの製品と組み合わせるということができます。
- マイクロサービスでは、異なるSOAと、サービスは、簡単に通常のサービスと専門的なことを行うには、プロの人々のための独立したサービスの拡大、新製品の迅速な反復の新しいバージョンを展開すること、独立して、他のサービスと展開の操作が可能。
- SOAデータストレージを共有することができるサービス、およびマイクロサービスの各サービスは、個別のデータストレージを有します。
- SOAサービスとマイクロ主な違いは、大きさと範囲で、SOAは、通信のHttp + JSON形式を使用して、アイデア、サービス指向アーキテクチャー・システム、マイクロ・サービス継承SOAの利点は、伝統的なメッセージバスのESB除去され、より軽量。
3つの高い同時設計の原則
システム設計だけでなく、考えるビジネス機能を実現するだけでなく、高い同時実行のシステム、高可用性、高信頼性などがあることを確認するためにする必要があります。アカウントにも、システム容量（などの流量、容量を）取ると、SLAは（スループット、レスポンスタイム、可用性、ダウングレードなど）、アラーム監視（などマシンの負荷、応答時間、可用性、）、危機管理計画（災害復旧を、指定されました）低下、制限、分離、切断フロー、ロールバック、等。
- キャッシュ
- 非同期同時
- 接続プーリング
- スレッドプール
- 拡張
- メッセージキュー
- 分散型ミッション
3.1分割システム
システムは、第1の機能モジュールアーキテクチャ設計、それはまだモジュールによっていくつかのルールである必要があり、大きな戦争パッケージのリリース管理を使用してMVCシステムに直接垂直に行われますとき私たちはゼロから新しいシステムを作ります分割、またはマイクロ設計されたSOAサービス・システムより良いですか？私はこのプロジェクトは一種のプロジェクトの人的・物的条件とサポートの量ユーザーの数と取引量の基礎を必要とした内容に基づいて必要があると信じています。良いシステムは、基本的なコアのオンライン版の後に、現在のニーズを満たし、問題を解決し、将来のための制御およびスケジュールのリスク、予測と計画を達成するために、過剰設計を避けるようにするために設計され、その後、反復して改善を継続する必要があります。
今日は行動SOA、マイクロサービスアーキテクチャ設計モジュール分割のいくつかの寸法と原則について話しています。
- システム寸法：システムの機能に応じて、事業を分割し、そのようなクーポン、など、カート、請求書、注文システムを買い物に。
- 機能寸法：システムの機能は、粒度の細かい分割、クーポンを行っているが、クーポンシステムは、チケットシステム、チケット発行システムをリードし、バックオフィスシステムに分割されています。
- 読み取りおよび書き込み寸法：例えば商品システムとしてクエリのより大きい量は、それぞれ、二つの別々のサービスに分割し、書込みサービス照会することができれば、
書き込み特性は比分割、読み取り複数、マルチレベル・キャッシュを考慮し、ライトより、サブライブラリーのサブテーブルと考えることができます。 - AOPの寸法は：アクセス特性に応じて、そのような製品詳細ページとしてAOP分割に従ってCDN、ページ・レンダリング・システムに分けることができ、CDNシステムのAOPであります
- モジュール寸法：除算のWebサービス、コードの全体的な構造上のDAO
3.2サービス
分散システムでは、ビジネス・ロジックへのインタフェースは、他のシステムコールにさらされる、フォームにカプセル化し、これは、サービスと呼ばれるインタフェースとして解釈することができます。
より多くのサービスとして、彼らがガバナンスのサービスを使用する必要があります、それはダボ、SpringCloudサービスガバナンスのフレームワークを使用します。
-深さでダボとSpringCloudでフォローアップを詳細に言及しました。
進化のサービス：インプロセスサービス-スタンドアロンのリモートサービス-自動登録と発見サービス- -パケットサービス、検疫、ルート-サービスガバナンスのクラスタサービスを手動で登録します。
サービスグループ、分離、電流制限、ブラックリストとホワイトリスト、タイムアウト、再試行メカニズム、ルーティング、障害補償を検討
実践：負荷分散、ZooKeeperの、領事及びその他の自動登録と発見サービスは、nginxの、HaProxy、LVSなどを使用しています。
3.3メッセージキュー
ミドルウェアは、ミドルウェアが生産した後にメッセージを送信し、通信をポイントに分けて、パブリッシュ・サブスクライブされたメッセージング、クライアントとサーバの非同期通信フレームワークであるメッセージング、消費者がメッセージを送信するプロデューサーを受け入れる非同期を待つ必要はないかもしれません。
電気供給システムにおける非同期メッセージキュープッシュメッセージ、リトライ冪等注意メッセージの失敗の問題を使用します。
問題の冪等のソリューション、永続的なグローバルID +ログレコードの使用。
3.4キャッシュ
- ブラウザのキャッシュ
- APPのクライアントキャッシュ
- CDN（コンテンツデリバリーネットワーク）キャッシュ
- キャッシュアクセス層
- アプリケーション層のキャッシュ
- 分散キャッシュ
データや異常なデータはすべての詳細を明らかにするために、あなたはそれ以外のユーザーは非常に長い時間では、これらのデータが表示され、キャッシュに許されるべきではありません。
同時の3.5
パラレル変化にシリアル。
4つの高可用性設計の原則
ロード・バランシングとリバースプロキシを介して分流さを達成。
保護サービスを制限することにより雪崩災害から。
ダウングレードを介して利用可能に不利益サービスに、いくつかを達成します。
分離によって分離フォールト。
タイムアウトと再試行メカニズムによって回避の蓄積に合理的な要求を設定雪崩を引き起こしました。
バージョンロールバック機構によるクイックフィックス・エラー。
4.1ダウングレード
：高可用性サービスの場合、スイッチの設計に切り替えることをダウングレード、ダウングレード、主に以下の考え方に基づいて設計することが重要である
各アプリケーションにプッシュスイッチ機構を押してください。1.スイッチを集中管理。
マルチレベル読み込む2.サービスのダウングレード：サービスコールのローカルキャッシュは、読み取り専用読み取り専用の分散キャッシュをするために格下げなど、デフォルトでは読み取り専用のデータは、（デフォルトでは、このような在庫の在庫状況など）格下げ。
3.前のスイッチ：アーキテクチャはNginx-> Tomcatの、スイッチが要求またはソースへのアプリケーション・フロー・バックのほんの後端部のソースにnginxの層流バックに切り替えるように、nginxのアクセス層に付加することができるされています。
4.ビジネスのダウングレード：高同時着信トラフィック、電源は、大規模な受注を促進するためのコア要件を支払うために、そして最終的にデータの整合性を確保するように設計する際、ユーザーのシステムを保護します。だから我々は、非同期呼び出しにいくつかの同期呼び出しを置くシステムが利用可能であることを確認するために、システムに優先度の高いデータや特殊な特性、流れの合理的な配分に優先順位を付けることができていること。
4.2制限
目的：悪意のある攻撃や要求を防ぐためには、システムピーク超えて
練習を：
悪意のあるトラフィックはキャッシュにのみ要求アクセスが
nginxの制限使用してバックエンド・アプリケーション処理貫通流れ
nginxのはiptablesにIPポリシーやゴミを拒否悪質な使用を
4.3カットトラフィック
目的：シールド機械障害
プラクティス：
DNS：ドメイン名変更入口は、DNSPOD代替IP、IP正常障害、代替アドレスへの独立したスイッチとして添加してもよく、遅い効果練習取る
HttpDNSを：トラフィックの正確なスケジューリングをバイパスキャリア実現LocalDNSに
LVS / HaProxy / nginxの：障害が発生したノードの除去
4.4はロールバックすることができます
あなたは、常にバージョンが失敗した高速の安定版リリースに頼ることができます
5つのビジネスデザインの原則
5.1アンチ重いデザイン
防止重複ページ要求は、提出アンチリプレイキーを使用することができる、トークンその他の重いテーブルを置く
攻撃機を防止するためのグラフィカルな認証を。
5.2冪等の設計
メッセージングミドルウェア：メッセージコンシューマ繰り返しにつながる、ネットワークの遅延などによりの理由に注意を払う必要がありミドルウェアメッセージング
コールバックインタフェースでは、ネットワークの遅延は、サードパーティ決済プラットフォームに戻るには時間、コールバック電源やその他の問題に注意を払うが存在しないことに留意すべきである：サードパーティ製の支払いゲートウェイを。
分散システムでは、注文番号冪等一意問題は、ジョブの実行タイミングが発生することを確実にします。
5.3プロセス定義
パーソナライズされたサービスプロセスを提供するために、ワークフローシステムを多重化。
5.4状態とステートマシン
パーソナライズされたサービスプロセスを提供するために、ワークフローシステムを多重化。
システムの5月のフィードバックの5.5背景操作
バックオフィスシステムを設計する場合、プレビューの効果をフィードバックすることができ考えます。
バックグラウンドシステムの5.6承認
いくつかの重要なバックオフィス機能のために、このような価格を調整、および運用トレーサビリティ、監査能力を確保するための操作をログとして承認フローを設計する必要があります。
5.7ドキュメントのコメント
システム開発の初期段階では、ドキュメントライブラリ（デザイン・建築、設計、データ・ディクショナリ/業務プロセス、既存の問題を）持っているコメントを持つべきビジネスコードの特別なニーズに合わせなければなりません。
バックアップ5.8
バックアップコードおよび人員を含みます。主は、少なくともリポジトリの機能の複数のバージョンを持っている必要があり、コード倉庫管理とバックアップにコードを提出します。人事のバックアップは、少なくとも二つの開発者が知っている必要がありますシステムを指します。
