转：web系统架构演进

引自：系统架构演进

  

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。实际生产环境，通常将mvc项目集群，nginx+tomcat 多服务器提供访问。

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

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/dubbox/springcloud

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

微服务的主要特征如下：

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

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

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

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

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