微服务开发框架主流技术总结

前言

随着网络技术的高速发展，微服务架构开发也得到了足够的完善，这里我们主要总结一下目前微服务生态环境中所使用到的一些主要技术，知识点。

一.分布式微服务

微服务架构是一种架构模式，它提倡将单体架构程序划分成一组小的服务，服务之间互相协调、互相配合，对外形同一个系统。这里我们就用到了spring-cloud

spring-cloud

微服务架构工具集，提供了用于搭建微服务所需要的各种常见的模式的实现工具，比如说

1.服务发现 2.服务网关 3.负载均衡 4.服务容错……

二.服务发现—>nacos

服务之间需要通信，是指使用一个服务注册中心来记录分布式系统中的全部服务的信息，以便其他服务能够快速的找到这些已注册的服务。实际上就是服务调用 service call（远程方法调用RMI，远程过程调用RPC），也就是找到服务实例地址的过程。下面我们可以看一张图：

简单来说就是生产者服务启动时向服务注册表上报自己的信息，消费者向服务注册表拉取信息，服务注册表定时向生产者发送健康监测，实时检查状态。有变动的时候通知消费者，然后消费者在重新拉取，这里主要运用使用nacos。

三.负载均衡—>nacos

负载均衡：LoanBalance,意思是将负载（工作任务，访问请求）进行平衡、分摊到多个操作单元（服务器，组件）上进行执行。是解决高性能，单点故障（高可用），扩展性（水平伸缩）的终极解决方案。不同的策略针对不同的情况轮询，轮流访问不同的实例。也就是说，在分布式系统里，当我们的高并发请求，访问量，服务器压力过大，一台机器不能满足，我们就会采取把请求拆分到多个服务器共同承担访问压力，实现流量分发。

这里我们也提到一些Ribbon的内置策略，如下：

……

当然也还有一些其他的内置策略，这里我们就主要提到以上这几个。

四.声明式服务调用—>openfeign

这里我们主要讲到Openfeign

它是 Spring 官方推出的一种声明式服务调用与负载均衡组件，它具有 Feign 的所有功能，并在 Feign 的基础上增加了对 Spring MVC 注解的支持，例如 @RequestMapping、@GetMapping 和 @PostMapping 等。

原理：

1.Spring-AOP 创建代理类（client实现类）

2.反射

1).获取client上的注解，进一步获取到请求相关信息：请求方式、服务名、参数名、参数类型、返回值类型

2).根据请求信息生成服务调用代码（服务发现 ，负载均衡，服务调用……）

五.配置管理

当微服务部署的实例越来越多，达到数十、数百时，逐个修改微服务配置就会让人抓狂，而且很容易出错。我们需要一种统一配置管理方案，可以集中管理所有实例的配置。Nacos一方面可以将配置集中管理，另一方可以在配置变更时，及时通知微服务，实现配置的热更新。

每一个服务要拉取nacos中管理的配置，并且与本地的application.yml配置合并，才能完成项目启动，因此spring引入了一种新的配置文件：bootstrap.yaml文件，会在application.yml之前被读取。所以配置管理可以实现管理统一的公共依赖如：lombok，hutool，共享所有服务都需要的类，如：result,MallException……,以及统一所有项目的依赖版本。下面也可以大致用一张图解释一下：

六.分布式事务—>seata

在微服务架构中，分布式事务 般的解决办法就是两阶段提交或者三阶段提交，不管使用哪都存在事务失败，导致数据不 致的情况，关键时刻还得人工去恢复数据，这里涉及几个概念：

全局事务：分布式事务本身，由参与的所有分支事务组成

分支事务：单个服务内部的事务

事务协调者：TC Transaction Coodinator 协调各个分支事务，同时提交，同时回滚

事务发起者：TM Transaction Manager 事务管理者 发起全局事务

事务参与者：RM Resource Manager 资源管理者 参与全局事务，维护分支事务

两阶段提交–>

第一阶段：发起一个分布式事务，交给事务协调器TC处理，TC向多有的参与事务的节点发送处理事务操作的准备操作。所有的参与节点执行准备操作，所有的分支事务处理完后告知TC。

第二阶段：TC如果收到所有的分支事务提交都是完成，则全局事务提交，通知所有分支事务提交，TC如果有收到存在部分提交失败或者超时，则全局事务回滚，通知所有分支事务回滚。

