微服务：雪崩（微服务保护）与分布式事务-优快云博客

(一)雪崩

1.什么是微服务雪崩：指微服务某一服务的生产者不能提供某一服务或者提供某一服务慢使得消费者该服务堆积耗尽消费者服务资源耗尽，在此之后由于微服务之间以链式拓扑结构进行调用每个消费者对应的若干个他们自己消费者就会收到影响递归的耗尽自己的资源几何式传递使接下来几乎所有微服务都不能使用

关于解决方案

根据上述首先可以想到某一服务资源量不足进而阻塞过度消耗那让他不要影响别的进程即可这就是线程隔离

2.第二个服务熔断 1说的服务堆积只要发生了消费问题就控制输入的请求即可走falback逻辑

3.在前两点基础上降低峰值流量带来的瞬间爆炸进行qps整形用限流处理即可

分别对应于讲师归纳的下图：

4.运行sentinel.jar 导入依赖就能拉起sentinel服务了这个东西监控的是接口调用情况因此未发生调用时候只显示自己

访问接口后界面如下

5 人话：sentinel会监控 controller调用接口它对应的传输链路的并发量但问题是这个路径相同时候没有区分具体接口

配置httpmodifyspecify属性

用jmeter打流进行性能测试感觉这玩意很慢 429 errcode 是限流自己请求被限制的意思

QPS = 并发线程数 * 单线程qps 也就是说线程隔离要防止的极端情况其实QPS是低的反之亦然

同时限制这两个事相当于整个雪崩的极大值极小值都被抹去了

6.线程隔离测试点击修改会显示查询失败原因是修改生效了只不过查询没法显示修改的效果

7.前面说的fallback逻辑在这用上了线程隔离相当于自断一臂保全大局但是太过惨烈用fallback修饰或者发一个普适性的结果才明白feign调用不属于簇点链路资源怪不得刚才打流都是针对于服务本身而不是级联服务甚至连网关都没走

通过别人造好的轮子一个工厂方法来定义后备client实例再想办法注册

这里fallback工厂对象要在配置类定义bean 因为配置类会被扫描在那里面注册bean对应的组件才会被拉起最后在对应的client Feign注解扫描fallback 工厂

8.配上这个 feigncvlient级联事务会被加入簇点也就是说对级联事务加留空最后返回一个同样的结果 fallback 保证子簇点被阻断时候查询不会过度占用资源卡死

总结来说限流针对某个服务本身防止其链路传入过多的请求线程隔离阻断高频服务子模块影响次数避免影响其他服务 fallback 使得阻断的子模块不会返回异常结果影响界面

1.fallback要将feign打开 sentinel 针对级联限流 2.然后定义fallback逻辑并放到配置类注册3.对应的client配置fallback工厂类.class+

9.关于服务熔断大概就是一个定时器定时放行检测耗资源率搞得线程并把它关掉返回fallback 也是在流控规则配的

（二)分布式事务

1.分布式事务大致是级联事务种中同一层次的分支事务相互不能感知导致有的事务成功了有的事务没成功要解决的方案就是用seta-tc去管理分支事务与全局事务

这玩意有tm，tc分别管理主干事务和分支事务大概是说主干事务从函数入口到确认完各分支事务结束为一个主干周期给TM配置入口出口配置 TM进行监控监控到主干异常通知TC回滚所有分支事务 TM看不到分支事务 tc通过rm获取分支状态

要搭建TC微服务引入seata依赖导入tc要基于来运行的sql数据和锁：

2.关于要配置的： seata这个东西本身跟n个微服务去相互通信因此要用nacos负载均衡注册+feign访问

类似yml的配置可以决定管理分布式时候用的数据来源这里的seata作为一个微服务部署在docker 由于和其他的不一样不是在本地因此网络如果不同访问不到nacos和数据库自然运行时候就会挂掉且无法和他们通信

可以用docker ps -a --format '{{.ID}}\t{{.Names}}\t{{.Networks}}'去查看已有容器的连接网络并通过 docker network connect [网络名] [容器名] 这样就能正常拉起也让我知道了上次errcode 255挂掉是因为和数据库/nacos连不上