本文转载自微信公众号《程序员DD》，作者翟永超。转载本文请联系程序员DD公众号。这几天在不同的微信群和社区遇到了一系列的问题：比如spring4all的帖子：http://bbs.spring4all.com/thread/21比如在Mr中进行了类似的问题秦氏集团昨天讨论。虽然描述不同，但核心都是围绕一个问题：多个不同注册中心下的服务治理问题！下面谈谈我对这个问题的思考、实践和建议。为什么会出现这样的场景？先说背景问题。有的群友看到这种问题，第一反应就是如何使用多个注册中心。是不是很头疼？明明有点脑子没人会这么做！那么为什么会存在这样的场景呢？通常是这样演变的：缺乏统一的基础技术平台管理，几乎所有的大型企业都会遇到这样的问题。对于业务野蛮发展时期，技术团队几乎没有精力去做这些治理。系统边界划分之后，因为系统与系统之间的交互要通过协议来定义和规范，所以各个系统内部的技术栈都是基于团队的，选择自己最擅长的，不做的需要统一快速高效的完成各个系统的建设。因此，不同的系统选择不同的注册中心来管理自己的服务并没有错。随着业务的发展，业务需要调整，架构需要演进，复杂的系统关系（过去自己开发的系统，自己收购的系统，从外部购买的系统）需要重构。无论是以微服务还是中台的方式重新定义系统边界，都需要对现有服务进行重新规划和管理。由于系统的复杂性，我们无法一步到位，只能一点一点地向改造目标转变。必然有一个新旧并存、逐渐转化的演进过程。为了能够平滑过渡转型过程，我们首先想到的是先统一服务治理，让所有内部服务能够轻松便捷地相互发现、相互调用。同时，各种注册中心带来的运维复杂性也可以通过统一的服务治理体系来解决。所以，这里就是文章开头讨论的场景。所以，这是架构演进的产物，而不是因为设计不好而冒出来的奇葩架构。统一服务治理的两种思路。方案一：在业务服务器端，实现多个注册中心的注册和发现。这个方法是第一个，大家提出的问题的解决方案，这个方案的实现涉及到几个核心问题的解决：服务注册扩展：我们知道SpringCloud的注册机制是针对单一注册中心的，匹配的发现是一样的。我们无法通过配置一组额外的服务发现接口实现来实现多个注册中心。因此，需要使用一套主注册中心作为SpringCloud自身的Bean实现，需要学习多套（根据注册中心数量）来注册客户端实现。服务发现的扩展：如果对非主注册中心实现了一套注册操作，那么也必须实现一套发现机制。同时，由于这里的服务发现没有绑定SpringCloud的服务发现机制，所以这些服务不会进入SpringCloud配置的注册中心下的ServiceList和对应的ServerList。因此，在服务发现模块中，需要将从这些外部注册中心获取的服务和实例添加到主注册中心下的ServiceList和ServerList中。同时，这里有几点需要注意：因为业务服务是在各个注册中心注册的，所以发现的时候会有重叠，所以这里一定要做好去重工作。服务名称的管理也需要保护。不同系统下的用户中心等一些服务名称容易冲突。您可以使用系统代码作为前缀来处理服务名称，以确保集成后不会出现重复。通过这样的操作，每个业务服务都与所有的注册中心建立了联系，原本在不同系统中的各种服务也可以相互发现和调用。方案二：在注册中心之间同步业务数据。该方法是创建一个注册中心同步服务。它的任务很简单，就是将各个注册中心的服务信息同步到其他注册中心。同时监控各个注册中心的变化，使所有系统下的所有服务都处于不同的注册中间。这样的话，只要是SpringCloud搭建的业务服务，只需要逐步替换注册中心的依赖，就可以很方便的将原本在不同注册中心下的服务转移到同一个注册中心下的服务上。注册中心。.两种方式的优缺点上面两种方案的优缺点对比如下：方案一优点方案二优点无需增加部署成本业务服务侵入性小缺点业务服务侵入性较大，需要增加部署成本当然，对于解决方案2也会有一些并发症。如果对注册过程有一些特殊的定制，则需要一些扩展兼容性。但是相比于方案一的改造程度，业务应用侧的逻辑复杂度植入是非常小的。同时，因为需要统一服务治理，事后的最终状态往往只有注册中心想集中维护。此时。如果采用第一种方案，需要重新调整注册和发现机制，去除待淘汰的注册和发现逻辑更加复杂。因此，对这两种方法进行综合比较。个人认为第二种方案，同步注册中心的数据，完成统一服务治理的任务，比第一种方案更安全，对业务发展影响最小。尽管会引入一些部署成本，但这些成本对于多系统基础而言是最小的。原文链接：https://mp.weixin.qq.com/s/7_K7-vw2Yu7ByjyqGcLGYw
