本篇要搞懂的 10 件事：分布式架构落地时绕不开的 10 个工程问题——选什么分布式数据库、分库主键怎么定、数据怎么同步、跨库怎么查、热点数据怎么扛、前后序数据怎么关联、数据中台怎么建、BFF 干什么、什么时候上分布式事务、多活怎么设计。
⚠️ 这是总结课，以 10 个问答形式覆盖分布式架构关键设计，每问先给一句话答案再展开，没有配图。
承接前文：前面的课讲的是「怎么把业务建成领域模型、拆成微服务」（领域建模、微服务设计、前端设计），这是业务侧的方法论。但中台几乎都跑在分布式微服务架构上，业务拆完之后，工程上还有一堆硬骨头要啃——数据被切成八块怎么查、跨服务改数据怎么保证一致、热点数据怎么扛住并发、机房挂了怎么不停服。20 讲就是把这些工程侧的坑列成 10 个问题，逐个给思路。可以理解为：前面教你「画图纸」，这一讲教你「图纸落地时会踩的雷」。
一、选什么样的分布式数据库？
一句话答案：看你的「钱 + 团队能力 + 业务复杂度」三件套，分别对应三档方案，从重到轻。
分布式数据库的核心套路都是数据多副本——同一份数据存好几份，靠这个实现高性能、多活和容灾。三种方案的区别就在于「副本怎么处理」和「有没有数据库中间件」：
| 方案 | 怎么干 | 代表产品 | 适合谁 |
|---|---|---|---|
| ① 一体化分布式数据库 | 数据库自己搞定多副本，多用 Paxos 协议，写多数副本成功就算成功 | OceanBase、高斯 | 大厂，要云底座，成本高、门槛高 |
| ② 集中式数据库 + 数据库中间件 | 中间件管数据路由和全局数据，数据库靠自身同步机制保证副本一致 | MyCat+MySQL、TBase（基于 PostgreSQL） | 中大型企业，成本/能力适中 |
| ③ 集中式数据库 + 分库类库 | 一个 JAR 包跟应用部署在一起，管路由和归集 | ShardingSphere | 简单读写场景，成本最低，但强一致和聚合分析弱 |
🪞 辅助理解：这三档就像「自动挡豪车 / 手动挡家用车 / 加装外挂的二手车」。一体化数据库是开箱即用但贵；中间件方案是自己攒一套够用的；分库类库是给现成数据库塞个小插件凑合用。没有最好，只有最匹配你预算和团队的。
💡 选型口诀：先掂量自身能力、成本、业务需要这三样，别盲目抄大厂。大厂的方案是给大厂的体量和钱包准备的。
二、如何设计数据库分库主键？
一句话答案：和客户打交道的关键业务，建议拿客户 ID当分库主键。
把同一个客户的数据全塞进同一个数据单元里，好处是避免「跨数据单元频繁访问」——而跨数据中心的服务调用、跨数据单元的查询，对性能是致命的。
🪞 辅助理解：分库主键就像图书馆给书分区的规则。如果按「同一个客户」分区，那这个客户的所有书都在一个书架上，一次就拿全了；如果乱分，你得满图书馆跑断腿。「以客户为中心」的业务能力，第一步就是数据上做到「以客户为中心」。
💡 不一定非得用客户 ID，也可以按机构、用户等业务属性分。关键是让高频一起访问的数据落在同一单元。
三、数据库之间怎么同步和复制？
一句话答案：抛弃慢吞吞的 ETL，改用基于数据库日志的增量捕获技术 CDC。
微服务把数据切碎了，要整合就离不开库与库之间的批量同步与复制（用于数据迁移、备份、往数据中台汇集、多主题整合等）。
| 方式 | 特点 |
|---|---|
| 传统 ETL / 定时提数 | 时效性差，是「批处理」式的延迟 |
| CDC（增量数据捕获） | 读数据库逻辑日志拿增量，准实时，数据处理与应用逻辑解耦，用起来简单 |
💡 CDC 不只用来同步数据，它还能在领域事件驱动设计里当「领域事件增量数据」的获取手段——业务一改库，日志里就有增量，顺手就发成领域事件了。PostgreSQL 和 MySQL 外围有大量现成的日志捕获组件。
四、跨库关联查询如何处理？
一句话答案：别硬跨库 join，提前把数据「搬到一起」——大场景建主题库，小场景做小表广播。
跨库关联查询是分布式数据库的天生短板。实体被拆到不同微服务后，业务上又免不了要关联查。分两类场景，两套打法：
| 场景 | 例子 | 解法 |
|---|---|---|
| ① 主题/维度查询（跨多业务线微服务） | 客户全业务视图 | 建面向主题的分布式数据库，用 CDC 把各微服务数据准实时汇过来，提前做好关联（合成宽表）或建数据模型，再建查询微服务 |
| ② 表与表关联（小表 + 大表分散在不同服务） | 机构表 join 业务表 | 小表广播：在业务库里放一张冗余的代码副表；主表一变，靠领域事件异步刷新所有副表 |
🪞 辅助理解：跨库 join 就像你要查「学生 + 他选的课」，但学生名单在 A 楼、课表在 B 楼。硬查就得两楼来回跑。聪明做法是：要么提前把两份名单合并誊到一张大表里（宽表/主题库），要么把那张不常变的「课程代码表」复印一份贴到 A 楼墙上（小表广播）——查的时候就地解决，不跑腿。
五、如何处理高频热点数据？
一句话答案：把高频热点数据（商品、机构等代码类）从数据库挪到 Redis 缓存里扛并发。
这类数据同时被多个应用读，并发高，直接怼数据库会把库压垮。挪到缓存后既降库压力、又提访问速度。需要模糊查询的，还可以上 ElasticSearch 这类搜索引擎。
🪞 辅助理解：原文那句很妙——缓存就像调味料，投入小、见效快，用户体验提升快。撒一把就能让一盘菜（系统响应）立刻好吃很多，成本却很低。
六、前后序业务数据怎么处理？
一句话答案：靠领域事件把前序数据「冗余」一份到当前微服务，按需设计成值对象或实体。
很多数据要关联前一道工序的微服务数据：投保单关联前序投保单、运输单关联前序订单。但数据散在前序微服务的库里，没法直接跨库建关联。
办法：前后序数据一般都跟领域事件挂钩，通过领域事件实体把前序数据传输并冗余到当前微服务库里。冗余进来后，怎么设计有讲究：
| 前序数据情况 | 设计成 | 理由 |
|---|---|---|
| 只整体修改，不查询/不统计 | 值对象 | 当个整体引用就够了 |
| 多条数据，还要查询/统计分析 | 实体 | 能当查询条件，在本地做多维查询 |
💡 收益：在本地微服务一次就能拿全「前序清单 + 当前单据」反馈给前端，减少跨微服务调用；只有真要明细时才回前序微服务捞。既保数据完整，又降依赖、提性能。
七、数据中台与企业级数据集成
一句话答案：微服务拆库会拆出一堆「数据孤岛」，用数据中台三步把数据重新融合起来。
分布式架构提升了弹性和高可用，代价是原本集中的数据被拆散成孤岛，企业级用数据变难。数据中台分三步建：
| 步骤 | 做什么 |
|---|---|
| 第一步：汇集存储 | 按统一数据标准，把各微服务/各渠道的数据汇集起来，解决孤岛和初级共享 |
| 第二步：主题建模 | 按主题/场景加工数据，建面向不同主题的视图（客户视图、代理人视图、渠道视图…） |
| 第三步：需求驱动 | 建业务需求驱动的数据体系，支撑业务和商业模式创新 |
💡 别把数据中台理解成「只做分析」。它也能支撑交易型场景——建在数据仓库/数据平台上，平台化之后直接喂给前台业务用。
八、BFF 与企业级业务编排协同
一句话答案：在微服务和前端之间加一层 BFF，专门干「跨微服务的协调编排 + 适配前端」。
企业级流程往往要多个微服务协作完成，每个微服务像积木块只管自己那一摊。谁来组织它们？BFF（Backend for Frontends，服务于前端的后端）。
它和微服务内部的「应用服务」都在做组合编排，区别在层级：
| 应用服务 | BFF | |
|---|---|---|
| 位置 | 微服务内部 | 中台微服务之上 |
| 管什么 | 微服务内的服务组合编排 | 微服务之间的协调 + 适配前端 |
| 怎么发版 | 跟随微服务 | 可随前端版本协同发布 |
🪞 辅助理解：BFF 像汽车里的变速齿轮，夹在「善变的前端」和「要稳的中台微服务」之间适配步调。前端需求一变，改 BFF 就行，不用去动底下的中台微服务——这样核心领域逻辑才能保持稳定。
💡 设计原则：尽量把可复用的能力往下层沉淀，既复用又避免跨中心调用。BFF 做强了，它本身就是个「集成多中台能力、面向多渠道」的业务能力平台。
九、分布式事务还是事件驱动？
一句话答案：实时强一致才上分布式事务（且尽量避免），非实时的最终一致首选领域事件驱动。
一个操作动了多个微服务的数据，就有一致性问题。一致性分两种，代价完全不同：
| 强一致性 | 最终一致性 | |
|---|---|---|
| 方案 | 分布式事务 | 领域事件驱动（异步） |
| 适用 | 实时性要求高的场景 | 非实时场景 |
| 代价 | 有性能代价，复杂 | 解耦、削峰填谷、可读写分离 |
| 建议 | 设计时平衡拆分/一致性/性能/复杂度，尽量避免 | 推荐（基于消息中间件的事件发布订阅） |
🪞 辅助理解：分布式事务像「几个人必须同时按下按钮才生效」——只要有一个慢了/卡了，所有人都得等，强但累。事件驱动像「群里发个通知，大家各自异步去办」——发完就走，办完总会办好（最终一致），系统轻快得多。也可以类比成：强一致像「同步加锁」，事件驱动像「消息队列异步解耦」。
💡 实战取向：能不用分布式事务就不用。多数业务场景其实接受得了「过几秒就一致」，那就老老实实用领域事件削峰解耦，性能和扩展性都赚到。
十、多中心多活怎么设计？
一句话答案：多活是个超复杂的系统工程，记住四个关键设计：选对数据库、单元化、访问路由、全局配置同步。
| 关键设计 | 要点 |
|---|---|
| ① 选合适的分布式数据库 | 支持多数据中心部署、多副本、底层复制同步、数据恢复时效 |
| ② 单元化架构 | 一组应用打包成「业务单元」当部署单位；单元业务自包含（流程在本单元内闭环）、数据多中心有副本、单元故障不互相影响。尽量避免跨中心/跨单元调用 |
| ③ 访问路由 | 接入层 / 应用层 / 数据层都要路由，确保请求准确到达对应的数据中心和业务单元 |
| ④ 全局配置数据管理 | 各中心全局配置统一管理、实时同步、保持一致 |
🪞 辅助理解：单元化就像连锁餐厅——每家分店（业务单元）都能独立做完一整顿饭，不用跑去别的分店借厨具（跨中心调用）。一家店停电了，其他店照常营业（故障隔离）；而总部的菜单（全局配置）每家店实时同步、保持一致。
总结
这一讲把分布式架构落地时绕不开的工程难题列成了 10 问。可以归成几条主线：
- 数据怎么存：选数据库（一体化 / 中间件 / 分库类库，看预算和能力）、分库主键（以客户为中心）。
- 数据怎么流通和查：CDC 做准实时同步；跨库查靠主题库（宽表）和小表广播，核心思路都是「提前把数据搬到一起，别临时硬跨库」；前后序数据靠领域事件冗余过来。
- 数据怎么扛压力：热点数据进 Redis 缓存（投入小见效快）。
- 数据怎么整合和编排：数据中台三步融合孤岛；BFF 当变速齿轮做跨微服务编排 + 前端适配。
- 怎么保一致、保高可用：能不用分布式事务就用事件驱动（最终一致）；高可用靠多活四件套（选库 / 单元化 / 路由 / 全局配置）。
一句话：业务建模教你怎么拆，这一讲教你拆完之后数据散了、调用远了、机房会挂，工程上怎么补回来。
一句话速记
数据散了就提前搬到一起（主题库/小表广播/事件冗余），压力大了进缓存，一致性能用事件就别用分布式事务，高可用靠单元化多活，跨服务编排交给 BFF。
思考题
你设计过或读过一套跑在多个微服务上的系统（哪怕是练手项目或开源项目），试着用这 10 问给它「体检」：
- 如果你让 AI 帮你写一段「下单 + 扣库存」跨两个服务的代码，它默认给你的是分布式事务还是事件驱动？哪种更适合你的场景，你能讲清理由、而不是照单全收吗？
- 你的项目里有没有「跨库 join」？是临时硬查，还是用了宽表 / 小表广播 / 事件冗余把数据提前搬到一起？
- 站在数据一致性与运维的角度想一想：数据冗余到多个微服务、缓存里放热点数据、CDC 抓数据库日志——这几处分别会带来哪些数据不一致 / 数据延迟的风险？你会怎么兜底？
