本文分享了一次在微服务化改造中进行数据库拆分的实战经验，包括拆分背景、分析、中间过程及上线总结。通过遵循《Refactoring Databases》中的步骤，逐步完成业务代码修改、数据迁移、监控和BI的调整，确保服务化改造的顺利进行。重点讨论了如何在拆分发货单服务时，处理业务代码、数据和监控的变更，以及上线时的策略选择。
前言
对遗留系统的微服务化改造，从整体上来说，整个过程包含两个部分：一，通过某一种方法论将系统进行微服务划分，比如DDD倡导的限界上下文划分方法。根据系统的特点和运行状态，又分为具体的两种实施策略，绞杀者模式和修缮模式。二，数据库的拆分，只有在数据层面也拆分开，才能真正达到服务化的目的。具体也可以分为，与业务服务拆分同时进行，或者等业务服务拆分后再单独进行两种策略。
似曾相识的步骤
如果不考虑在拆库的同时引入新功能，拆库其实也是一种重构。Martin Fowler在**《Refacotring》中强调数据库具有高度的耦合性，数据库重构存在相当的难度。不过好在还有另一本权威著作来为此背书，那就是《Refactoring Databases》**。
来看看这本书提到的数据库重构步骤：
- Verify that a database refactoring is appropriate
- Choose the most appropriate database refactoring
- Deprecate the original database schema
- Test before, during, and after
- Modify the database schema
- Migrate the source data
- Refactor external access program(s)
- Run your regression tests
- Version control your work
- Announce the refactoring
- What you have learned
是不是和代码的重构似曾相识，分析->测试->修改->测试……
同时也看看我们的数据库拆分实践是否能和这些步骤有所呼应。
背景介绍
我们曾经对某客户企业的系统做服务化改造。根据其组织架构和系统特点，最终采取了先服务拆分，再数据库拆分的演进路线。
到服务化改造基本完成时，系统逻辑结构如下图所示：
右边的图完全就是《Refactoring Databases》里说的Multi-Application Database。
接下来就是数据库的重构了，也是本文的重点。
分析在前
系统数据库采用MySQL，由于之前是一个大单体，所有的数据
最低0.47元/天 解锁文章
扫一扫
770
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
