系统应用架构演变（转载）

0.      ORM应用

就是全部的都写在一块儿 ，这里就不作解释了吧，

1.      传统的垂直应用的架构：

就是咱们如今企业中最经常使用的MVC架构，它有一个主要的特色就是技术单一，开发上手快，测试，部署都是比较简单的

MVC的三层结构：

a．  最前端的是V(view),主要是用于前端页面展现，使用jsp,js,html+css等

b．  中间为调度控制层（Control）,主要是用于前端web请求的分发，而后调度后台的逻辑执行，能够经过struts2或者spring mvc来实现

c．  第三层为应用模型层（Model），模型是应用程序上的字体部分，模型表明了业务逻辑和业务数据

标准的MVC模式并不包含数据访问层，在开发中咱们有一些架构能够解决这个问题，好比使用了咱们的ORM(对象关系映射框架)来实现与数据库的访问，可使用mybatis和hebernate,这俩个框架都不一样程度的封装了JDBC

这种垂直架构面临的挑战：

1.      复杂应用开发的维护成本很高，部署效率低

2.      团队合做弱，多个项目的或者同一个项目的公共模块重复开发，增长了代码量的冗余

3.      系统可靠性下降，随业务的不断增长，访问量增大，网络流量增大，数据库链接增多，这都是将要面临的问题

4.      维护困难：业务代码不断加大，功能不断加多，在这种垂直的架构中没法对已有的服务拆分，改一个地方，其它地方会有影响

2.      RPC架构

RPC架构可让远程过程（服务）调用更加简单、透明，RPC框架负责屏蔽底层的传输方式（TCP或者是UDP）、序列化方式（XML、JSON、二进制）和一些通讯的细节，开发者不须要关心具体的通讯细节和调用过程

RPC架构的核心技术：

1.      远程服务提供者须要以某种形式提供服务调用相关的信息，包括但不局限于服务接口定义、数据结构，或者中间态的服务定义文件，服务调用者须要经过必定的途径获取远程服务调用相关信息。

2.      远程代理对象：服务调用者调用的服务实际是远程服务的本地代理，对于咱们的java来讲其实就是jdk的动态代理，经过动态代理的拦截机制，将本地调用封装成远程服务调用

3.      通讯：RPC框架与具体的协议无关

4.      序列化

RPC架构面临的挑战：

随着服务愈来愈多的时候，服务间依赖关系变得错综复杂，服务的调用量愈来愈大，服务的容量问题就会暴露出来了，某个服务在那个机器上，何时该增长节点，这都是问题

将业务服务化后，随之而来的就是服务治理的问题，目前业界开源的RPC框架的服务治理能力都不是很健全，当应用大规模服务化后会面临许多服务治理方面的挑战，须要解决这些问题，必须经过服务框架+服务治理来完成，但凭RPC框架就比较吃力了

3.      SOA服务化架构

SOA是一种粗粒度，松耦合的以服务为中心的架构，接口间经过定义明确的协议和接口进行通讯。它能够更加从容地应对复杂企业系统集成和需求的快速变化

SOA面向服务的通常原则总结以下

1.      服务和复用

2.      服务共享一个标准的契约：好比说一个接口

3.      服务间是松耦合的

4.      服务是底层逻辑的抽象：只有经服务契约所暴露的服务对外部可见，契约外的底层逻辑实现是不可见的

5.      服务是能够组合的：多个服务能够被编排组合成一个新的服务

6.      服务是自治的不依赖其它服务

7.      服务是能够被自动发现的:服务发布上线后，容许被其它消费者自动发现

SOA架构面临的挑战：

SOA架构解决了应用服务化的问题，随着服务化实践的不断深刻，服务规模愈来愈大，服务治理面临的挑战也是愈来愈多

4.      微服务架构例如dubbo/springcloud

微服务架构是一种服务化架构风格，经过将功能分散到各个离散的服务中以实现对解决方案的解耦

微服务的主要特征以下：

1.      原子服务，专一于作一件事情，与面向对象中的“单一职责原则”相似，实现高内聚，低耦合

2.      高密度部署：重要的服务能够独立进程部署，非核心服务能够独立打包，合设到统一进程中去，服务被高密度部署

3.      敏捷交付：服务由小研发团队负责设计、开发、测试、部署、线上治理运维整个服务的生命周期

4.      微治理：服务足够小，功能单一，能够独立打包、部署、升级。不依赖其它的服务，实现了局部自治

这就是咱们应用架构的演进，从耦合到微服务，便于管理和服务的治理