正文
基于组件模型的架构（EJB）
分层架构（MVC）
面向服务架构（SOA）
特点如下：
优点如下：
边界清晰：
比如说一个电商平台，我们以前是部署在一台服务器上，所有的代码打成一个 war 包。
现在，我们可以给它拆分开：用户服务，积分服务，支付服务，仓储服务，信息服务，地图服务等等。
每一个微服务只关注一个特定的业务功能，这样的话开发和维护单个服务都比较简单，因为它的边界足够清晰，业务也足够清晰，用户服务，只做好用户的事情就好了，相较于之前的大而全的单体服而言，每个微服务的代码量也比较少。
效率高：
单体服务随着代码量变得越来越多，比如说百万行级别的代码，仅仅编译一次应用可能就需要花费很久。
但是现在，如果一个地方有问题，比如说支付模块有问题，只需要单独修改支付模块，修改完支付模块之后，单独测试支付功能，单独部署支付模块就可以了，而不会影响整体的部署速度。
技术栈不受限制：
每一个服务可以使用不同的技术栈来实现，由于不同的服务之间是通过 restful API 来通信的，所以每个服务可以使用不同的技术框架，使用不同的存储库来实现。
拓展性更强：
随着业务的发展，用户量变得越来越多，或者说订单量猛增，这时我们可以专门去优化这个订单服务，给这个订单服务提供更高配置的机器，而其他并没有遇到瓶颈的业务，比如说短信服务，我们可以暂时不用动。
缺点如下：
运维成本过高：
以前只需要打个 war 包扔在 tomcat 下面就可以了，但现在，我们可能需要部署几个甚至几十个微服务，这样的话，如何保证这几十甚至上百个微服务正常的运行和互相通信协作，这给运维带来了很大的挑战。
分布式系统复杂：
使用微服务这种架构，构建的是一个分布式的系统，在分布式系统当中会引入很多问题，比如说分布式锁，分布式事务等等。
这个时候我们需要对这个系统的，事务，幂等，网络延迟，分区，熔断，降级等问题都要有一个妥善的处理和应对方案。
通信成本高：
由于之前的接口调用都在同一个进程内，我需要支付调用支付方法，需要积分直接调用添加积分的方法。
但现在，由于积分模块或者支付模块都被拆成了单独的服务，这个时候如果再想去调用的话，就是通过 http 方式的请求去调用。
这种频繁的跨服务通信是有很高的成本的，选择一个适合自己业务的轻量级低成本的通信方式，也很关键。
服务拆分难：
如何做好微服务的拆分？这个是需要我们不断摸索的，从单体服务向微服务架构的演进，它是一个循序渐进的过程，在演进的过程中常常会根据业务变化来对微服务进行重构，甚至是重新划分，从而让这个架构更加合理。
①MVC 架构
MVC 架构就是一个单体架构。我们常使用的技术：Struts2、SpringMVC、Spring、Mybatis 等等。
②RPC 架构
RPC（RemoteProcedureCall）：远程过程调用。他一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。我们常使用的技术：Thrift、Hessian等等。
实现原理：首先需要有处理网络连接通讯的模块，负责连接建立、管理和消息的传输。
其次需要有编解码的模块，因为网络通讯都是传输的字节码，需要将我们使用的对象序列化和反序列化。
剩下的就是客户端和服务器端的部分，服务器端暴露要开放的服务接口，客户调用服务接口的一个代理实现，这个代理实现负责收集数据、编码并传输给服务器然后等待结果返回。
③SOA 架构
SOA（ServiceorientedArchitecture）：面向服务架构。
ESB（EnterpariseServceBus）：企业服务总线，服务中介。主要是提供了一个服务于服务之间的交互。
ESB 包含的功能如：负载均衡，流量控制，加密处理，服务的监控，异常处理，监控告急等等。我们常使用的技术：Mule、WSO2。
③微服务架构
微服务就是一个轻量级的服务治理方案。我们常使用的技术：Spring Cloud、Dubbo 等等。
架构区别
①AKF 拆分原则
业界对于可扩展的系统架构设计有一个朴素的理念,就是：通过加机器就可以解决容量和可用性问题。
这一理念在“云计算”概念疯狂流行的今天，得到了广泛的认可！对于一个规模迅速增长的系统而言，容量和性能问题当然是首当其冲的。
但是随着时间的向前，系统规模的增长，除了面对性能与容量的问题外，还需要面对功能与模块数量上的增长带来的系统复杂性问题以及业务的变化带来的提供差异化服务问题。
而许多系统，在架构设计时并未充分考虑到这些问题，导致系统的重构成为常态，从而影响业务交付能力，还浪费人力财力！
对此，《可扩展的艺术》一书提出了一个更加系统的可扩展模型——AKF 可扩展立方（ScalabilityCube）。
这个立方体中沿着三个坐标轴设置分别为：X、Y、Z。
Y 轴（功能）：
关注应用中功能划分，基于不同的业务拆分。
Y 轴扩展会将庞大的整体应用拆分为多个服务。每个服务实现一组相关的功能，如订单管理、客户管理等。在工程上常见的方案是服务化架构（SOA）。
比如对于一个电子商务平台，我们可以拆分成不同的服务，组成下面这样的架构：
服务化架构 SOA
但通过观察上图容易发现，当服务数量增多时，服务调用关系变得复杂。为系统添加一个新功能，要调用的服务数也变得不可控，由此引发了服务管理上的混乱。
所以，一般情况下，需要采用服务注册的机制形成服务网关来进行服务治理。
服务网关治理
X 轴（水平扩展）：
关注水平扩展，也就是”加机器解决问题”。
X 轴扩展与我们前面朴素理念是一致的，通过绝对平等地复制服务与数据，以解决容量和可用性的问题。
其实就是将微服务运行多个实例，做集群加负载均衡的模式。为了提升单个服务的可用性和容量，对每一个服务进行 X 轴扩展划分。
X 轴（水平扩展）
Z 轴（数据分区）：
关注服务和数据的优先级划分，如按地域划分。
Z 轴扩展通常是指基于请求者或用户独特的需求，进行系统划分，并使得划分出来的子系统是相互隔离但又是完整的。
工程领域常见的 Z 轴扩展有以下两种方案：
单元化架构：
在分布式服务设计领域，一个单元（Cell）就是满足某个分区所有业务操作的自包含闭环。
如上面我们说到的Y轴扩展的 SOA 架构，客户端对服务端节点的选择一般是随机的，但是，如果在此加上 Z 轴扩展，那服务节点的选择将不再是随机的了，而是每个单元自成一体。
移动端用户
数据分区：
