注册中心Nacos

1 主流注册中心对比

微服务治理系列二_分布式事务

2 CAP实践

微服务治理系列二_环境隔离_02

  • C是所有节点在同一时间看到的数据是一致的;而A的定义是所有的请求都会收到响应。何时选择使用何种模式?
  • 如果不需要存储服务级别的信息且服务实例是通过nacos-client注册,并能够保持心跳上报,那么就可以选择AP模式。当前主流的服务如 Spring cloud 和 Dubbo 服务,都适用于AP模式,AP模式为了服务的可能性而减弱了一致性,因此AP模式下只支持注册临时实例。
  • 如果需要在服务级别编辑或者存储配置信息,那么 CP 是必须,K8S服务和DNS服务则适用于CP模式。CP模式下则支持注册持久化实例,此时则是以 Raft 协议为集群运行模式,该模式下注册实例之前必须先注册服务,如果服务不存在,则会返回错误
  • nacos默认是AP。curl -X PUT ‘$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP’

配置中心Nacos:

1 bootstrap.yaml配置

  • Nacos同springcloud-config一样,在项目初始化时,要保证先从配置中心进行配置拉取,拉取配置之后,才能保证项目的正常启动。springboot中配置文件的加载是存在优先级顺序的,bootstrap优先级高于application

2 配置规则

微服务治理系列二_环境隔离_03{spring.profiles.active}.${spring.cloud.nacos.config.file-extension}

3 springcloud原生注解@RefreshScope+nacos动态刷新配置

@RestController
@RefreshScope //支持Nacos的动态刷新功能。
public class ConfigClientController
{
    @Value("${config.info}")
    private String configInfo;

    @GetMapping("/config/info")
    public String getConfigInfo() {
        return configInfo;
    }
}

4 配置版本回滚

nacos会记录配置文件的历史版本默认保留30天,此外还有一键回滚功能,回滚操作将触发配置更新

5 持久化存储到mysql

6 nacos集群配置

  • 需要配置cluster.conf集群ip
  • 配置每个nacos启动端口,application.conf
  • 用nginx反向代理多个nacos,生产环境keepalived+nginx做nginx容灾
  • spring boot应用配置nacos服务就配置nginx代理端口

服务调用与负载均衡 OpenFeign

1 open feign

  • OpenFeign是Spring Cloud 在Feign的基础上支持了SpringMVC的注解,如@RequesMapping等等。OpenFeign的@FeignClient可以解析SpringMVC的@RequestMapping注解下的接口,并通过动态代理的方式产生实现类,实现类中做负载均衡并调用其他服务。经测试spring cloud 2020.0.2nacos、open feign中已经移除了对ribbon的依赖,替换成了spring cloud原生的load balance

2 调用超时熔断

# feign 配置
feign:
  sentinel:
    enabled: true
  okhttp:
    enabled: true
  httpclient:
    enabled: false
  client:
    config:
      default:
        connectTimeout: 10000
        readTimeout: 10000
  compression:
    request:
      enabled: true
    response:
      enabled: true

3 open feign调用异常抽取

@FeignClient(contextId = "remoteUserService", value = ServiceNameConstants.SYSTEM_SERVICE, fallbackFactory = RemoteUserFallbackFactory.class)
public interface RemoteUserService {
    @GetMapping("/user/info/{username}")
    public R<LoginUser> getUserInfo(@PathVariable("username") String username, @RequestHeader(SecurityConstants.FROM_SOURCE) String source);
}

4 负载均衡

  • ribbon、load balance负载均衡是进程jvm的负载均衡(客户端的负载均衡,不是nginx、haprox服务端的集中式负载均衡)
  • load balance调用实际是用okhttp或者httpclient包

5 设置open feign调用详细日志

import feign.Logger;

@Configuration
public class FeignConfig{
@Bean
Logger.Level feignLoggerLevel() {
	return Logger.Level.FULL;
}
}

# yaml
logging:
level:
# feign日志以什么级别监控哪个接口
com.ruoyi.system.api.RemoteUserService: debug

分布式事务seata

1 核心概念

  • Transaction ID XID:全局唯一的事务id
  • Transaction Coordinator(TC):事务协调器,维护全局事务运行的状态,负责协调并驱动全局事务的提交或回滚
  • Transaction Manager(TM):控制全局事务的边界,负责开启一个全局事务,并最终发起全局提交或全局回滚的决议
  • Resource Manager(RM):控制分支事务,负责分支注册、状态汇报并接收事务协调的指令,驱动分支(本地)事务的提交或回滚

2 执行流程

  • TM 向 TC 申请开启一个全局事务,全局事务创建成功并生成一个全局唯一的 XID;
  • XID 在微服务调用链路的上下文中传播;
  • RM 向 TC 注册分支事务,将其纳入 XID 对应全局事务的管辖;
  • TM 向 TC 发起针对 XID 的全局提交或回滚决议;
  • TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。

3 原理

  • Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式,开源的使用AT模式对业务代码零侵入,只需要添加@Global Transaction
  • seata在数据库中依赖几张表:branch_table、global_table、lock_table、undo_log
  • 实例sql:update product set name = ‘GTS’ where name = ‘TXC’;
一阶段
  • 前提TM开启了全局事务,seata在global_table更新XID
  • 解析 SQL:得到 SQL 的类型(UPDATE),表(product),条件(where name = ‘TXC’)等相关的信息。
  • 查询前镜像:根据解析得到的条件信息,生成查询语句,定位数据。select id, name, since from product where name = ‘TXC’;
  • 执行业务 SQL:更新这条记录的 name 为 ‘GTS’。
  • 查询后镜像:根据前镜像的结果,通过 主键 定位数据。select id, name, since from product where id = 1;
  • 插入回滚日志:把前后镜像数据以及业务 SQL 相关的信息组成一条回滚日志记录,插入到 UNDO_LOG 表中。
  • 提交前,向 TC 注册分支:申请 product 表中,主键值等于 1 的记录的 全局锁 。
  • 本地事务提交:业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交。seata branch_table生成数据
  • 将本地事务提交的结果上报给 TC。
二阶段-回滚
  • 收到 TC 的分支回滚请求,开启一个本地事务,执行如下操作。
  • 通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。
  • 数据校验:拿 UNDO LOG 中的后镜与当前数据进行比较,如果有不同,说明数据被当前全局事务之- 外的动作做了修改。这种情况,需要根据配置策略来做处理,详细的说明在另外的文档中介绍。
  • 根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句:update product set name = ‘TXC’ where id = 1;
  • 提交本地事务。并把本地事务的执行结果(即分支事务回滚的结果)上报给 TC。
二阶段-提交
  • 收到 TC 的分支提交请求,把请求放入一个异步任务的队列中,马上返回提交成功的结果给 TC。
  • 异步任务阶段的分支提交请求将异步和批量地删除相应 UNDO LOG 记录。