モノマーアーキテクチャ
1.アーキテクチャモノマー
モノマーアーキテクチャは、システムアーキテクチャのアプリケーションに結合されるように、モジュールのすべての関数であることが、モノマーまたはモノマーシステムアプリケーションと呼ばれています。簡単な方法は、同じサーバ内のアプリケーション、データベースなどを含むアプリケーション全体にあることを理解。分散アプリケーションは、データが別のサーバーに分離など、アプリケーションとデータベースの単純な角度からの操作のための異なる方向での性能を最適化することが理解されるべきです。
2.モノマーアーキテクチャ機能は
単一のユニットにパッケージ化され展開されたアプリケーション（パッケージまたはパッケージ戦争に導入ジャーと呼ばれる）の後、アプリケーションは、プロセスによって実行します
モノマーアーキテクチャの長所と短所の
の利点は
、プロジェクト管理可能
シンプルな展開
デメリット
テストのコストが高いです
スケーラビリティ差
信頼性が低いです
イテレーション困難
クロス言語的差異の程度
チームワークが難しいです
第二に、マイクロサービスアーキテクチャ
のマイクロサービスは何である1
マイクロ・サービスは、様々なマイクロサービスシステムで構成されるマイクロサービスは、それぞれ独立したマイクロサービスの展開することができる1つまたはそれ以上の建築様式、大規模、複雑なソフトウェア・アプリケーションであり、疎結合されている間、各マイクロはただ一つのタスクに焦点を当てたし、よくやったタスクを完了サーブ。複雑なソフトウェアシステムは、非人間的な解決されたが、スプリットを通過した後、複雑なアプリケーションでは、より効率的になります。
2.建築様式
の建築様式と呼ばれるプロジェクトのデザインパターンです。そして、私たちの共通のプログラミングモデルは、以下の4つの方法があります。その後、各モードの長所と短所の詳細な比較のために。
一般的な建築様式
クライアントとサーバは：C / SとB / Sは2であり、B / S特別なことを含みます。
コンポーネントベースアーキテクチャモデル（EJB）
階層化アーキテクチャ（MVC）
サービス指向アーキテクチャ（SOA）
3.マイクロ特長
（1）システムは、複数のサービスで構成されています
（2）各サービスを個別に独立して展開することができます
サービスのそれぞれとの間の（3）は、緩く結合されています。内部サービスは、高度に凝集され、外部結合が低く、それは複数のソフトウェア・デザインの原理に沿って、高い凝集力は、各サービス内の関係は、非常に近いだけ各サービス間の機能の完了に関係しているとなっています。
マイクロおよびサービス欠点のの4利点
利点の
テストは簡単
強力なスケーラビリティ
確実
クロスランゲージ度がより柔軟になります
チームワークは簡単です。
システムは、簡単に反復されます
欠点
運用および保守費用は、展開の大きな数が高すぎます
インターフェースは、マルチバージョンと互換性があります
分散システムの複雑さ
分散トランザクション
第三に、MVC、RPC、SOA、マイクロ・サービス・アーキテクチャの違い
1.MVCアーキテクチャ
実際には、本質的に、MVCデザインパターンは単一のアーキテクチャとして数え、数えられるべきです。Struts2の,, SpringMVC、春、：より多くの技術の代表 MyBatisのは、Hibernate のように。
2.RPCアーキテクチャ
RPC（リモートプロシージャコール）、基盤となるネットワークプロトコル技術を理解する必要なく、ネットワーク経由でのリモートコンピュータへの要求であるリモートプロシージャコール、。技術を代表して、スリフト、ヘッセなど
SOAアーキテクチャ
SOA（サービス指向アーキテクチャ）、サービス指向アーキテクチャ
ESB（Enterparise Servceバス）：エンタープライズ・サービス・バス、サービス機関。サービス間の双方向サービスの主要プロバイダー。
制御、暗号化処理、サービス監視、例外処理、監視、警告およびその上を流れ、負荷分散：ESBは、次のような機能を備えています。
代表的な技術：ラバ、WSO2など
マイクロサービスアーキテクチャ
マイクロサービスは、技術に代わって、軽量なサービス管理プログラムである：ダボなどSpringCloud、
どのようにマイクロサービスを設計し、設計原則第四に、
1.AKFは原則を分割
前記後端部の前端部の分離の原理
3.ない状態サービス
4.RestFul実勢スタイル
1.AKFは、原則として分割
シンプルなコンセプトで設計され、私たちは機械の容量と可用性を追加することによって、問題を解決することができるスケーラブルなシステムアーキテクチャのための業界を。つまり、十分ではありませんマシンは、2台のマシンを使用します。
、今日の社会ではめちゃくちゃ人気の「クラウドコンピューティング」という概念の概念は、我々はほとんどの問題を議論し、規模の急速な成長のために広く認識されているシステム容量とパフォーマンスの問題です。しかし、パフォーマンスと容量の問題に直面するだけでなく、ビジネスの変化だけでなく、システム数の増加をもたらす機能とモジュールの複雑化によって引き起こされる問題に直面する必要性に加えて、時間進行、システムのサイズの増加、として区別提供しますサービスの問題。多くのシステム再設計時間と完全に再構成可能なシステムで、その結果、アカウントにこの問題をしていないは、このようにサービスを提供する能力だけでなく、人間と財源の無駄遣いに影響を与え、常識となっ！この点で、「スケーラビリティアートは、」本は前方よりスケーラブルなモデル--AKFシステムのスケーラビリティ立方メートルを置きます。それぞれ3つの座標軸の方向XYZキューブ。
Y軸（機能）
Y軸の拡張は、複数のサービスの中に、アプリケーション全体の膨大な量を追加します。各サービスは、注文管理、顧客管理などの関連機能のセットを実装しています。一般的なシナリオは、電子商取引プラットフォームのようなサービス指向アーキテクチャ（SOA）、ある工学の、我々は、異なるサービスに以下から成るようなフレームワーク分割することができます。
しかし、見つけるのは簡単で、ときサービスの数の増加のグラフを見ることによって、サービスは関係が複雑になってきた呼ぶようになりました。システムに新しい機能を追加し、呼び出されるサービスの数は、サービス管理上の混乱につながった、制御不能になります。したがって、通常の状況下で、我々はサービス管理にサービスゲートウェイを形成し、サービス登録のための機構を必要とする以下の図に示すように、システムアーキテクチャ設計はなるだろう。
X軸（水平展開）
拡張X軸は、シンプルなアイデアの前に配向されているサービスおよびデータの複製サービス、能力や問題を解決するための可用性の絶対平等で、同じです。実際には、マイクロ・サービスの複数のインスタンスを使用することに加え、クラスタモードのロードバランシングを行います。
単一のサービスの利用可能性と能力を高めるために、各サービスは、X軸が延びる分割されています。
Z軸（データ分割）
一般に、システムを分割し、そしてそのようなサブシステムのうち分割単離されているが、損なわれている、ユーザーまたは要求者の固有のニーズに基づいて、Z軸の膨張を指します。中国事業の発展のためのフォード・モーター・カンパニー、またはZ軸の拡張である完全な自動車生産を担当、米国の工場のような完全なサブ工場を確立するために中国で中国の安い労働力を活用する：例の自動車工場の生産。
共通のZ軸拡張エンジニアリングプログラムは、次の2つがあります。
ユニットアーキテクチャ
分散型サービスの設計では、セル（セル）は、自己完結型のクローズド・ループ・パーティションにすべての業務を満たすことです。それはSOAアーキテクチャのY軸拡張、上の例になると、このプラスZ軸拡大は、その後しなくなり、ランダムなサービスノードを選択した場合、クライアント選択サービスのエンド・ノードは、一方で、一般的にランダムであるが、各ユニットは、図のように、自己完結型です。
データパーティション
安全性能データを考慮するために、我々は異なるサブセットに分け、特定の寸法に応じて、完全なデータセットになります。パーティション（シャード）は、全体のデータセットのサブセットです。尾の番号を分割するために、ユーザによって、例えば、同じユーザ数の端部は、パーティションと考えることができ、パーティションデータは、一般的な方法を分割する次のデータを含みます
データタイプなどトラフィックの種類
周期データの範囲、例えば、ユーザID
このような熱は、熱商品などのユーザアクティビティデータ
製品例サブリーダー、商品目録に記載されているように
前記後端部の前端部の分離の原理
それを分離後縁のフロントエンドとは何ですか！もともと一般的な概念に前端と後端を単離しました。この協力関係の下では状況の知識の他の領域に触れずにフィールドで最高のエンジニア、大きなケーキを置くためにJSP技術、労働者の細心の部門からスタートします、それはますます効率的な場合があります。メンテナンスももっともっとシンプルになります。JSPテンプレート技術、HTMLとJavaコードの組み合わせ、この技術では膠質で、フロントエンドとバックエンドのレガシーMVCの開発を行うには、仕事はフロントエンドのソリューションで問題を探しに行くフロントページ、テンプレートにバックエンドのターンを、行うことですフロントエンドとフロントとリアの最終目標を分離し、Javaコードを読み取ることができませんが、これらの厄介な状況を打破することです。
分離原理の終わりは、フロントエンドの分離とバックエンドのコードの点ではシンプルで前と後に、我々は物理的な分離モデルを使用することをお勧めします、それは直接使用するサーバー側のテンプレート技術に続けば、さらに、より徹底した分別を推進展開するための最良の方法である、などJSPのjava、JS、HTML、CSSは複雑なページは維持方法はありませんもう少し、ページに積ま。
この分離方法は、いくつかの利点を持っています
ユーザーエクスペリエンスの最適化、より良い、フロントとリアのサイド技術を分離、それぞれの分野を最適化するために、それぞれの専門家が行うことができるので、フロントエンド
スプリットモード、明確なインターフェースのフロントエンドは、バックエンドのインターフェイスにインターフェースモデル、紹介を残して、明確な、そしてより多くの、簡単に維持するために
、バックエンドサーバーを変更せず、統一データモデルを実装する方が簡単、フロントエンドのマルチチャネル統合シナリオをして、マイクロチャネルのフロントエンドH5、PCのフロントエンド、Androidのフロントエンド、IOSのフロントエンドとして、複数のフロントエンド、サポートすることができます
。3.無状態サービスを
ステートレスサービスの場合、最初の状態が何であるかを紹介します。データは、トランザクションを完了するために、複数のサービスで共有される必要があり、その後、このデータは状態と呼ばれている場合。この状態のさらなる依存性は、他にステートレスなサービスとして知られている、サービス・データ・サービス状態と呼ばれ
まあ、これは非国家サービスの原則は、マイクロ状態でサービスに存在することを意味するものではありませんが、真の意味はクラスのサービスを計算するステートレスためのすべてのビジネスサービスを置くために状態を変更することです表現するために許可されていない場合、対応する状態データが対応に移行されますステートフルなデータサービス。
シーンの説明：そのビジネス・サービスは、ステートレスの計算ノードになりますので、例えば、我々は以前にローカルメモリデータキャッシュ、セッションキャッシュに設立され、現在はマイクロサービスアーキテクチャは、あなたがキャッシュに保存されている分散データに移行する必要があります。移行後、オンデマンドの動的ストレッチ行うことができ、動的な追加または削除ノードは、実行時にキャッシュデータ同期サービスマイクロアプリケーションに方法を検討する必要はありません。
4.RestFulコミュニケーションスタイル
：原則として、それは彼が多くの利点を持っているので、直接コミュニケーションスタイルは、ここにRESTfulな好ましい実施を推奨「ステートレス通信の原則」になるはずでした
ステートレスプロトコルHTTPは、自然の利点を持って、強力な拡張機能は、例えば、セキュリティを必要とし、HTTPSへの既存および実証済みのソリューションがあり
JSONシリアライズパケット、軽量でシンプル、人と機械が読むことができ、低コストを学び、エンジンフレンドリーな検索
言語に依存しないが、主要な一般的な言語は、RESTfulなAPIフレームワーク、他のエコ-RPCフレームワークの相対数は、より完全な成熟しています。