假设有一个遗留的Dubbo系统,现在想改用Spring Cloud。
由于遗留Dubbo系统比较庞大,短期之内无法完成技术栈的迁移。因此需要“分步走”,即:初期实现两者共存,后期逐步绞杀Dubbo应用,最终实现技术栈的统一。
p.s. 这里并没有贬低Dubbo的意思,仅是按照该场景讨论。
架构迁移、技术栈更换、项目重构时的第一步往往不是“改造”,而是“停止修改”。基于这个原则,个人不太倾向于去立即大幅重构Dubbo应用原先的代码。原因有二:首先是原则问题,更重要的是时间成本、技术风险很难得到控制。
而,假如新编写的Spring Cloud应用去进行迁就,例如:
考虑到一般来讲,遗留系统的改造过程中一般都是新系统调用老系统,很少出现老系统大规模调用新系统的场景(至少我这边目前是这样^_^)。因此,笔者列出几种仅需少量的代码编写成本即可实现Spring Cloud与Dubbo短期/长期共存,并且侵入性较小,同时还允许我们改造遗留Dubbo系统的几种方案,算是抛砖引玉。期待朋友们提出更优雅、成本更小的方案。
优点:架构不依赖Eureka或其他服务注册组件,借助Ribbon去调用Dubbo微服务暴露的RESTful API;
缺点:如果Dubbo微服务较多时,均需手动配置,不适合新式的部署环境(例如Docker,因为每次部署IP/端口可能都不同)
使用Sidecar,Dubbo微服务必须实现健康检查(对于Spring Boot程序即:添加spring-boot-starter-actuator依赖)。
优点:
缺点:
将Dubbo应用也注册到Eureka上。
优点:
缺点:
本项目中几个Demo中,都是手动编码为Dubbo应用开放RESTful API的,实际迁移过程可以借助cglib或者lombok之类的工具,实现从Dubbo接口道RESTful API的转换。本仓库主要还是为大家提供思路,不做具体讨论。
Spring Cloud QQ交流群:564840207、157525002(已满)
实体书《Spring Cloud与Docker微服务架构实战》上线啦!
亚马逊购书链接:
实体书配套代码:http://www.itmuch.com/advertisment/my-spring-book-code/
个人公众号:
Spring Cloud中国社区公众号:
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。