# 架构的演变过程 ``` MVC架构　—>　　 RPC架构　　 —> 　　SOA架构　　 —>　　 微服务架构 ``` ## MVC架构 　　MVC架构其实就是SSH或SSM，属于单点应用，把整个业务模块都会在一个项目进行开发，分为MVC架构，会拆分成控制层、业务逻辑层、数据库访问层（持久层）。 传统架构一般适合于一个人或者小型团队开发。 #### 缺点： 耦合度太高，一旦某个模块导致服务不可用，可能会影响到其他模块  ## RPC架构 RPC是基于传统架构演变过来的，将传统的项目以项目模块拆分成多个子项目，比如：拆分会员项目、订单项目、支付项目、优惠券项目等，每个项目都有自己的独立数据库，独立redis等。 #### 优点： * 把模块拆分，使用接口通信，降低模块之间的耦合度。 * 把项目拆分成若干个子项目，不同的团队负责不同的子项目。 * 增加功能时只需要再增加一个子项目，调用其他系统的接口就可以。 * 可以灵活的进行分布式部署。（并发量太大的话就要使用缓存（memcached、radis等）） #### 缺点： 系统之间交互需要使用远程通信，接口开发增加工作量  ## SOA架构　 　　SOA架构代表面向服务架构，俗称服务化。通俗的理解为面向于业务逻辑层开发，将共同的业务逻辑抽取出来形成的一个服务。提供给其他服务接口进行调用，服务于服务之间调用使用rpc远程技术。 #### 缺点： * 依赖于中心化服务发现机制。 * SOA架构采用的是SOAP协议（Http+xml），因为xml传输协议比较占用宽带，整个xml报文中有非常大的冗余数据，所有在微服务架构中以轻量级的json方式代替了xml报文传输。  ## 微服务架构 微服务架构是从SOA架构中演变过来的，比SOA架构上的粒度更加精细。让专业的人做专业的事情，目的就是为了提高效率。每个服务之间互相不受影响，每个服务必须独立部署（独立数据库、独立Redis等），微服务架构更加提醒轻量级，采用restful风格提供的API，也就是使用HTTP协议+json格式进行传输，更加轻巧，更加适用于互联网公司敏捷开发、快速迭代产品。  、 #### 优点 * 测试容易 * 可伸缩性强 * 可靠性强 * 跨语言程度会更加灵活 * 团队协作容易 * 系统迭代容易 #### 缺点 * 运维成本过高，部署数量较多 * 接口兼容多版本 * 分布式系统的复杂性 * 分布式事务 #### 微服务架构如何拆分： * 微服务把每一个职责，单一功能存放在独立服务器中。 * 每个服务运行在单独进程中，能够单独启动或销毁。 * 每个服务有自己独立的数据库存储，实际上有自己独立的缓存、数据库、消息队列等资源。 #### 微服务设计原则 * AKF拆分原则 业界对于可扩展的系统架构设计有一个朴素的理念,就是： 通过加机器就可以解决容量和可用性问题。(如果一台不行那就两台)。 我是个段子：（世界上没有什么事是一顿烧烤不能解决的。如果有，那就两顿。） 这一理念在“云计算”概念疯狂流行的今天，得到了广泛的认可！对于一个规模迅速增长的系统而言，容量和性能问题当然是首当其冲的。但是随着时间的向前，系统规模的增长，除了面对性能与容量的问题外，还需要面对功能与模块数量上的增长带来的系统复杂性问题以及业务的变化带来的提供差异化服务问题。而许多系统，在架构设计时并未充分考虑到这些问题，导致系统的重构成为常态，从而影响业务交付能力，还浪费人力财力！对此，《可扩展的艺术》一书提出了一个更加系统的可扩展模型—— AKF可扩展立方 （Scalability Cube）。这个立方体中沿着三个坐标轴设置分别为：X、Y、Z。  * 前后端分离原则 何为前后端分离？前后端本来不就分离么？这要从尴尬的jsp讲起。分工精细化从来都是蛋糕做大的原则，多个领域工程师最好在不需要接触其他领域知识的情况下合作，才可能使效率越来越高，维护也会变得简单。jsp的模板技术融合了html和java代码，使得传统MVC开发中的前后端在这里如胶似漆，前端做好页面，后端转成模板，发现问题再找前端，前端又看不懂java代码......前后端分离的目的就是将这尴尬局面打破。 前后端分离原则，简单来讲就是前端和后端的代码分离，我们推荐的模式是最好采用物理分离的方式部署，进一步促使更彻底的分离。如果继续直接使用服务端模板技术，如：jsp，把java、js、html、css都堆到一个页面里，稍微复杂一点的页面就无法维护了。  * 无状态服务 对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。 那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。 场景说明：例如我们以前在本地内存中建立的数据缓存、Session缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。  * RestFul的通讯风格 作为一个原则来讲本来应该是个“无状态通信原则”，在这里我们直接推荐一个实践优选的Restful 通信风格 ，因为他有很多好处： 1) 无状态协议HTTP，具备先天优势，扩展能力很强。例如需要安全加密，有现成的成熟方案HTTPS即可。 2) JSON 报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。 3) 语言无关，各大热门语言都提供成熟的Restful API框架，相对其他的一些RPC框架生态更完善。  ## MVC、RPC、SOA、微服务架构之间的区别  #### MVC架构 其实MVC架构就是一个单体架构。 代表技术：Struts2、SpringMVC、Spring、Mybatis等等。 #### RPC架构 RPC(Remote Procedure Call)：远程过程调用。他一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。 代表技术：Thrift、Hessian等等 #### SOA架构 SOA(Service oriented Architecture):面向服务架构 ESB(Enterparise Servce Bus):企业服务总线，服务中介。主要是提供了一个服务于服务之间的交互。 ESB包含的功能如：负载均衡，流量控制，加密处理，服务的监控，异常处理，监控告急等等。 代表技术：Mule、WSO2 #### 微服务架构 微服务就是一个轻量级的服务治理方案。 代表技术：SpringCloud、dubbo等等