这几天在不同的微信群和社区里连续碰到了类似的问题:
比如spring4all的帖子:http://bbs.spring4all.com/thread/21
又比如今天在秦总的群里也进行了类似的讨论。
虽然描述不同,但核心都围绕着一个问题:两个不同注册中心下的服务要如何互相调用?
下面就针对这个问题,展开说说我的思考、实践与建议。
先来说说背景问题,有的群友在看到这类问题的时候,第一反应就是怎么用多个注册中心,是不是蛋疼了瞎搞的?
显然有点脑子的人都不会这样做!那么为什么会存在这样的场景呢,通常都是这样演变而来的:
于是,就有了文首大家讨论的这种场景。所以,这是一个架构演进的过程产物,并不是设计不好才出来的怪胎。
方案一:在业务服务端,实现多注册中心的注册与发现
这种方式就是文首,大家所提问题的方案,实现这种方案涉及几点核心问题的解决:
服务发现的扩展:对于非主注册中心的注册操作实现了一套,那么发现机制也要实现一套。同时,因为这里的服务发现,并不与Spring Cloud的服务发现机制绑定,所以这些服务并不会进入到Spring Cloud配置的注册中心下的ServiceList和对应的ServerList里。所以在服务发现模块,需要自己把这些外部注册中心获取的服务和实例加入到主注册中心下的ServiceList和ServerList里。同时,这里需要注意的几个点:
通过这样一顿操作,每个业务服务与所有注册中心都建立了联系,原本处于不同系统的各种服务也都能互相发现并实现互相调用了。
方案二:在各个注册中心之间,实现服务数据的同步
这种方法是新建一个注册中心同步的服务,它的任务很简单,就是把每个注册中心上的服务信息同步到其他注册中心上,同时监听每个注册中心的变化以保持所有不同注册中间都包含了所有系统下的服务。
在这种情况下,只要是Spring Cloud构建的业务服务,那么就只需要逐步的更换注册中心的依赖,就能轻松的把原本处于不同注册中心下的服务,转移到同一注册中心下的服务了。
上面所述两种方案的大致优缺点如下:
| |方案一|方案二|
|---|---|---|
|优点|不需增加部署成本|业务服务侵入性小|
|缺点|业务服务侵入性大|需要增加部署成本|
当然,对于方案二也会有一些复杂情况,如果对注册过程有一些特殊定制的,会需要做一些扩展兼容。但比起第一种实现方式来说,在业务应用侧的逻辑复杂度植入是非常小的。
同时,因为要统一服务治理,那么事后最终状态往往就是只保留最后想要集中维护的注册中心的,这个时候。如果采用第一种方案,那么势必还要去重新调整注册与发现机制,将要淘汰的注册与发现逻辑去除,又是一件比较复杂的事情。
所以,综合比较这两种方法方法来说。个人认为采用方案二,同步注册中心的数据来完成统一服务治理的任务,要比方案一更加稳妥,对于业务开发的影响面最小。虽然会引入一些部署成本,但这些成本对于一个多系统的基础下,那是微乎其微的。
那么,大家是否有碰到类似的问题呢?又有什么好的方案呢?留言一起讨论下吧!如果你想与更多有趣的灵魂碰撞,也可以加入我们的技术交流群一起探讨我们的技术人生!
欢迎关注我的公众号:程序猿DD,分享其他地方看不到的知识与思考
本文在github做了收录 https://github.com/Michael-lz... 在类电商类项目,往往...
第1步:制作菜单外貌 在Dreamweaer 中新建一个文件,绘制一个层,在该层中插入一...
Bit-map的基本思想就是用一个bit位来标记某个元素对应的Value,而Key即是该元素...
热门版本类型推荐 下载地址 Dreamweaver MX 2004 官方简体中文专业版 点击进入下...
盒子模型的计算 外边距(margin)+边框(border)+内边距(padding)+内容(content) 在...
工作中遇到如下需求,点击输入框弹出自定义弹窗,输入框是input标签: 但是在移...
本文译自博客Usability Counts,译者@C7210 。原文作者Patrick Neeman是用户体验...
手机浏览器是把页面放在一个虚拟的窗口(viewport)中,通常这个虚拟的窗口(vie...
Html代码 : 复制代码 代码如下: td align="center" valign="middle" img src="im...
单行: div { /* 单行溢出隐藏 */ width: 150px; white-space: nowrap; overflow...