先定义清楚：分布式是手段，不是架构目标
分布式（微服务、分库分表、多机房）解决的是三类真实问题：
- 独立扩缩容：A 模块的流量是 B 的 100 倍，希望只扩 A。
- 独立发布与故障隔离：A 的发布不想牵连 B，A 挂了不想拖垮 B。
- 数据量/吞吐超过单机物理上限：库装不下、单机 CPU 扛不住。
判断标准很简单：你现在的系统，这三类问题哪个真实存在、且单机方案已经解决不了？ 如果答案是没有，那分布式对你就是负债——它要你付网络、一致性、运维三份税，却没有对应收益。
拆之前，永远先做模块化
大多数人想上微服务，是因为「代码改不动了」。但「改不动」的根因是耦合，不是「没拆成服务」。把服务拆开但耦合还在，等于把「改不动的单体」变成「查不动的网状」——问题一个没少，还多了网络故障。
所以第 1 步永远是在单体内部完成模块化：
- 模块边界按业务拆解方法论画清楚，接口先行。
- 代码层禁止跨模块直连数据（各模块只走自己暴露的方法）。
- 等「模块化后的单体」仍然满足不了独立扩缩容 / 独立发布，才谈拆服务。
一个脱敏案例的完整过程可以看项目作品：老单体服务化——前三个月只做边界，一个字都没拆。
分布式的三份税，要提前算清
- 网络税：一次本地调用变成一次 RPC，延迟从微秒级到毫秒级；网络抖动、超时、重试逻辑全都要处理。
- 一致性税：数据分散后，事务从「数据库帮你想」变成「你自己设计」——分布式事务、对账、补偿，每一样都是实打实的工程量。
- 运维税：每个服务都要发布、监控、日志、追踪；服务越多，可观测性成本越高。这三份税是持续的，不会因为「以后规模到了」而减免。
常见高估：以为「先拆了再说，以后优化」。事实上拆出去的复杂度几乎不可能再合回来——分布式改造是不可逆投资，决策要按「不可逆」的标准来。
三种最常见的过度设计（对号入座）
- 业务日活几千，上了微服务全家桶：为了「架构先进」预支复杂度（详见架构反模式）。
- 把「性能焦虑」当「分布式需求」：还没压测、没做索引和缓存优化，就认定「单机扛不住」。多数系统的问题在慢 SQL 和缺缓存，不在单机。
- 分库分表先行：数据量还在百万级，先上分片——换来的是跨分片查询、分布式事务、扩容重分布的连环坑。
演进路线（按这个顺序走，多数团队能省掉一次大改造）
单体 → 模块化单体（先做，收益最大）→ 读写分离/加缓存（性能不够时）
→ 按需拆出独立服务（出现真实独立需求时）→ 分库分表（数据量真实超限时）
每走一步，都用技术选型方法论的流程过一遍：约束是什么、假设是什么、怎么验证、写没写 ADR。
落地清单
- 用「三类真实问题」清单自检：现在的系统真的需要分布式吗
- 拆之前先完成模块化（代码层消灭跨模块耦合）
- 把网络 / 一致性 / 运维三份税的账算给团队看
- 按演进路线走，不跨级
- 每个架构决策写 ADR，标注「什么条件下要推翻」