Dubbo注册中心扩展，我造了个这样的轮子来冲KPI

hello大家好呀！

作为一名基础组件开发，服务好每一位业务开发同学是我们的义务（KPI）。

客服群里经常有业务开发同学丢来一段代码、一个报错，而我们，当然要微笑服务，耐心解答。

 有的问题，凭借多年踩坑经验，一眼就能看出；有的问题，看一眼代码也能知道原因，但有的问题，还真就光凭看是看不出来的，这时，只能下载代码，本地跑跑看了。

熟悉我的朋友都知道，我从事dubbo相关开（客）发（服）工作多年，所以我就来讲一个dubbo问题排查过程中的有趣的事。

通常遇到看不能解决的问题时，先git拉取代码，再导入IDEA，找到main方法点击启动，一顿操作下来，不出意外，肯定会有点小错误，比如这条：

Socket error occurred: localhost/127.0.0.1:2181: Connection refused

看到2181端口就知道这是本地没有装zookeeper（下文简称zk），问题不大，docker直接拉一个zk镜像，起个容器就完事。

随着这样的习惯日积月累，低配的Mac上相继跑了etcd、redis、mysql等等容器，重要的是还打开了N个IDEA窗口。

每当启动一个新的项目时，风扇呼呼地直接将IDEA卡死。

这时，我陷入了思考，能不能少跑点程序？

etcd、redis、mysql暂时搞不定，但dubbo的注册中心我熟啊！柿子当然要挑软的捏。

需求梳理

在开干之前，得先梳理一下需求，于是我脑子闪现出无数个在本地测试时遇到的与dubbo注册中心有关问题的瞬间，但仔细一捋，无外乎两种：

• 作为provider：最最最主要的就是不要阻断应用启动
• 作为consumer： 不要阻断应用启动 可以发现并调用本地的provider 可以调用远程的provider 可以手动指定调用任意provider

除了这两个功能上的需求，还得解决我们最初的问题：不要依赖第三方服务（如zk）。

调研

由于一开始就想到了利用dubbo注册中心扩展来实现这个功能，为了不重复造轮子，翻了一下dubbo源码，看看是否已经有相应的实现：

发现除了dubbo-registry-multicast之外都是依赖了第三方服务，所以这个multicast是啥呢？dubbo官方文档说的很清楚：

乍一看很符合我们的需求，但仔细一想，还是有几点不满足：

1. 不一定能发现远程的provi