分布式架构关键设计 10 问

课程收官篇的总结。微服务拆完只是开始，分布式架构下的数据、事务、多活这些"硬问题"才是真正的考验。这 10 问每一个都能单独展开成一个专题，这里先建立整体认知。

1. 分布式数据库怎么选？

三种方案，成本和能力要求依次降低：

方案	代表	特点	适合
一体化分布式数据库	OceanBase、高斯	Paxos 多副本，多数写入成功即成功；通常需要云底座	大厂，成本和技术要求高
集中式库 + 数据库中间件	MyCat+MySQL、TBase	中间件独立部署做路由，靠数据库自身机制同步	中大型企业，适中
集中式库 + 分库类库	ShardingSphere	轻量 JAR 包随应用部署	简单读写场景，强一致和聚合查询较弱

2. 分库主键怎么设计？

客户相关的核心业务，建议用客户 ID 做分库主键——同一客户的数据落在同一数据单元，避免跨单元频繁访问（跨数据中心调用对性能是致命的）。"以客户为中心"首先要做到数据上的以客户为中心。也可按机构、用户等业务属性选择。

3. 数据同步与复制怎么做？

传统 ETL / 定时提数时效性差。分布式架构推荐 CDC（数据库日志增量捕获）：准实时复制、与应用逻辑解耦。CDC 还可以兼职领域事件的增量数据获取——一鱼两吃。

4. 跨库关联查询怎么办？

分布式的经典短板，分两类场景：

• 主题维度查询（如客户全业务视图）：建面向主题的数据库，用 CDC 从各微服务准实时汇集数据，提前做好宽表关联，再配一个查询微服务
• 表间关联（如机构表 × 业务表）：小表广播——业务库冗余一张代码副表，主表变更时通过事件驱动异步刷新所有副表

5. 高频热点数据怎么处理？

商品、机构这类代码数据并发访问高，加载进 Redis 缓存扛压；要模糊查询的上 Elasticsearch。原话很形象：缓存像调味料，投入小、见效快。

6. 前后序业务数据怎么关联？

比如运输单要关联前序订单数据，但订单在另一个微服务里。解法：通过领域事件把前序数据按需冗余到当前微服务，设计原则沿用实体/值对象的判断标准：

• 只整体替换、不查询统计 → 值对象
• 多条记录、要查询统计 → 实体

这样查询在本地完成，必要时才回源取明细，既保完整性又减少跨服务调用。

7. 数据中台怎么建？

微服务拆分 → 数据孤岛加剧 → 需要数据中台融合。三步走：

1. 统一标准汇集各微服务数据（解决孤岛）
2. 按主题建数据模型和视图（客户视图、渠道视图……）
3. 业务驱动的数据体系，支持创新

注意数据中台不只服务分析场景，配合 CDC 也能支撑交易场景。

8. BFF 和应用服务怎么分工？

都做"组合编排"，但层次不同：

• 应用服务：微服务内的服务组合编排
• BFF：微服务之间的协调 + 适配不同前端；随前端需求变化协同发版，挡住变化，保护中台微服务的核心逻辑稳定

原则：可复用的能力尽量往下沉淀。

9. 分布式事务还是事件驱动？

• 强一致 + 实时性要求高 → 分布式事务（有性能代价，能避则避）
• 最终一致可接受 → 领域事件驱动（推荐）：解耦微服务、削峰填谷、还能顺手实现读写分离

设计时先问一句：这个场景真的需要强一致吗？大部分业务其实接受最终一致。

10. 多中心多活怎么设计？

四个关键点：

1. 数据库选型要支持多中心部署和底层复制
2. 单元化架构：业务单元自包含（流程在本单元闭环）、数据多中心有副本、单元故障不影响同类单元，尽量避免跨中心调用
3. 访问路由：接入层/应用层/数据层三层路由，请求准确到达对应单元
4. 全局配置管理：各中心配置数据实时同步

结语

整个 DDD 专栏学下来，我自己的最大收获浓缩成三句话：

1. 边界是一切：领域边界、聚合边界、代码边界，划清了架构演进就是搬积木
2. 战略大于战术：先想清楚业务模型，再谈代码怎么写
3. 不要为 DDD 而 DDD：它是工具不是信仰，能解决问题的方法就是好方法