微服务全流程分析 .pdf

微服务全流程分析

转眼已经2020，距离微服务这个词落地已经过去好多年！（我记得2017年就听过这个词）。然⽽今天我想想什么是微服务，其实并没有⼀

个很好的定义。为什么这样说，按照微服务的定义：

微服务架构就是将⼀个庞⼤的业务系统按照业务模块拆分成若⼲个独⽴的⼦系统，每个⼦系统都是⼀个独⽴的应⽤，它是⼀种将

应⽤构建成⼀系列按业务领域划分模块的，⼩的⾃治服务的软件架构⽅式，倡导将复杂的单体应⽤拆分成若⼲个功能单⼀、松偶

合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发，及持续集成与交付活动。

根据这个定义，不难看出其实就是对复杂的业务系统统⼀做逻辑拆分，保持逻辑上的独⽴。那么逻辑上独⽴就是⼀个服务这样做真的是好

吗，如何界定：⼩、独，还有要做⼀个事情，完成单⼀的业务，单⼀的功能要拆分出来，为了独⽴⽽独⽴会不会导致拆的过细？不同⼈有不

同的见解，我们今天⼀起探讨微服务的过去和未来。

微服务缘起

在没有微服务之前，我们最早的架构模式就是MVC模式，把业务逻辑分为：表⽰层，业务逻辑层，数据访问层。MVC模式随着⼤前端的发

展，从⼀开始的前后端不分离，到现在的前后端分离逐渐演进。这种演进好的⼀点是剥离了不同开发语⾔的开发环境和部署环境，使得开发

较为便利，部署更直接。然⽽问题是：这种模式仍然是单体应⽤模式，如果有⼀个改动需要上线，你不得不因为这个改动去考虑更多，因为

你⽆法估量在这么⼤体量的代码中你的⼀个改动会不会引发蝴蝶效应。

另外很重要的⼀点就是移动互联⽹时代的到来，引发了⽤户数⼏何倍数暴增，传统的单体应⽤模式已经⽆法⽀撑⽤户量暴涨的流量冲击，互

联⽹⼈不得不做出加机器的⽆赖之举，然⽽发现有的时候加机器都⽆法搞定问题，因为逻辑调⽤过于耦合导致调⽤链复杂。继⽽出现精简调

⽤流程，梳理调⽤路径的举措，于是演变出微服务这个概念。

其实在没有微服务这个词出现之前，我们也是这样⼲的，只是⼲的不彻底⽽已。⽐如说有⼀个信贷系统，信贷系统分为贷前，贷中，贷后三

步：

在微服务未出现之前，我们⼤多是单体应⽤，基本上⼀个⼯程包含所有，⽆所不能，所以很臃肿上。述这些模块应该都是在⼀个⼯程中，但

是按照业务做了代码上的拆分。另外就是RPC框架并为横空出世，如果有服务上的拆分，⽐如不同部门之间调⽤对⽅提供的服务，那么⼋

九不离⼗肯定定义的是HTTP接⼝，因为通⽤。但是某些时候⼤家⼜怕HTTP接⼝性能差，关键服务不敢⽤。

微服务出现之后，⼤家觉得按照模块分别部署好像是这么回事，同时默默在⼼⾥嘀咕，以前我只⽤发布⼀个⼯程，现在倒好，可能有个改动

涉及3个服务，我⼀个⼩⼩的改动就要发布3次，是不是增加了⼯作量，另外我以前都不⽤调接⼝的，现在依赖了⼀堆别的系统，系统调⽤这

么复杂，万⼀别的系统有问题，我岂不是就被耽搁了！

在这种质疑中⼤家虽有抱怨但是也没有放弃赶时髦，微服务开展的如⽕如荼，⽤户中⼼独⽴部署，风控系统单独成型，⽀付中⼼全公司统⼀

独⽴，财务系统不再各个业务各⾃为战⽽是统筹公司各个业务线统⼀规划。按照业务抽象独⽴之后，⼤家发现好像是这么回事，⽤起来真

⾹。虽然每次需要别的模块的时候就需要找对应模块进⾏接⼊，但是业务逻辑上清晰了呀，如果出了问题，不是⾃⼰的，那就是别⼈的，甩

锅很⽅便的（笑）。

如何做微服务

因为微服务是功能粒度上的拆分，必然导致拆分之后的模块变多。针对模块与模块之间的通信与维护，⼜演变出如下问题：

模块与模块之间如何通信；

每个被拆分的微服务如何做负载均衡；

服务如何做注册，如何做发现；

服务之间调⽤如何做限流，服务调⽤失败如何做降级，流量异常如何做熔断；

服务调⽤是否可以做统⼀的访问控制；

针对这些问题，业界也在发展中慢慢演进出⼏套通⽤的框架。理想中微服务框架应该具备这样的能⼒：

基于上述微服务框架应该具备的能⼒，我们来分析⽬前可以落地的微服务框架的具体实现。

⽬前国内⽤的最多的⽆外乎是两套框架：Dubbo，SpringCloud。Dubbo⼤家都很熟悉，从开源到⽆⼈维护再到重新冲击Apache顶级项

⽬。但是Dubbo更加准确来说是⼀个分布式服务框架，致⼒于提供⾼效的RPC远程服务调⽤⽅案以及SOA服务治理⽅案。说⽩了就是个分

布式远程服务调⽤框架。

Dubbo

从Dubbo官⽹给的图来看Dubbo的整体架构：

模块注解：

Provider:暴露服务的服务提供⽅。

Consumer:调⽤远程服务的服务消费⽅。

Registry:服务注册与发现的注册中