まず、サイトのアーキテクチャの進化
：サイトのアーキテクチャは、次のフェーズに分けることができます
- >分散型アーキテクチャ（プロジェクト分割） - > SOA（サービス指向アーキテクチャ） - >マイクロサービスアーキテクチャ従来のアーキテクチャ（シングルユース）
1.Monolith（シングルユース）のアーキテクチャ
単一のアプリケーションをある何1.1
最初、我々はサービスを開発してきたことをすべてリコールのは、それがどのように見えるかです。典型的には、サービスコードを構成する複数の項目に対応し、各アイテムは、それ自体によって提供される機能に応じて明確な境界を有することになります。コンパイル時には、これらのアイテムは、1つのJARパッケージに包装し、最終的にはWARパッケージを形成するために一緒にマージされます。次に、我々は、WebコンテナにWARパッケージをアップロードするWARパッケージを抽出し、サーバーを再起動する必要があります。この一連の動作の実装が完了した後、我々はコンパイルして、サービスが完了した展開します。組織とコードのすべての機能を1つのパッケージに含まれているこのプロジェクトは、WARモノリスと呼ばれます。例えば、我々は、SSHを使用して、SSMアーキテクチャは、単一のアーキテクチャです。
1.2欠点
このアーキテクチャは、MVCの考え方に基づいて層別化し、プロジェクト内のビジネス・モジュールを通じて開発されます。
このプロジェクトの場合には小さなモノマーアプリケーションは比較的単純であるが、プロジェクトとしてますます大きくなって、より次のような欠点が存在するより多くのコード。
- テストするのは難しい、展開するのが難しい、難しいコンパイルし
、符号量にもパッケージをコンパイルするために展開する前に、コンパイルに多くの時間を過ごすために必要なコードの行を変更するために多くの時間を、それを解凍し、そう難しい展開し、展開が終わっただけでなく、テストのテスト難しいそう。 - 高と相まって
サービスが得られモジュールが使用不能になると、それがプロジェクト全体に影響を与える可能性があります。 - することは困難拡張
サービスの容量を拡張するとき、我々は唯一の繰り返しこれらのWARパッケージを展開することを選択することができますので、単に拡張子が表示されるのではなく、サービスの機能を拡張するために、唯一のWARパッケージは、すべての機能が含まれて生成されたコードモノリスの組織に従ってくださいシステムのボトルネックのコンポーネント。
2.分散アーキテクチャ
進化した伝統的な建築様式に基づいて、プロジェクト全体は、次のフェーズに分け、複数のサブプロジェクトに分割されます：
2.1データベースサービス、アプリケーション、ファイルの分離段階
2.2アプリケーションサーバークラスタの展開フェーズ
時に業務トラフィックの多い時にユーザー要求は、リードユーザーエクスペリエンスの低下、同じアプリケーションを複数のサーバーに展開することができ、この時、1台のサーバー上の圧力を緩和するために、各サーバーに配布ユーザー要求の数が多いため、キューに入れられます。
そして含ま要求、配布する方法を负载均衡（Load Balancing）算法設計し、サーバのパフォーマンスを最大化することができ良好な負荷バランシングアルゴリズムは、一般的に使用されるロードバランシングアルゴリズムになります。
- ポーリング方式
ポーリング方式は、ユーザの要求が順番にサーバーに割り当てられている、それはターン配分で、一つ一つを数えるようなものです。このアルゴリズムは比較的単純である、彼は絶対的なバランスの利点を持っていますが、またそれが絶対的にバランスが取れているので、それは例えば、それは仕事、余裕ができないサーバーに基づいて割り当てタスクの合理的な配分を保証することはできません、高い代償を払う必要があります。 - ランダムに
ランダムに、ランダムに割り当てタスクにサーバーを選択します。これは、リクエストの分散がバランスをとる目的を達する保証します。同時に、以前の状態と選択された状態の等化係数を維持するために必要ではない[5]。しかし、タスクの増加量と、その効果はポーリングアルゴリズムも欠点部分を持っているポーリングする傾向があります。 - 最小ライゲーション
最小接続方法がアルゴリズムを動的負荷分散であるので、タスクは、この時点で接続の最小数を有するノードに割り当てられます。ノードは、接続の数は、一つのタスクによって増加される受信した後、ノードは、重みが0に設定されているノードの障害となり、タスクは、もはやノードに割り当てられていません。各ノードに適した最小の接続方法は、処理性能と同様です。サーバーへのユニットを配布タスクがスムーズにタスクを割り当てます。サーバーのパフォーマンスのギャップが大きい場合でも、それは望ましい結果を達成することはできません。接続数が正確に、サーバの処理能力、接続小さく、パフォーマンスの低下を示すものではありませんので、それ自体は、接続サーバ自体の大きなと優れた性能の数より少なくてもよいです。タスクが発生します。この時点でのように、正確に、強力な余剰処理能力のマシンに割り当てることができません。
2.3数据库读写分离阶段
2.4为了缓解数据库压力，又在系统加入NoSql（Redis、MongoDB）等内存型数据库作为缓存
此时遇到用户请求，先去查找缓存，若查到则只需要1次内存I/O；缓存中没有时，经过1次磁盘I/O从数据库读取数据，再经过1次内存I/O写入缓存。
2.5将服务器集群按照应用拆分并拆分数据库
随着业务量的增加，表的数据不断增长，数据查询性能便成了问题，所以必须要对数据库进行水平拆分。水平拆分是将单个表的数据拆分到多个数据库中，如100W数据的表拆分到10个数据库后，每个表就只有10w。
3.SOA架构（Service-Oriented Architecture）
在上面的架构中，用户服务会调用到商品服务，商品服务又会调用交易服务，用户服务又调用订单服务，调用关系错综复杂，维护成本不断变高。此时，SOA架构出现了：
SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML（标准通用标记语言的子集）/Web Service技术之后的自然延伸。
SOA将能够帮助软件工程师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。
SOA架构通俗的理解为将共同的业务逻辑抽取出来形成一个通用服务，如Mq、Hdfs、检索工具等，该服务作为一个独立项目部署，给其他服务提供接口进行调用，服务间调用依然使用RPC远程技术。
4.微服务架构
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于Http的Restful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立开发,独立部署,独立运维，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
4.1.那么服务间的远程调用方式有哪些呢？
常见的远程调用方式有以下几种：
- RPC：Remote Produce Call远程过程调用，类似的还有RMI。自定义数据格式，基于原生TCP通信，速度快，效率高。早期的webservice，现在热门的dubbo，都是RPC的典型
- Http：http其实是一种网络传输协议，基于TCP，规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议。也可以用来进行远程服务调用。缺点是消息封装臃肿。
複数のマイクロ・サービスマイクロサービスアーキテクチャの存在のために、どのように管理し、これらのサービスを調整するには？springcloudは春ブーツがパッケージを実装するサービスベースの管理ツールである一方、我々は、サービスガバナンスのフレームワークに必要です。
春は何か4.2。クラウド
春クラウドは、一連のフレームの順序付きコレクションです。その用途は、巧みに、サービス発見、登録、流通センター、メッセージ・バス、ロードバランシング、回路遮断器、監視および他のデータのような分散システム・インフラストラクチャの開発を簡素化、春ブーツの開発の様式で行うことができる春ブーツの開発を促進しますそして、展開を開始するためのキー。Springcloudは車輪の再発明はない、それだけで、各企業が再パッケージ化され、より成熟し、合わせた実際のサービスフレームワークのテストに耐えることができます開発し発表します最終的に開発するために、春ブーツスタイルでの原則の複雑な構成と実装をマスクしさておきセット分散システム開発キットの、理解しやすい展開が容易と簡単なメンテナンスのセットに。
以下は主なコンポーネント（百度からの抜粋）は以下のとおりです。
春の雲は多くの優れた要素を持っている、後の記事では、列挙されます。
