架构思想之-高可用场景怎么做服务的故障发现,故障恢复

从现有的一套微服务开始

在这里插入图片描述

简述一下上面流程

  1. 各个订单服务向zk (这里只是注册中心,也可以是eurake、consul、nacos等)注册自己的服务。注册的时候其实就是上报当前服务的ip:port:name等
  2. 网关(服务的消费方)watch zk的节点,就能感知到那些服务注册进来了
  3. 网关层可以通过zk拿到下游服务的基本属性,然后向每个服务建立长连接。即可

简单思考一下上面这一套有什么问题?

  1. 如果服务A挂了怎么办?难道网关还一直向他发请求?
  2. 那如果服务A只是假死怎么办?(例如发生了死循环)
  3. 服务A出故障了怎么让他恢复?
  4. 服务A恢复了网关又怎么感知到?

基于以上问题我们一个个来分享处理思路。

1. 如果服务A挂了怎么办?难道网关还一直向他发请求?网关怎么知道服务A挂掉了?

假设服务A是真的死了(机器都挂了等)。其实服务A与zk之间是有保持心跳的。默认每3s发送一次心跳。当zk连续2次没有发送心跳,我们就认为这台服务真的挂了。那么那么服务A在zk上注册的节点(临时节点)就会消失。自然网关层就能watch到。就可以在本地把连接服务A的长连接踢掉即可。
但是在这6s钟期间,我们网关其实是不知道服务A挂了。那这时候就要依靠网关层自己要做好一些熔断/降级/重试机制,即快速将请求失败返回。或者转移到另外一台服务上。

2、那如果服务A只是假死怎么办?(例如发生了死循环)

例如,你的用户程序发生了死循环,但是整个进程并没有挂掉。此时zk心跳肯定还是能保持的。也就是说没法依靠zk的心跳机制来帮我们实现。此时我们可以让上层服务(网关)来帮我们实现。
例如:网关那边每次请求服务A时,保存几秒中的请求返回信息。每隔1s统计一下该服务的正确率。如果错误率达到一定比例。上层服务(网关)可以帮忙去删除服务A在zk上注册的信息。

3、服务A出故障了怎么让他恢复?

上面讲到上层服务(网关)帮服务A,注销服务了。那么服务A不可能一直让他挂着肯定得重启它,让他恢复啊。
例如:如果服务真的宕机了。那么直接重启就完事。
但是假死的情况就得自己来完成了。上面说到网关会帮服务A注销。服务A自己肯定也能感知到自己被注销了(假死,那zk客户端肯定也是在的)。所以就得依靠zk客户端来帮我们重启这个服务。
步骤:

  1. jstack 3次(每次隔几秒)
  2. sleep 6s以上( 不一定必须)
  3. kill 进程
  4. start 服务
    思考:为什么要这么做?后面来讲。

4、网关怎么知道服务恢复了呢?

这个就比较简单了。服务A重启后,重新注册到zk上。其他上层系统自然就能感知到了。

解答:

为什么要jstack?为什么是3次?

jstack 是为了保留上次故障的线程栈。为了后面复盘问题。
3次并且每次 还隔几秒。其实是为了保留对照。例如:死循环,对照3次立马就可以看到线程是不是停在同一个方法上。

为什么要sleep 6秒?

如果如果上游系统没有帮我们删除节点的话。就可以通过sleep 6s ,主要是为了断掉心跳。主要是因为zk心跳3s,2次才会被认为服务挂了。

完整流程:

在这里插入图片描述

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

七层汉堡王

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值