微服务保护和分布式事务
一、微服务保护
1.雪崩
某一个微服务出问题,导致整个服务出问题
问题来源:
服务提供者出现故障或者阻塞
服务调用着没有处理好异常
1.1请求限流
原因:并发请求太高了,导致故障
解决:类似于漏斗,对于服务提供者,限制每秒访问的次数QPS
1.2线程阻塞
原因:当一个服务访问时间长并且并发高,耗尽服务器线程资源,导致其他访问接口出现问题
类似于船舱,把每个微服务单独隔离放在一个盒子里,当一个出问题时,不影响其他,但没有对异常问题进行处理,后续可以用fallback进行处理
1.3服务熔断
虽然线程隔离避免了雪崩,但是出现服务故障的这个问题依旧没有解决,会拖垮依赖这个故障服务的其他服务
当发现某一个服务访问过于缓慢或者经常出错,就断开对该服务访问
2.Sentinel解决
2.1.下载jar包
sentinel-dashboard.jar包,运行Java -jar xxx.jar
java -Dserver.port=8090 -Dcsp.sentinel.dashboard.server=localhost:8090 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard.jar
访问http://localhost:8090页面,就可以看到sentinel的控制台了
2.2.导入依赖
<!--sentinel-->
<dependency><groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
2.3.配置yaml
spring:cloud:sentinel:transport:dashboard: localhost:8090http-method-specify: true
因此可以进入页面去设置规则来进行测试
2.4.fallback
首先创建一个fallback类继承FallbackFactory工厂,重新里面的方法啊,进行服务降级处理,一般是写到日志
@Slf4j
public class ItemClientFallback implements FallbackFactory<ItemClient> {@Overridepublic ItemClient create(Throwable cause) {return new ItemClient() {@Overridepublic List<ItemDTO> queryItemByIds(Collection<Long> ids) {log.error("查询商品信息失败", cause);return CollUtils.emptyList();}@Overridepublic void deductStock(List<OrderDetailDTO> detailDTOS) {throw new BizIllegalException(cause);}};}
}
其次bean注入
@Beanpublic ItemClientFallback itemFallbackFactory() {return new ItemClientFallback();}
最后在openFegin的注解上加上fallbackFactory
Caused by: java.lang.IllegalStateException: Incompatible fallback instance. Fallback/fallbackFactory of type class com.hmall.api.client.fallback.ItemClientFallback is not assignable to interface com.hmall.api.client.ItemClient for feign client item-service
二、分布式事务
1.seata分布式事务框架
1.运行seata.sql创建seata数据库 2.下载seata文件,拉取jar包,docker运行部署 3.配置nacos的共享文件shared-seata.yaml 4.pom文件导入seata的依赖 5.在yaml文件加入共享文件配置
2.1.XA
一阶段:
RM创建分支到TC
RM运行sql,但不提交
RM报告执行状态到TC
二阶段:
TC查看所有运行状态
成功提交
失败回滚
2.2.AT
一阶段:
RM创建分支到TC
保存快照undo_log
RM运行sql并提交
RM报告执行状态到TC
二阶段:
成功,删除快照
失败:回滚快照
2.3 XA与AT区别
XA中,RM运行sql,但不提交,最后统一提交,强一致性,但是耗时长,性能差
AT中,RM运行sql并提交,失败回滚快照,最终一致性,性能好,但是可能出现短暂的读脏数据