微服务项目架构演变过程

接上一篇了 微服务项目常用术语 之后，这次来了解一下微服务项目架构的演变过程。

概括

业界流传这么一句话：大型项目是演变而来的

很正确，项目成立之初很多业务并没有确定，需要根据需求变化，改进项目。经典例子：淘宝体系演变，有兴趣的同学可以找一下<<淘宝技术这10年>>看看，了解下淘宝如何从最初的PHP体系演变成现在的Java体系。

当今，随着web2.0移动互联网的兴起，用户量的暴涨，各类网站应用的、各种APP规模也实现跨越式增长，随之而来的是各种高并发，海量数据处理的头疼问题，此时的系统架构为了使用时代，也被迫推陈出新。从互联网早期到现在，系统架构大体经历了下面几个过程：

单体应用架构--------垂直应用架构--------分布式架构--------SOA架构--------微服务架构

后续围绕这些架构模式讲解各自的优缺点。

单体应用架构

项目初期，一般的网站应用用户量很少，产生的流量也很少，项目所有功能完全可以部署在一起。减少开发、部署和维护成本。最关键是硬件成本。

以电商系统为例子：一个完整电商系统肯定包含：用户管理，商品管理，订单管理，物流管理等不同模块，如果按照单体应用架构方式搭建项目如下：

优点：

• 项目架构简单，小型项目的话， 开发成本低

• 项目部署在一个节点上(一只猫即可)， 维护方便

缺点：

• 功能集中，需求复杂后不易开发和维护

• 项目模块之间紧密耦合，单点容错率低

• 无法对对某个模块进行水平扩展

垂直应用架构

上面单体架构开发维护是爽了，但当用户量上来，各种问题会接踵而来，最明显问题就是访问速度下降。这时我们可能想到的方案有2种：

1>砸钱垂直扩展，提高服务器性能

2>项目集群，提高并发

方案1：短时间内可行，长期来说是个坑，原因：服务器硬件有瓶颈，无法无限提升

方案2：可行，当不是最佳，存在资源分配问题。

 集群之后，所有代码一式多份，所有功能模块都平等占用资源。但实际情况是用户更关心商品是否有货，下单是否通畅，也就是说电商项目的流量集中的商品管理，订单管理上而非其他边缘模块，此时就存在核心模块资源不足，边缘模块资源过剩的问题。那怎么办呢？垂直应用架构就应运而生啦。

垂直应用架构的核心是啥：拆分子项目  

对项目进行功能划分，业务功能紧密的模块归类一个子项目，互不相干划分成另外一个模块。还是以电商系统为例子

1>电商系统(用户管理 商品管理 订单管理)

2>后台系统(用户管理 订单管理 客户管理)

3>CMS系统(广告管理 营销管理)

 后续，当电商系统需要优化时，可以垂直扩展(提高服务器性能)，也可以水平扩展(集群)

优点：

• 项目拆分流量做了分流，解决了并发问题，同时可以对模块进行针对性优化

• 一个子项目出问题不会影响到其他子项目，提高容错率

缺点：

• 子项目间相互独立， 无法进行相互调用

• 子项目间相互独立， 存在重复造轮子问题

分布式架构

上面垂直架构项目应对普通业务就差不多了，但是，当拆分后的子项目越来越多之后，重复的业务代码也会增多，这时就需要考虑一下要不要将重复的代码抽取出来，做成一个统一对外提供服务的子项目呢？有了这想法，那新的的架构模式就出来，分布式系统架构。

分布式架构核心：一样是拆分

分布式的拆分与跟垂直架构拆分不一样，垂直架构拆分维度依据是：业务功能的独立性，分布式的拆分维度依据是：业务重用性

 分布式系统架构。它将把项目拆分成表现层和服务层两个部分，服务层中包含业务逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。

优点：

• 抽取公共的功能为服务层，提高代码复用性

• 可以针对不同服务进行垂直与水平扩展

• 非常建立自动扩缩容机制，提高系统可用性

缺点：

• 系统间耦合度变高，调用关系错综复杂，难以维护

SOA架构

在分布式架构模式下，代码重用性得到保证，但是也引入新的问题：每个服务部署在不同的服务器中，如果需要交互该怎么办？如果某个服务宕机了，其他服务怎么感知？增加新服务器，怎么快速加入服务集群等。

上述问题，其实上面问题，归类起来就是一个问题：服务管理问题。如何做好服务管理呢？SOA架构引入如资源(服务)调度和助理中心，让它实现服务的统一管理。

 服务注册中心负责所有服务ip/端口管理

优点:

• 使用注册中心解决了服务间调用关系的自动调节

缺点:

• 服务间会有依赖关系，一旦某个环节出错会影响较大( 服务雪崩 )

• 服务关系复杂，运维、测试部署困难

微服务架构

上面的SOA架构还是存在问题，一个服务宕机会影响所有依赖该服务的其他服务，同时后期维护较为麻烦，那有没有更好的架构方式呢？答案是yes：微服务架构

微服务架构可以认为是SOA架构的升级版，对服务做了更细致的拆分。

优点：

• 服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展

• 微服务之间采用RESTful等轻量级Http协议相互调用

缺点：

• 分布式系统开发的技术成本高（容错、分布式事务等）

到这项目架构演变就差不多了，可以还有朋友说微服务不是还有缺点么？不是应该继续演变么？其实到这就可以了，没有完美的架构，综合考虑满足当前业务即可，这些缺点就是采用微服务架构必须承受的代价。

 看文字不过瘾可以切换视频版：SpringCloud Alibaba 极简入门