常见的一些解决方案：

1.XA协议

多个数据库，同步打开事务，不提交，等待TC协调，等所有事务确认提交之后，再提交

，数据库事务是非常耗性能，加之网络通信时间较长，资源锁定的时间就比较长

2.TCC ： Try-Confirm-Cancel

优势：跟XA区别，所有的操作都是独立提交事务的，不存在事务等待问题，不会造成资源额外消耗

劣势：编码复杂度增加，代码量增加；接口需要拆分成TCC三个接口；所有业务需要重新设计和重写；

3.SAGAS

流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现

4.AT模式***

概念：AT模式是一种无侵入的分布式事务解决方案，在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。

一阶段：执行业务，seata代理数据源，拦截所有的数据库操作，获取到操作执行前后的数据镜像，生成insert SQL,插入到undo_log表中，最后加入到当前事务，提交

二阶段：正常提交，删除undo_log表中的记录，

异常回归：seata提取对应的undo_log表中的记录，计算生成回滚用sql，执行回滚SQL，提交事务

seata优势：没有额外的事务方面的性能消耗，资源消耗低，

七.服务网关

服务网关:,统一应用请求接口.网关在微服务们的最前端,让 网关变成由应用所发起的每个请求的入口，也就是说整个分布式系统的唯一入口。

功能：

ip黑白名单：封禁ip，允许哪些ip通过；

动态路由：可以根据不同的请求路由到不同的服务上. 也可以进行路由的版本控制，这样即使后服务发生了变化，Gateway 的路径依然可以不改变；

权限认证：客户端在与我们后端服务进行交互之前，由网关先进行登录鉴权操作，这是后端所有的服务都需要有的共有逻辑；

负载均衡：网关知道所有服务实例的地址，可以根据不同服务采取不同的负载均衡策略；

熔断，降级，限流:通过网关可以在监测到某个服务发生异常，或者当服务的流量超过服务的承载能力等情况时，可以采取相应的措施. 提高整个系统的容错性、稳定性等。

……

八.单点登录—>sa-token

Single Sign On –>SSO,指在同一帐号平台下的多个应用系统中，用户只需登录一次，即可访问所有相互信任的系统。简而言之，多个系统，统一登陆。这里主要运用sa-token去实现SSO。

原理：sso需要一个独立的认证中心，所有子系统都通过认证中心的登录入口进行登录，登录时带上自己的地址，子系统只接受认证中心的授权，授权通过令牌（token）实现，sso认证中心验证用户的用户名密码正确，创建全局会话和token，token作为参数发送给各个子系统，子系统拿到token，即得到了授权，可以借此创建局部会话，局部会话登录方式与单系统的登录方式相同。简单用一张图可以了解一下：

九.服务容错—->Sentinel

服务雪崩效应：

在分布式系统中,由于网络原因或自身的原因,服务一般无法保证 100% 可用。如果一个服务出现了问题，调用这个服务就会出现线程阻塞的情况，此时若有大量的请求涌入，就会出现多条线程阻塞等待，进而导致服务瘫痪。由于服务与服务之间的依赖性，故障会传播，会对整个分布式系统造成灾难性的严重后果，这就是服务故障的 “雪崩效应” 。

常见的容错思路有隔离、超时、限流、熔断、降级这几种

常见的容错组件：Hystrix,Resilience4j,Sentinel

Sentinel 是阿里巴巴开源的一款断路器实现，本身在阿里内部已经被大规模采用，非常稳定。

为了解决分布式系统的雪崩效应，分布式系统引进了熔断器机制。

当一个服务的处理用户请求的失败次数在一定时间内小于设定的阈值时，熔断器出于关闭状态，服务正常。

当服务处理用户请求失败次数在一定时间内大于设定的阈值时，说明服务出现故障，打开熔断器，这是所有的请求会快速失败，不执行业务逻辑

当处于打开状态的熔断器时，一段时间后出于半打开状态，并执行一定数量的请求，剩余的请求会执行快速失败，若执行请求失败了，则继续打开熔断器，若成功了，则将熔断器关闭

以上也就是我对整个分布式架构开发的部分知识点的整理，归纳！！！:）