这几天在不同的微信群和社区里连续碰到了类似的问题：

比如spring4all的帖子：http://bbs.spring4all.com/thread/21

又比如今天在秦总的群里也进行了类似的讨论。

虽然描述不同，但核心都围绕着一个问题：两个不同注册中心下的服务要如何互相调用？

下面就针对这个问题，展开说说我的思考、实践与建议。

为什么会有这样的场景？

先来说说背景问题，有的群友在看到这类问题的时候，第一反应就是怎么用多个注册中心，是不是蛋疼了瞎搞的？

显然有点脑子的人都不会这样做！那么为什么会存在这样的场景呢，通常都是这样演变而来的：

1. 缺少统一的基础技术平台管理，几乎所有做大的企业都会碰到这样的问题。为了业务野蛮发展的时期，技术团队是很少有精力去做这些治理的，通过系统边界划分好之后，因为系统与系统间的交互通过协议定义规范就好，每个系统内部的技术栈根据团队特性选择自己最擅长的就行，并不需要去统一就能又好又快的去完成各个系统的建设。所以，不同的系统选择不同的注册中心来治理自己的服务，并没有什么不妥。

2. 随着业务的发展，业务需要调整，架构需要进化，复杂的系统关系（以往我们自己开发的系统，并购进来的系统，外部采购的系统）需要被重建。不论是以微服务的方式，还是中台的方式去重新划分系统边界，势必要对现有服务做重新规划与治理。

3. 由于系统复杂，我们没法一步就位，只能一点点的往改造目标去转变。势必会存在一个新老共存，逐步转化的演进过程。为了能够平滑的过渡改造的过程，我们第一个想到的就是先把服务治理统一起来，让所有内部服务都可以简单和便捷的发现彼此并能够互相调用。

于是，就有了文首大家讨论的这种场景。所以，这是一个架构演进的过程产物，并不是设计不好才出来的怪胎。

两种统一服务治理的思路

方案一：在业务服务端，实现多注册中心的注册与发现

这种方式就是文首，大家所提问题的方案，实现这种方案涉及几点核心问题的解决：

1. 服务注册的扩展：我们知道Spring Cloud的注册机制是对单注册中心的，同时配套的发现也一样。我们并不能通过多配置一套服务发现接口的实现来实现多注册中心的实现。所以，你需要以一套主注册中心为Spring Cloud自身的Bean实现，外围需要另外去学多套（根据注册中心数量）注册客户端的实现。

2. 服务发现的扩展：对于非主注册中心的注册操作实现了一套，那么发现机制也要实现一套。同时，因为这里的服务发现，并不与Spring Cloud的服务发现机制绑定，所以这些服务并不会进入到Spring Cloud配置的注册中心下的ServiceList和对应的ServerList里。所以在服务发现模块，需要自己把这些外部注册中心获取的服务和实例加入到主注册中心下的ServiceList和ServerList里。同时，这里需要注意的几个点：

• 因为业务服务往每个注册中心里都注册了，所以在发现的时候，是会有重叠的，这里要做好去重。
• 对于服务名称的管理也需要防重，不同系统下有一些比如用户中心之类的服务命名是很容易冲突的。通常可以把系统编码做前缀来加工服务名，以保证融合后不存在重复的出现。

通过这样一顿操作，每个业务服务与所有注册中心都建立了联系，原本处于不同系统的各种服务也都能互相发现并实现互相调用了。

方案二：在各个注册中心之间，实现服务数据的同步

这种方法是新建一个注册中心同步的服务，它的任务很简单，就是把每个注册中心上的服务信息同步到其他注册中心上，同时监听每个注册中心的变化以保持所有不同注册中间都包含了所有系统下的服务。

在这种情况下，只要是Spring Cloud构建的业务服务，那么就只需要逐步的更换注册中心的依赖，就能轻松的把原本处于不同注册中心下的服务，转移到同一注册中心下的服务了。

两种思路的优缺点比较

上面所述两种方案的大致优缺点如下：

当然，对于方案二也会有一些复杂情况，如果对注册过程有一些特殊定制的，会需要做一些扩展兼容。但比起第一种实现方式来说，在业务应用侧的逻辑复杂度植入是非常小的。

同时，因为要统一服务治理，那么事后最终状态往往就是只保留最后想要集中维护的注册中心的，这个时候。如果采用第一种方案，那么势必还要去重新调整注册与发现机制，将要淘汰的注册与发现逻辑去除，又是一件比较复杂的事情。

所以，综合比较这两种方法方法来说。个人认为采用方案二，同步注册中心的数据来完成统一服务治理的任务，要比方案一更加稳妥，对于业务开发的影响面最小。虽然会引入一些部署成本，但这些成本对于一个多系统的基础下，那是微乎其微的。

那么，大家是否有碰到类似的问题呢？又有什么好的方案呢？留言一起讨论下吧！如果你想与更多有趣的灵魂碰撞，也可以加入我们的技术交流群一起探讨我们的技术人生！

欢迎关注我的公众号：程序猿DD，分享外面看不到的干货！