完整 ADR 案例订单服务数据库选型下面给出一个完整、可直接套用的 ADR 案例。它覆盖了从上下文、评估标准、候选方案对比到最终决策、后果、置信度和复查条件的全部要素。案例背景设定为一家中型电商公司正在重构订单服务。ADR-0042订单服务采用 PostgreSQL 作为主数据库字段内容ADR 编号ADR-0042标题订单服务采用 PostgreSQL 作为主数据库状态Accepted日期2025-03-14决策者架构组张伟、李娜、订单团队负责人王强相关方订单团队、运维团队、数据团队、安全团队取代无被取代无截至 2025-03-141. 上下文Context1.1 业务背景公司现有订单系统基于单体应用 MySQL 5.7日均订单量 30 万峰值 QPS 约 1200。随着业务增长预计未来 18 个月日均订单量将达到 100 万峰值 QPS 约 4000。现有系统已出现以下问题大促期间订单写入延迟明显部分请求超时报表查询与在线交易争抢资源互相影响分库分表方案基于应用层实现维护复杂跨分片查询困难MySQL 5.7 已停止官方支持存在安全合规风险1.2 技术背景订单服务正在从单体中拆分出来成为独立微服务。这是重新选型的窗口期。约束条件如下时间拆分窗口 4 个月数据库选型必须在 2 周内确定团队订单团队 6 人均有 MySQL 经验无其他数据库生产经验运维运维团队支持 MySQL 和 Redis其他数据库需额外学习合规订单数据需保留 7 年支持审计数据不可丢失预算年度基础设施预算增加不超过 30%1.3 核心需求需求类型具体要求事务强一致性支持 ACID订单状态变更必须原子写入峰值 4000 QPS日均 100 万订单查询支持复杂查询多条件筛选、聚合、报表扩展支持水平扩展至 3 年内预期规模可用性99.99%支持主从切换RPO≈0RTO30s合规支持审计、数据保留 7 年、加密迁移支持从 MySQL 5.7 平滑迁移2. 评估标准Evaluation Criteria团队在选型前共同确定以下评估维度和权重维度权重说明业务匹配度30%事务、查询、扩展能力是否满足需求团队能力20%学习曲线、招聘难度、现有经验运维成熟度15%运维工具、监控、备份恢复生态与社区10%文档、社区活跃度、第三方工具总拥有成本10%硬件、人力、licensing、迁移成本风险与可逆性10%锁定风险、迁移成本、合规风险长期演进5%版本节奏、LTS、厂商支持3. 候选方案Considered Options评估了以下 4 个候选方案包括保持现状方案 A继续使用 MySQL 5.7 应用层分库分表维持现有技术栈升级到 MySQL 8.0继续使用应用层分库分表方案方案 B采用 PostgreSQL 15主从架构逻辑复制支持报表读库未来需要时引入 Citus 或分库分表方案 C采用 TiDB分布式数据库原生水平扩展MySQL 协议兼容迁移相对平滑方案 D采用 MongoDB文档型数据库schema 灵活分片集群支持水平扩展4. 对比矩阵Comparison Matrix维度权重MySQL 8.0PostgreSQL 15TiDBMongoDB业务匹配度30%3453团队能力20%5422运维成熟度15%5433生态与社区10%5534总拥有成本10%4423风险与可逆性10%3432长期演进5%4544加权总分100%3.954.053.552.85评分说明1差3可接受5优秀。权重和评分由架构组、订单团队、运维团队共同确定。关键差异分析TiDB在业务匹配度上最高原生水平扩展但团队能力、运维成熟度、成本三项拖累明显。团队无分布式数据库经验运维需额外投入年度成本约为 PostgreSQL 方案的 2.5 倍。MongoDB在事务和复杂查询上弱于关系型数据库订单场景的强事务需求使其匹配度不足。MySQL 8.0团队最熟悉但应用层分库分表的维护复杂度和跨分片查询问题未根本解决。PostgreSQL 15综合最优事务和查询能力满足需求团队学习曲线可控运维成熟成本可控。5. 决策Decision采用 PostgreSQL 15 作为订单服务的主数据库。具体方案架构一主两从主库承担写入从库承担报表和只读查询复制使用流复制保证高可用逻辑复制支持报表读库扩展初期单库预留分库分表能力当单表超过 5000 万行或写入 QPS 超过 8000 时评估 Citus 或应用层分片迁移使用 pgloader 从 MySQL 5.7 迁移双写过渡 2 周校验数据一致性后切换合规启用审计日志数据加密TDE备份保留 7 年高可用使用 Patroni etcd 实现自动故障切换RPO≈0RTO30s6. 理由Rationale选择 PostgreSQL 15 而非其他方案的核心原因为什么不是 TiDBTiDB 在水平扩展上确实更优但当前 4000 QPS 的需求 PostgreSQL 完全能覆盖。TiDB 的分布式事务和运维复杂度对 6 人团队是过重负担年度成本也超出预算。为 3 年后的规模提前支付今天的成本不划算。当真正需要时PostgreSQL 可通过 Citus 平滑演进。为什么不是 MySQL 8.0MySQL 8.0 团队最熟悉但应用层分库分表的维护复杂度和跨分片查询问题未解决。PostgreSQL 在复杂查询、JSON 支持、扩展性上更强且团队学习曲线可控SQL 语法相近。为什么不是 MongoDB订单场景需要强事务和复杂查询MongoDB 在这两方面弱于关系型数据库。schema 灵活性的优势在订单场景并不关键。为什么是 PostgreSQL 15事务和查询能力满足当前和可预见需求团队有 SQL 基础学习曲线可控预计 2 周上手1 个月熟练运维成熟Patroni、pgBackRest 等工具链完善开源无锁定成本可控可通过 Citus 平滑演进到分布式社区活跃LTS 支持明确7. 后果Consequences7.1 正面后果事务和复杂查询能力满足订单场景核心需求主从架构分离读写报表查询不再影响在线交易开源方案无厂商锁定成本可控团队 SQL 技能可复用学习成本低于 TiDB/MongoDB为未来水平扩展预留路径Citus7.2 负面后果团队需学习 PostgreSQL 特有特性MVCC、VACUUM、扩展机制运维需掌握 Patroni、pgBackRest 等新工具单库写入上限约 8000 QPS超过需分库分表迁移期间需双写增加短期复杂度逻辑复制在 schema 变更时需额外协调7.3 中性后果需建立 PostgreSQL 运维 runbook需调整监控和告警规则需更新团队技能矩阵和招聘要求8. 权衡Trade-offs放弃了什么换取了什么TiDB 的原生水平扩展更低的运维复杂度和成本MySQL 的团队熟悉度更强的查询能力和扩展性MongoDB 的 schema 灵活性强事务和复杂查询能力一步到位的分布式架构渐进演进的灵活性和可逆性9. 置信度Confidence方面置信度说明当前需求匹配高PostgreSQL 能力明确覆盖当前需求团队学习曲线中基于 SQL 基础预估实际可能更长3 年扩展路径中Citus 方案尚未在生产验证迁移风险中pgloader 迁移需 POC 验证运维成熟度高Patroni 等工具在生产广泛使用整体置信度中高。核心决策选 PostgreSQL置信度高扩展路径和迁移细节置信度中等需通过 POC 和试点验证。10. 复查条件Review Triggers在以下任一条件满足时重新评估本决策单表超过 5000 万行或写入 QPS 持续超过 8000Citus 方案在生产验证失败且无其他可行扩展路径团队学习成本远超预期影响交付出现 PostgreSQL 无法满足的新业务需求如全球分布式事务PostgreSQL 社区出现重大治理或 licensing 变化下次复查时间2026-03-14决策后 12 个月11. 实施计划Implementation Plan阶段时间关键任务负责人POC第 1-2 周验证 pgloader 迁移、Patroni 切换、性能基准张伟环境搭建第 3-4 周搭建生产级 PG 集群配置监控备份运维团队迁移开发第 5-8 周双写适配、数据校验、回滚方案订单团队灰度切换第 9-10 周双写过渡逐步切读验证一致性订单团队全量切换第 11-12 周停止双写MySQL 只读保留 1 个月订单团队复盘第 13 周复盘迁移过程更新 ADR 状态架构组12. 相关文档ReferencesADR-0015订单服务从单体拆分订单服务数据库选型对比矩阵详细版PostgreSQL 15 POC 报告Patroni 高可用方案设计迁移回滚预案13. 附ADR 状态变更记录日期状态变更说明变更人2025-03-07Proposed初稿提交评审张伟2025-03-10Proposed根据运维团队反馈补充高可用方案张伟2025-03-14Accepted架构组和订单团队共同批准架构组2026-03-14待定计划复查—案例使用说明这个案例的完整之处在于上下文具体有业务数据、技术约束、时间窗口而非泛泛而谈评估标准前置在选型前确定维度和权重避免先有结论再找理由候选方案完整包括保持现状避免二元对立对比矩阵结构化权重和评分公开差异分析具体决策明确选了什么、怎么落地清晰可执行理由充分解释了为什么不是其他方案而不只是为什么是这个后果完整正面、负面、中性都列出不隐藏代价权衡显式明确放弃了什么换取了什么置信度分级区分高置信度和需验证的部分复查条件明确什么情况下重新评估避免决策僵化实施计划具体有时间、任务、负责人状态变更可追溯从 Proposed 到 Accepted 的完整历程套用建议小型决策可精简为上下文-决策-后果三要素大型决策可参考本案例的完整结构关键不是格式而是记录为什么、放弃了什么、什么条件下重新评估ADR 应在决策过程中写而非事后补已接受的 ADR 不修改新决策产生新 ADR 并链接这份 ADR 的价值不在于它选了 PostgreSQL而在于一年后有人问为什么当初不用 TiDB时能直接找到答案。