某日中午，午睡正香的时候，接到系统的报警电话，提示生产某物理机异常宕机了，目前该物理机已恢复，需要重启上面部署的应用。
这时瞬间没有了睡意，登上堡垒机，快速重启了应用，系统恢复正常。本想着继续午睡，但是已经没有了睡意。
旁边的小师弟（我们叫他小灰吧）刚才在我们边上，目睹这一切，然后向我请教个问题。
小灰：
黑哥，刚才应用突然宕机，会不会对交易有影响啊？
小黑：
影响确实会有，不过也不大，就当时应用正在运行那些那些交易会受到影响。
小灰：
不对啊，我们现在系统架构是下面这样。
我们这次宕机的是业务逻辑层，那按照目前使用 dubbo 轮询的负载均衡方式，不是还会有交易分发到宕机那台应用上，这些交易请求显然会异常。
运气差点，不是会有一半交易请求都会有问题吗？
小黑：
没错，我们的系统架构图确实如说的一样。
不过你说的这个问题，它是不存在的。
这是因为 dubbo 内部会自动帮我们的摘除宕机的应用节点。
小灰：
小黑：
可以啊，不过讲这个原理之前，我们首先需要了解 dubbo 服务注册发现流程。
我看你最近一直在看『深入理解 Apache 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 服务治理中心下发配置。这时 routers 与 configurators 就会增加相关配置。
小灰：
嘿嘿
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
