从单体到微服务：iDev 数据库拆分实战
From Monolith to Microservices: iDev's Database Split in Practice
| iDev Engineering | 2026-08-27T11:11:22
本文记录 iDev 将单体应用的 MySQL 大库拆分为 6 个独立数据库的完整过程，包括数据迁移、双写方案和回滚策略。
This article documents iDev's complete process of splitting a monolithic MySQL database into 6 independent databases, including data migration, dual-write approach, and rollback strategy.
拆分背景iDev 早期使用单一 MySQL 实例承载所有业务数据，单库表数超过 120 张，日均查询量突破 5000 万。数据库成为全系统的单点瓶颈。拆分方案设计领域划分user_db：用户、权限、组织project_db：项目、仓库、分支ai_db：AI 会话、代码生成记录billing_db：订单、账单、支付analytics_db：访问日志、使用统计config_db：系统配置、功能开关跨库关联处理拆分后最大的挑战是处理跨库 JOIN 查询。我们采用三种策略：数据冗余（高频查询字段冗余存储）、API 组合（应用层聚合）和异步同步（Debezium CDC 同步变更）。迁移过程双写阶段阶段1：老库读写 + 新库写入（影子写入） 阶段2：新库读写 + 老库写入（回退保障） 阶段3：新库读写，老库只读（观察期） 阶段4：下线老库连接每个阶段持续 1-2 周，通过数据校验服务持续比对新老库数据一致性。踩坑记录分布式事务是最棘手的问题。我们放弃了 XA 事务，转而采用 Saga 模式处理跨库业务流程。对于强一致性场景（如支付），使用 TCC 模式保障。成效数据库拆分完成后，核心查询 P99 延迟从 120ms 降至 25ms，数据库 CPU 利用率从 85% 降至 35%，支持水平扩展后理论容量提升 10 倍。
BackgroundIn its early days, iDev used a single MySQL instance for all business data, with over 120 tables and daily queries exceeding 50 million. The database became a single point of bottleneck for the entire system.Split Strategy DesignDomain Divisionuser_db: Users, permissions, organizationsproject_db: Projects, repositories, branchesai_db: AI sessions, code generation recordsbilling_db: Orders, invoices, paymentsanalytics_db: Access logs, usage statisticsconfig_db: System configuration, feature flagsCross-Database Join HandlingThe biggest challenge post-split was handling cross-database JOIN queries. We adopted three strategies: data redundancy (storing frequently queried fields redundantly), API composition (application-layer aggregation), and async synchronization (Debezium CDC for change sync).Migration ProcessDual-Write PhasePhase 1: Old DB read/write + New DB write (shadow write) Phase 2: New DB read/write + Old DB write (rollback safety) Phase 3: New DB read/write, Old DB read-only (observation) Phase 4: Decommission old DB connectionsEach phase lasted 1-2 weeks, with a data verification service continuously comparing consistency between old and new databases.Lessons LearnedDistributed transactions were the trickiest issue. We abandoned XA transactions in favor of the Saga pattern for cross-database business processes. For strong consistency scenarios (like payments), we used the TCC pattern.ResultsAfter the database split, core query P99 latency dropped from 120ms to 25ms, database CPU utilization decreased from 85% to 35%, and theoretical capacity increased 10x with horizontal scaling support.