/tags/postgresql/ Recent content in postgresql on Hugo -- gohugo.io en Thu, 26 Mar 2026 23:20:00 +0800 /posts/liquibase-split-progressive-migration/ Thu, 26 Mar 2026 23:20:00 +0800 /posts/liquibase-split-progressive-migration/ 很多团队在做单体拆微服务时，第一反应都是先拆代码、拆接口、拆部署。但数据库层真正难的地方，往往不是“怎么建新表”，而是： 旧系统已经在线跑着，不能随便停 Liquibase changelog 早就耦合成一个大文件 业务表和外键关系跨领域交织 拆服务后，数据库迁移责任边界也要跟着重画 这次我做了一个 Liquibase Split POC，目标不是做一个“看起来很对”的设计稿，而是把一条在本地跑通并验证过的渐进式迁移路径做出来： 完整 POC 代码及运行脚本见 GitHub: meirongdev/liquibase-split Phase 1：单体 + 单库 + 单 changelog Phase 2：还是单库，但 changelog 按服务拆开 Phase 3：每个服务拥有自己的数据库 而且这次不是只写代码，我尽量把整个实验跑完整，并记录了每一步的迁移结果。 这次 POC 要解决什么问题 如果一开始就要求把单体数据库“一刀切”拆成多个库，风险通常很高： Liquibase 历史已经存在，不能随便改 checksum 线上数据库里已经有数据，不能直接重建 跨服务 FK 会让拆库变得很痛苦 微服务代码和数据库边界很容易出现错位 所以这个 POC 的核心想法是 progressive split： 先把迁移职责拆开 再把数据库边界拆开 最后才进入真正的独立库阶段 和“先想理想架构，再一把切过去”相比，这条路径在现有项目里通常更容易落地。 三阶段目标 Phase 数据库形态 Liquibase 形态 关键目标 Phase 1 单个 shopdb 单体主 changelog 先把完整单体 schema 跑起来 Phase 2 仍然是 shopdb 每个服务各自维护 changelog，DATABASECHANGELOG 隔离 零停机拆迁移边界 Phase 3 userdb / productdb / orderdb 每个服务各自迁移到自己的库 完成数据库层拆分 这个模型里，Phase 2 是真正的关键。