/tags/liquibase/ Recent content in liquibase on Hugo -- gohugo.io en Sun, 26 Apr 2026 10:00:00 +0800 /posts/best-practice-for-liquibase/ Sun, 26 Apr 2026 10:00:00 +0800 /posts/best-practice-for-liquibase/ 本文用一组「问答」拆解 Liquibase（XML 格式）在 Spring Boot 微服务下我更倾向采用的一些实践经验。文中的反例都来自真实可见的代码风格——表名、字段、author 全部脱敏，不指向任何具体项目。每条做法尽量给出官方文档或社区可访问的来源。 一、Schema 应该住在哪个 repo？ Q：为什么我现在不太倾向继续用一个独立的 db-* 仓库（或子模块）单独保存所有 MS 的 schema？ 历史上常见的做法是开一个 database-foo、database-bar 的项目，里面只放 liquibase.properties + 一堆 change-log/*.xml，跑 mvn liquibase:update 完成迁移。问题是： schema 和服务代码不在同一个生命周期里。MS 加了一个 entity_id 字段，PR 在服务 repo；migration 在另一个 repo。两个 PR 难以原子合并，code review 也只能看半边。 CI 触发不一致。服务 repo 的测试不会跑 migration repo 的最新变更；migration repo 的 CI 也很难拿到服务的 entity 类去做 schema-vs-entity 的 sanity check。 不利于 service ownership。微服务的核心原则是 database per service；schema 是这个服务的私有资产，住到外部 repo 等同于把私有资产挪出了边界。 Q：那我现在更倾向怎么放？ 直接放进微服务自己的 repo，使用 Spring Boot 默认约定： /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 是真正的关键。