微服务治理系列二_架构师老狼

网络投稿 02-07 4259

注册中心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<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：全局唯一的事务idTransaction 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 Transactionseata在数据库中依赖几张表：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 记录。