遗留系统的服务拆分
我们正在书写、即将面对、正在面对遗留系统。在与遗留系统的相爱相杀中,需要我们基于项目目标和现状、结合过往经验、经过剪裁和取舍,才能迎面不断出现的挑战。
技术链接、资讯与社区分享流
我们正在书写、即将面对、正在面对遗留系统。在与遗留系统的相爱相杀中,需要我们基于项目目标和现状、结合过往经验、经过剪裁和取舍,才能迎面不断出现的挑战。
我们选择了 CDC 模式将遗留系统中产生的变化同步到新服务中。在同步过程中,由数据层的变化推导出业务意图是成功的关键。在其他运用绞杀模式的改造中,如果能够在更上层的地方做分支也是一种好的思路,这样可以更好地还原业务。
一半以上的新项目,都始于交接。交接期有长有短,交接形式多种多样。不管怎样,从客户关系、团队工作方式等各方面,交接期都奠定了项目进入稳定交付或维护期的基调。
数据库重构和代码重构有相似之处,也有不同之处。相似之处在于修改的过程中基本的思路是一致的,测试->修改->测试,小步快跑,反复迭代。不同之处在于拆库还依赖于硬件的基础设施,这就更要求测试环境尽量去模拟生产环境。
我们的项目整体来看算得上一个比较大型的项目,整个项目规划完成后有 17 条业务线。但是在刚起项目的时候由于种种原因并没有考虑周全,将项目当成一个普通的前端项目来解决,在第一期项目结束,第一条业务上线后,我们紧接着开始了第二和第三条业务线的开发,紧接着我们就遇到了一些问题.....
微服务拆分是微服务架构绕不过的话题,随着架构演进,在迭代开发中拆分微服务有时非常必要,微服务拆分不仅仅是一项技术层面的重构,首先要选择的合适的时机,另外在拆分前一定要理清业务现状,制定好拆分的基本原则,以指导后续拆分的过程。
对于服务拆分的逻辑来说,是先设计高内聚低耦合的领域模型,再实现相应的分布式系统。服务的划分有一些基本的方法和原则,通过这些方法能让微服务划分更有操作性。最终在微服务落地实施时也能按图索骥,无论是对遗留系统改造还是全新系统的架构都能游刃有余。
在 2016 年 11 月份的《技术雷达》中,ThoughtWorks 给予了微服务很高的评价。同时,也有越来越多的组织将实施微服务作为架构演进的一个必选方向。只不过在拥有众多遗留系统的组织内,将曾经的单体系统拆分为微服务并不是一件容易的事情。
随着业务的复杂性增大、系统吞吐量增长,所有功能统一部署难度加大,各个功能模块相互影响,使系统变的笨重且脆弱;因此需要对业务进行拆分、对系统进行解耦、对系统内部架构升级,来提升系统容量及健壮性。
我们发现组件测试能由于其关注行为的特点在单元测试和端到端测试之间取得平衡,对于改建遗留系统来说,它提供了一个不错的起点。