微服务治理系列二

微服务治理系列二 注册中心Nacos 1 主流注册中心对比

2 CAP实践

• 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 配置规则

s p r i n g . a p p l i c a t i o n . n a m e − {spring.application.name}- spring.application.name−{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 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 记录。