服务应用突然宕机了?别怕,Dubbo 会帮你自动搞定这一切!

Published on with 0 views and 0 comments

某日中午,午睡正香的时候,接到系统的报警电话,提示生产某物理机异常宕机了,目前该物理机已恢复,需要重启上面部署的应用。

这时瞬间没有了睡意,登上堡垒机,快速重启了应用,系统恢复正常。本想着继续午睡,但是已经没有了睡意。

旁边的小师弟(我们叫他小灰吧)刚才在我们边上,目睹这一切,然后向我请教个问题。

小灰:

黑哥,刚才应用突然宕机,会不会对交易有影响啊?

小黑:

影响确实会有,不过也不大,就当时应用正在运行那些那些交易会受到影响。

小灰:

不对啊,我们现在系统架构是下面这样。

我们这次宕机的是业务逻辑层,那按照目前使用 Dubbo 轮询的负载均衡方式,不是还会有交易分发到宕机那台应用上,这些交易请求显然会异常。

运气差点,不是会有一半交易请求都会有问题吗?

小黑:

没错,我们的系统架构图确实如说的一样。

不过你说的这个问题,它是不存在的。

这是因为 Dubbo 内部会自动帮我们的摘除宕机的应用节点。

小灰:

啥?Dubbo 内部还有这功能啊?黑哥你给我讲讲原理呗!

小黑:

可以啊,不过讲这个原理之前,我们首先需要了解 Dubbo 服务注册发现流程。

我看你最近一直在看『深入理解 Apache Dubbo 与实战』,这本书确实不错,里面框架原理,代码细节都讲的很透彻。

你应该已经了解了 Dubbo 服务注册发现流程,那你先跟我简单讲讲原理吧。

小灰拿起纸笔,在上面画了个图:

Dubbo 服务注册发现流程

恩,我当前了解的还不是很深,那我先聊聊目前我知道的。

我们目前使用 ZooKeeper 当做服务注册中心,ZooKeeper 可以简单理解成是一个 KV系统,内部是一个树形的数据结构。

Dubbo 默认将会在 ZooKeeper 中创建一个四层的数据结构,从上到下分别为:

  • Root
  • Service
  • Category
  • URL

其中 Root 层是注册中心分组,默认命名为 dubbo。我们可以通过修改 <dubbo:registry> 中的 group 属性修改默认值,这样修改之后不同分组的 dubbo 服务不会互相影响,也不会互相调用,可以用于环境隔离。

接下来 Service 就是服务类的全路径,包括包路径。

Service 层下面就是 Category 层,这其中总共有四类目录(上面图形只画了两种),分别为:

  • providers:包含服务提供者 URL 元数据信息
  • consumers:包含消费者 URL 元数据信息
  • routers:包含消费者路由策略的 URL 元数据信息
  • configurators:包含动态配置元数据信息

最后一层就是具体 Dubbo 服务 URL,类似如下:

dubbo://2.0.1.13:12345/com.dubbo.example.DemoService?xx=xx

小黑:

没错,这个内部结构你理还是蛮清晰的么!

平常使用的情况下,我们重点关注 providers 以及 consumers 就好了。如果我们需要配置服务路由信息以及动态配置,那我们需要在 Dubbo-Admin 服务治理中心下发配置。这时 routersconfigurators 就会增加相关配置。

小灰:

嘿嘿😝,咱接下来讲服务注册流程。

当服务提供者启动之后,会向注册中心写入自己的元数据信息,其实就是在 providers 节点下创建一个 URL 节点(如果上级节点都不存在,将会逐层创建),存储值类似如下:

dubbo://10.10.11.22:20880/com.foo/BarService?key=value....

接着启动服务消费者,消费者第一次连接上 ZooKeeper 时,将会拉取provider 节点下所有服务提供者的 URL 信息,然后与相应的服务提供者建立连接。

同时服务消费者也会将自己信息注册到在 consumer 节点下,这个目的是为了服务治理中心(Dubbo-Admin)发现自己。

同时消费者将会在 provider 节点上注册一个 watcher ,当有新的服务提供者启动成功,provider 节点发生变更,ZooKeeper 将会推送变更信息给 Dubbo 服务,然后 Dubbo 将会重新建立与服务提供者的连接。

小黑:

