垂直架构

随着互联网的发展，用户越来越多，软件技术也得到了很大的发展，人们开始研究一些技术使其与底层硬件交互会更加友好等。
及某系统流量访问某模块占比很高，而其他模块没有什么流量访问，如果都部署到一起占用资源就浪费了，如果分开部署，流量高的部署到一台高性能服务器，而流量低的部署到一台普通的服务器，两个模块之间的交互用webService,RPC等方式进行访问

架构说明：按照业务进行切割，形成小的项目，项目直接通过rpc等方式通信，交换数据等。

架构优点：涵盖了传统架构的优点，另外项目不会无限扩大，技术栈可扩展（不同的系统用不同的编程语言编写）。

架构缺点：1.功能集中在一个项目，不利于开发，扩展，维护。                   2.系统扩展只能通过集群的方式。                   3.项目之间功能冗余，数据冗余，耦合性强。

面向服务架构

在垂直架构中可以看到，物流系统有用户管理，CRM系统有用户管理，为什么还要重复去写？

人总是聪明的，很快的把一些生活中的例子作为参考去做设计（生活中，人们需要实现某种需求时，通常是去看市场是否有这种工具在售，人们不会去关心这个东西是怎么做成的），把用户管理模块作为一个服务去对外提供。

用户管理模块作为一个服务提供出去，人们怎么去找到这个服务？各系统的用户信息结构可能不一样所接入的接口可能不一样？

交互要经过ESB(企业服务总线)，ESB帮助你去找到你所需要的服务，且帮助你寻找到所需要的接口，可以理解为一个过滤和寻址的过程。

架构说明：将重复功能或模块抽取成组件的形式，对外提供服务，在项目与服务之间使用ESB的形式作为通信的桥梁，使用RPC等方式进行通信。

架构优点：1.重复功能或模块抽取为服务，提高开发效率，可重用性高，可维护性高                   2.可以针对不同服务制定对应的技术方案                   3.接口耦合低

架构缺点：各系统之间业务不同，因此很难确认功能或模块是重复的，不利于开发和维护抽取服务的粒度大，系统和服务之间耦合度高

微服务架构

SOA架构有局限性，就是所有的接口都需要走ESB，如果不同的编程语言开发子系统，而这个编程语言对于某种RCP协议支持是最友好的，而ESB规则限定只能使用ESB规定协议。而这里的网关是用于数据过滤等业务场景。

架构说明：在服务治理架构上延伸，抽取的粒度更细，尽量遵循单一原则，采用轻量级框架协议传输。

架构优点：1.去中心化。
                  2.粒度更细，有利于提升开发效率。
                  3.可以针对不同服务指定对应的技术方案。
                  4.去中心化的思想，不在使用ESB作为通信的桥梁，服务，系统之间可以相互访问。  
                  5.适用于产品迭代周期短

架构缺点：1.粒度太细导致服务太多，维护成本高。
                  2.负债均衡，事务等问题等技术团队的挑战及成本问题。