注册中心Nacos
1 主流注册中心对比
主流注册中心对比
2 CAP实践
AP与CP
- 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 配置规则
{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 记录。