你说的整个 Dubbo 服务注册发现流程没有什么问题,这里消费者与服务提供者建立的连接的流程,我们之前踩过一个坑,你有空可以看看 天啦噜!生产机器连接数飙升到上万,背后发生了什么?

另外,再考你一下:

服务节点变更时,ZooKeeper 推送 provider 下全量子节点数据给消费者吗?

小灰:

呀,难道不是吗?

小黑:

不是的。ZooKeeper 的 watch 机制目前只能推送节点变更信息,比如节点内容数据变更,监听节点下子节点列表变更等,具体如下图:

图片来自网络

进一步从 Zookeeper 客户端的源码上来看,watcher 回调通知内容最终转为 WatchedEvent

image-20200823204259983

这个类只有三个字段,所以是不会推送子节点列表数据过来。

小灰:

既然不是通过推送获取子节点列表的信息,那如何拿到变动子节点列表?

有了,在收到推送的时候,我们能获取到变动节点信息,然后我再拉取一下子节点的列表不就好了!

小黑:

没错,Dubbo 就是这么做的。

这一点我们可以具体看下 Dubbo 的源码,位于 CuratorZookeeperClient

画外音:下面的源码基于 Dubbo 2.6.7

图中标注的地方,Dubbo 通过拉取获取了字节点的全量数据,同时再次注册了一个 watcher

不过这么多,有个缺陷的,当微服务节点数量有很多的时候,全量拉取将会占用过多的内网带宽,很容易造成网络风暴。

上面我们讲到 Zookeeper 的这种方式,是一种典型的 Push 模式,对应的还有一种的模式为 Pull 模式,eureka 就是这种模式的典型的代表。

eureka 客户端就是通过定期轮询拉取数据,获取最新的变更数据。不过拉取模式也存在很大的劣势,如果轮询频率低,那么服务变更信息无法及时获取,如果轮率太高这就会增加注册中心的压力。

小黑:

服务发现流程这下我们已经搞明白了。如果有新增服务节点,Dubbo 消费者通过通知,然后再拉取全量的子节点列表,这样 Dubbo消费者就会新增与新的服务提供者连接,后续再通过负载均衡使用新的连接。

如果 Dubbo 服务提供者正常停止下线,那么他将会删除 ZooKeeper 上的自己注册的节点信息。删除之后 Dubbo 消费者第一时间收到了通知,通过拉取全量的子节点列表,然后通过比对,发现某个节点下线,然后删除之前简历的连接。这样后续,就不会再调用这个节点。

小灰:

恩,正常应用上下线,Dubbo 消费者可以感知到,但是像服务提供者宕机的情况,消费者是怎么感知到的?

小黑:

这一点,就与 Zookeeper 的自身特性有关了。

Zookeeper 中我们可以创建四种节点类型的节点:

  • 永久节点
  • 临时节点
  • 顺序节点
    • 永久节点
    • 临时节点

临时节点与永久节点唯一的区别在于,一旦 Zookeeper 客户端断开连接,Zookeeper 服务感知到之后就会自动删除临时节点。

Dubbo 服务提供者就是在 Zookeeper 注册了临时节点,如果服务提供者宕机了,临时节点自动被删除,后面的流程就跟 Dubbo 应用正常下线一样了。

小灰:

**すごい!**原来如此,这个设计 666 啊。

小黑:

其实应用宕机这种, Dubbo RPC 框架内部都可以自动帮我们处理,这种故障其实很好处理。但是如果碰到下面这这种情况:

  • 服务提供者与服务消费者网络隔离
  • 服务提供陷入缓慢

在服务消费者看来,服务提供者其实是「活着」,这是因为服务提供者与 Zookeeper 还是正常连接。

但是实际情况下,服务消费者其实已经不能正常调用服务提供者了,那这种情况就比较棘手了。

不过 Dubbo 内部也提供了解决办法。马上就上班了,也来不及讲了,我们后面再讨论!

小灰:

好的,黑哥!今天学到了!

黑哥🐂🍺!爱你~

帮助链接

  1. https://www.sofastack.tech/blog/sofa-registry-service-discovery-optimization/

本文首发于: https://studyidea.cn/dubbo-recover

欢迎关注我的公众号:程序通事,获得日常干货推送。如果您对我的专题内容感兴趣,也可以关注我的博客:studyidea.cn