服务应用突然宕机了？别怕，Dubbo 会帮你自动搞定这一切！

楼下小黑哥小黑十一点半

听说猫猫可以增加点击量~
某日中午，午睡正香的时候，接到系统的报警电话，提示生产某物理机异常宕机了，目前该物理机已恢复，需要重启上面部署的应用。

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

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

「小灰：」

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

「小黑：」

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

「小灰：」

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

我们这次宕机的是业务逻辑层，那按照目前使用 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」层，这其中总共有四类目录（上面图形只画了两种），分别为:

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

「小黑：」

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

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

「小灰：」

嘿嘿

更多相关文章