软件架构模式选型：从分层单体到事件驱动与微服务拆分

1. 先想清楚架构模式到底在解决什么

软件架构模式这个词，很多人第一次接触是在面试八股文里，背了一堆分层、微服务、事件驱动，真到项目里却发现一个都用不上，或者用上了反而更乱。我带过几个从零起步的项目，也接手过几个已经跑了两三年的存量系统，最常见的场景是这样的：系统上线第一年跑得挺顺，第二年需求一变，改一个字段要动七八个文件，第三年新人入职两周还没搞清楚一次请求到底经过哪几层。这时候大家才回头翻架构模式，想找个"正确答案"套上去。但架构模式从来不是答案，它是一组被反复验证过的取舍模板——每一个模式都在用某些方面的代价换另一些方面的收益，你要做的是搞清楚这笔交易划不划算。

我接手过一个内部工单系统，最早的代码就是典型的"一锅端"：Servlet 里直接写 SQL，页面里直接调 DAO，业务逻辑散落在 JSP 的 if-else 中间。功能其实不复杂，五个核心表，十来个人用。后来业务方要接移动端，要加审批流，要出统计报表，三个月内需求翻了三倍，团队从两个人扩到五个人。这时候问题就集中爆发了：两个人改同一个文件冲突不断，报表查询把主库拖垮，移动端要的 JSON 结构跟页面渲染需要的结构完全对不上。这就是我常说的架构债的触发点——不是代码丑，而是协作成本、变更成本、性能成本三者中有一个突然陡增。你判断要不要重构、要不要换模式，看的就是这三个成本曲线什么时候拐弯。

所以这篇内容我不打算按教科书顺序一个个念定义。我会按"你什么时候会真的用上它"来组织：单体内部怎么分层、单体怎么长成模块化、界面层那套 MVC 家族到底该选谁、以及一旦跨进程之后微服务、事件驱动、CQRS 这些模式各自要付出什么代价。核心关键词会反复出现：软件架构模式、分层架构、事件驱动架构、微服务拆分、CQRS、六边形架构、微内核插件化。适合正在做技术选型的后端同学、被存量系统折磨的维护者，以及想搞清楚"为什么别人这么设计"的初中级开发者。不需要你精通分布式，但至少要写过一次完整的增删改查，否则很多取舍你会觉得是空谈。

2. 单体家族：分层、模块化单体与管道过滤器

2.1 分层架构：最容易被用烂也最容易被误解的一个

分层架构几乎是所有项目的默认起点，典型四层是表现层、应用层、领域层、基础设施层。听起来很简单，但绝大多数"分层失败"的项目，问题不在分层本身，而在于依赖方向搞反了。我见过太多项目，领域层的实体类上挂着@TableName、@JsonFormat，基础设施层的工具类被领域服务直接静态调用，最后你换一个 ORM 或者换一个序列化框架，要改遍整个领域层。这不是分层架构的错，这是把分层理解成了"文件夹分层"。

真正有意义的分层，判断标准只有一条：依赖是不是单向指向内层。表现层依赖应用层，应用层依赖领域层，领域层谁也不依赖，基础设施层实现领域层定义的接口。这条规则落地成代码，最直观的体现就是领域层里不应该出现任何第三方框架的注解和 import。你可以用一个很土的办法自查：打开领域层的包，看看 import 列表里有没有spring、mybatis、jackson这些字样，有的话就得考虑抽接口了。

各层的职责我用一张表说清楚，顺便标注我在评审时最常看到的破例点：

这里有个实操心得：应用层和领域层的边界，用"事务"来切最省事。一个用例一个事务，事务开在应用层方法上，领域层方法必须是纯计算、可重复执行、无副作用的。我试过把这套规则写进代码评审清单，坚持两个迭代之后，团队里"改一个字段要动七八个文件"的情况基本消失了，因为改动只会落在领域对象和它的单元测试上。

当然分层也有它明确的短板。第一是简单查询会被迫穿透四层，一个列表接口要写 Controller、Service、Manager、Mapper 四个类，成本显得很蠢。我的处理办法是允许只读查询走旁路：直接用一个查询服务读视图或者读宽表，不走领域模型。这个做法在很多团队里有争议，但只要在团队内明确"写走领域、读可旁路"，争议就变成了约定。第二是跨层调用容易被当作捷径，比如表现层直接调基础设施层的缓存工具，短期很爽，长期就是隐藏耦合。这类事情靠自觉没用，得靠包级的依赖检查工具卡住。

另外说一句分层和部署的关系。分层是逻辑划分，不是部署单元。四层放在一个进程里跑完全没问题，不是分了层就得上微服务。我见过有人把分层理解成"每层一个服务"，然后搞出四个服务互相调用，性能掉一半，调试成本翻三倍，这就属于把模式用反了。

2.2 模块化单体：被严重低估的中间态

分层解决的是"纵向切"，但它的盲区很明显：同一个业务能力被横向撕碎。订单相关的代码散落在四个层的四个包里，你要改订单逻辑，得在四个目录之间来回跳。项目一大，这个问题比依赖方向更致命。

模块化单体就是针对这个盲区来的。它保留单一部署单元（一个进程、一个数据库、一次发布），但内部按业务能力纵向切模块，每个模块自带自己的分层结构，模块之间只通过公开接口和领域事件通信，禁止直接访问对方的数据表。这个模式在近几年被反复提起，但真正落地的不多，原因很现实：约束太容易被破坏。跨模块直接 join 两张表，一行 SQL 就绕过了所有边界。

我实际落地时用了三条硬规则，效果比较稳：

1. 模块私有表加前缀，比如订单模块的表全部以ord_开头，用户模块以usr_开头。跨模块 SQL 一旦出现对方前缀，评审直接打回。
2. 模块间只暴露一个门面接口，放在模块名-api的独立包里，实现类放在模块内部。构建层面可以做依赖检查，比如用 Maven 的 enforcer 或者 Gradle 的 dependency 约束，禁止 A 模块依赖 B 模块的内部包。
3. 跨模块的写操作一律走事件，同步返回用门面接口，异步通知用事件。这条是为了将来真要拆服务时，改动量小。

这套做法的收益是可以量化的。我之前维护的一个模块化单体，二十多个业务模块，编译一次四十秒，本地起服务不到十秒，新人入职第三天就能独立提交一个完整的业务改动。对比同期另一个拆成十几个服务的项目，本地要起五六个容器，新人两周还在配环境。所以我在很多场合都会说：团队人数低于三十、业务边界还在快速变化的时候，模块化单体几乎总是比微服务更优的选择，它保留了拆分的能力，但把分布式的复杂度延后了。

代价也要说清楚。第一，模块化单体的边界靠纪律和工具守，没有网络调用这种天然的物理边界，人一多就容易破。第二，数据库还是一个，热点表锁竞争、慢查询拖累全局的问题依然存在，只能靠读写分离、缓存、归档来缓。第三，模块间的事件走进程内事件总线，一旦某个监听器抛异常，容易把主流程拖住，必须明确区分同步事件和异步事件，异步的丢到线程池或者本地消息表去。

2.3 管道-过滤器：数据处理链路的默认解

只要你的系统里存在"一串加工步骤，每一步的输入是上一步的输出"，管道-过滤器就是最贴合的模式。典型场景是日志清洗、ETL、图片处理流水线、编译器前端。它的好处是每个过滤器独立、可单独测试、可自由排列组合，新增一步不用改其他步。

我做过一个数据入库的链路：原始数据先做字段校验，再做单位归一，再做敏感字段脱敏，再做去重，最后落库。五个过滤器串起来，每个过滤器接收一个数据对象返回一个数据对象，全部是无状态的纯函数。这套结构最大的价值不是好看，而是排错快：某批数据结果不对，把中间结果打到临时表，一眼就能看出是哪一步出的问题。换成分层写法，这五步多半会塞进一个大方法里，排错就得打断点单步走。

但这个模式有两个坑必须提前防。

第一个是错误处理语义不清晰。过滤器 A 校验失败，是直接丢弃这条数据、还是标记后继续传递、还是抛异常中断整条链路？这三种策略在一个链路里混用，最终结果会非常难预测。我的做法是给过滤器定义一个统一返回结构，包含status（pass/skip/fail）、payload、reason三个字段，链路上任何一步都可以决定短期中断还是透传，并且每次跳过都记一条明细日志。这样最终你会发现，数据处理系统的准确率问题，八成不是逻辑错，而是错误分类没定义清楚。

第二个是吞吐和内存。过滤器链如果是全量加载再逐级处理，数据量一上来就爆内存。改成流式处理之后又要处理背压。很土但有效的经验是：按行处理的链路用迭代器或者生成器，一批一批往下推，批大小设成 500 到 2000 之间实测调；链路中任何一步需要全量排序或者聚合，就说明这一步不该放在流式链路里，得单独拆成一个阶段落盘再做。

代码上我给个最小骨架，Python 示例，重点是那个统一返回结构：

from dataclasses import dataclass @dataclass class FilterResult: status: str # pass / skip / fail payload: dict reason: str = "" def run_pipeline(rows, filters): stats = {"pass": 0, "skip": 0, "fail": 0} for row in rows: current = FilterResult("pass", row) for f in filters: current = f(current) if current.status == "fail": break stats[current.status] += 1 if current.status == "pass": yield current.payload print(stats)

一段链路跑完打印三个计数，长期看这个统计比任何监控大盘都直观：skip 突然暴涨说明上游数据格式变了，fail 突然暴涨说明新加的校验规则太严。

3. 界面层的 MVC 家族与六边形架构

3.1 MVC、MVP、MVVM：选谁取决于"状态往哪流"

这三个模式被讨论得最多，也被误解得最深。很多人的理解停留在"MVC 是后端、MVVM 是前端"，其实它们的差别只有一个：视图和模型之间谁来承担同步状态的职责。

MVC 里控制器接收输入、更新模型、模型通知视图刷新。它的经典问题在桌面和富客户端时代就暴露了：视图和模型耦合，视图能直接读模型，测试视图就得连带模型一起跑。MVP 把控制器换成了 Presenter，视图退化成纯粹的哑巴接口，所有展示逻辑都在 Presenter 里，视图只负责调用接口方法。好处是 Presenter 可以完全脱离 UI 框架做单元测试，坏处是接口方法会膨胀，一个稍复杂的页面 Presenter 上挂三四十个方法是常事。MVVM 把同步这件事交给了数据绑定框架，视图模型暴露可观察属性，视图自动跟随变化，代码量最少，但双向绑定是个双刃剑：数据流方向不明确的时候，一个字段被谁改了很难追，复杂表单里经常出现循环更新。

我自己的判断标准很朴素，就三条：

• 页面状态简单、以展示为主，用 MVC 就够了，别为了模式而模式。
• 页面交互复杂、需要大量单元测试保障，用 MVP 或者 MVVM，但要接受接口/属性膨胀的成本。
• 表单字段多、联动多、还要撤销重做，慎用双向绑定，老老实实单向下发加事件回传。

有个特别现实的坑值得单独说：视图模型膨胀。不管是 Presenter 还是 ViewModel，写久了都会变成上帝类，校验、格式化、跳转、埋点、权限判断全塞进去。我的处理办法是把这几类职责拆出去做成独立的服务：格式化交给格式化器，权限判断交给一个策略对象，埋点交给一个装饰器包在外面。视图模型只负责"拿到数据、组合状态、暴露给视图"，超过三百行就该拆了。

3.2 六边形架构：把"核心"保护起来的思路

六边形架构（也叫端口-适配器）本质上不是一种新的分层，而是把分层的依赖规则推到极致：领域核心在正中间，对外只暴露端口（接口），所有外部世界的东西——数据库、消息队列、HTTP 接口、定时任务——都通过适配器接进来。它的价值在测试和替换成本上体现得最明显。

我拿一个真实改造举例。有个系统要在三种环境里跑：命令行批处理、HTTP 接口、消息消费。原来三套入口各写一份业务逻辑，改一处漏两处是常态。改成六边形之后，领域服务只定义OrderService这一个端口，三个入口各写一个很薄的适配器，把入参转成领域命令对象，调同一个端口。代码量从三份变成一份加三个几十行的适配器，测试也简单了，领域逻辑用内存实现替换掉仓储端口就能跑，不需要起数据库。

端口定义的关键是按用例定义，不要按技术定义。这是我踩过的坑：早期我定义了一个Repository端口，里面塞了findById、findByStatus、save、delete、countByXxx十几个方法，结果每个适配器都要实现全部方法，其中一半是空实现。后来改成按用例拆：下单需要OrderWriter，查询详情需要OrderReader，两个端口各自两三个方法，适配器实现起来干净很多，测试桩也好写。

// 端口：只声明这个用例真正需要的动作 public interface OrderWriter { void save(Order order); Optional<Order> load(OrderId id); } // 适配器：技术细节全在这里 public class JdbcOrderWriter implements OrderWriter { public void save(Order order) { /* 组装 SQL 或交给 ORM */ } public Optional<Order> load(OrderId id) { /* 查询并转回领域对象 */ } }

注意最后那句"转回领域对象"，这是六边形落地最容易被跳过的一步。很多实现直接把数据库实体当领域对象用，端口形同虚设，换了存储还得改领域层。多做一层转换确实啰嗦，但这一层转换恰恰是整个模式的价值所在——它让领域层对存储形态完全无知。

还有一个现实问题：六边形架构在小项目上会显得过度设计。一个只有五张表、两个入口的系统，硬套端口适配器，代码量能翻一倍。我的一般经验是：当系统存在两种以上入口，或者核心业务规则复杂到值得单独测试时，再上六边形；否则普通的四层分层够用，别为了架构图好看给自己加活。

4. 事件驱动与微内核：两种解耦方向

4.1 事件驱动：解耦最彻底，也最难排查

事件驱动架构的核心是把"我做了什么事"广播出去，谁关心谁自己订阅，发布方不关心有多少订阅方。它解决的是强耦合的扇出问题。一个下单动作，要通知库存、积分、优惠券、消息推送、数据统计五个下游，同步调用写法就是五段代码串在一个方法里，任何一个下游超时都拖垮下单。改成发一个OrderCreated事件，五个下游各自消费，下单主流程只剩两行。

这个模式的收益很直观，代价也很直观。我把实际项目里遇到的代价归成四类，每一类都配了对应做法：

其中本地消息表这个做法我强烈建议所有用事件驱动的团队都落地，因为它同时解决了"业务写库成功但消息发送失败"这个最恶心的场景。逻辑很简单：业务数据和一个消息记录在同一个本地事务里写进去，然后由一个独立的后台任务扫表投递，投递成功后标记状态。我实测过的量级是单表每天百万级消息记录，加上索引和定期归档，完全扛得住。伪代码如下：

-- 同一个事务里执行 INSERT INTO ord_order (id, user_id, amount, status) VALUES (?, ?, ?, 'CREATED'); INSERT INTO msg_outbox (id, topic, payload, status, created_at) VALUES (?, 'order.created', ?, 'PENDING', NOW()); -- 独立投递任务 SELECT * FROM msg_outbox WHERE status = 'PENDING' AND created_at < NOW() - INTERVAL 5 SECOND LIMIT 200; -- 投递成功后 UPDATE status = 'SENT'

为什么扫描条件要加 5 秒延迟？因为主事务可能还没提交，太早扫到会投递出"事件已发但业务数据没落地"的鬼故事。这个延迟值我给的经验区间是 3 到 10 秒，看你的主事务平均耗时，宁可多等几秒也别太激进。

事件驱动还有一个很容易被忽略的设计选择：Broker 模式还是 Mediator 模式。Broker 是事件总线，发布方和订阅方互不知道对方存在，扩展性最好，但整体流程不可见，没人能一眼说清一个事件最终触发了哪些动作。Mediator 是有一个协调者负责编排，流程可见，但协调者会变成新的中心节点，改流程要动它。我的选择习惯是：跨模块、跨团队的集成用 Broker，单个业务流程内部的步骤编排用 Mediator。全都用 Broker 会导致"一个事件触发二十个消费者，谁也不知道最终结果该是什么"的混乱局面，这个坑我踩过，排查一次跨五个服务的状态不一致花了整整两天。

关于幂等，还得补一句实操细节。去重表的键不要用消息 ID，因为很多场景下同一个业务动作会因为重试产生不同的消息 ID。要用业务唯一键，比如"订单号 + 事件类型"，这样重发、补发、人工重放都能被正确去重。

4.2 微内核与插件化：把变化关进盒子里

微内核（也叫插件架构）适合的场景很明确：核心流程稳定，外围功能经常变、且变化之间互不相干。典型是规则引擎、报表导出器、支付渠道接入、IDE 的扩展体系。核心系统只负责加载插件、路由请求、管理生命周期，具体业务逻辑全在插件里。

它的核心机制有四个要点，缺一个就会在半年后炸：

1. 扩展点定义：核心暴露一组接口，插件实现这些接口。扩展点一旦发布就要考虑向后兼容，加方法要用默认实现，别直接改签名。
2. 插件注册与发现：可以通过配置文件、目录扫描或者注解。我倾向于配置文件显式声明，虽然土，但排查问题时一眼能看到"到底加载了哪些插件"，比动态扫描黑盒强。
3. 隔离与降级：插件抛异常不能拖垮核心。每个插件调用都包一层，超时熔断，失败记日志并降级到默认实现。
4. 版本兼容：插件声明自己支持的扩展点版本，核心加载时校验，不匹配直接拒绝加载而不是带着 bug 跑。

# 极简插件注册示意 REGISTRY = {} def extension_point(name, version): def decorator(cls): REGISTRY.setdefault(name, []).append((version, cls)) return cls return decorator def dispatch(name, payload, timeout=2.0): for version, cls in sorted(REGISTRY.get(name, []), reverse=True): try: return cls().handle(payload) # 实际要加超时与异常隔离 except Exception as e: log.warning("plugin failed: %s %s", cls.__name__, e) return None # 降级：返回默认结果

这段代码省略了线程隔离和超时控制，真实实现里我会用线程池加 future 的get(timeout)，超时就放弃这个插件。为什么要这么谨慎？因为我们曾经遇到过一个插件里写了个死循环，把整个应用的请求线程全占满，核心系统跟着挂掉。自从那次之后，我对"插件必须隔离"这条的执念就没放下过。

微内核的代价是调用链路变长、调试变绕。一个请求经过核心路由到某个插件，出问题要先确认插件有没有被加载、加载的是哪个版本、有没有被降级。所以核心侧的可观测性必须跟上：每次插件调用都记录插件名、版本、耗时、结果状态，这四个字段缺一不可。

5. 分布式家族：微服务、SOA 与无服务形态

5.1 微服务拆分：粒度才是真问题

微服务的定义大家都会背，真正的难点从来不是"要不要拆"，而是"拆到什么程度"。我见过拆得太细的：一个用户相关的功能拆成注册服务、登录服务、资料服务、头像服务，改一个"昵称不能重复"的需求要动三个服务、发三次版、联调一整天。也见过拆得太粗的：号称微服务，实际是两个巨型服务互相调，一个服务里两百个接口。

我判断粒度用三个维度交叉验证：

• 业务能力边界：这块功能是不是一个完整的能力闭环，能独立对外描述"我负责什么"。能用一句话说清且不出现"并且"的，通常适合作为一个服务。
• 变更频率：两个模块的发布节奏是不是一致。一周发三次的模块和一季度发一次的模块绑在一起，前者会被后者拖住。
• 数据所有权：这块数据是不是只被一个服务写。如果两张表必须强事务一起写，那它们大概率该在同一个服务里。

再给一个更硬的参照：团队规模。一个服务最好由一个 5 到 8 人的小组负责，两个人负责三个服务是灾难，因为运维、值班、发布、排障的成本会摊薄到无法承受。按这个比例算，30 人的研发团队，微服务数量在 5 到 8 个左右是合理区间，超过 15 个基本可以断定拆细了。

拆分的第一个技术难题是分布式事务。我的建议是按业务影响分级处理，不要一上来就上重方案：

我特别想强调表格第一行。很多团队一上来就把库存和订单拆开，然后为了不超卖去搞分布式锁、搞 TCC，最后发现并发一高锁竞争比单体还严重。强一致的数据就该放在一个事务边界里，这条原则比任何分布式事务框架都靠谱。

拆分的第二个难题是可观测性。服务一多，一次请求跨五个服务，没有链路追踪就等于盲人摸象。最低配的三件套是：统一 traceId 贯穿全链路、每个服务记录出入参和耗时、关键业务动作打业务日志（不是技术日志）。我见过只打了log.info("enter method")这种日志的系统，故障排查基本靠猜。

还有一个经常被忽略的点：拆分之后，原来的单体数据库怎么办。理想状态是每个服务一个库，但现实里往往是先共享一个库，慢慢拆。共享库阶段的纪律是：一个表只能有一个服务写，读可以放开。这条不守，拆服务就是白拆，因为数据库层面还是耦合的。我在一个项目里用了一个很土但有效的检查手段：给每张表在配置中心登记"唯一写者"，构建时扫描代码里的 SQL，发现非写者服务出现写操作就报警。人工评审容易漏，工具不会。

5.2 SOA：那些年踩过的 ESB 坑

SOA 和微服务经常被混着讲，其实差别在于集成的重心在哪。SOA 时代倾向于把所有服务的集成逻辑收敛到一个中心化的总线里，服务之间的协议转换、路由、编排、监控全在那上面做。这套思路在企业内部系统整合上确实解决过大问题——一堆异构系统、不同协议、不同数据格式，靠一个总线做适配，比两两对接的 N×N 条线要清爽。

但它的问题也很典型。总线一旦成为所有流量的必经之路，它既是性能瓶颈也是变更瓶颈，任何一个小改动都要走总线的发布流程，排队等窗口。更麻烦的是业务逻辑会慢慢往总线里渗——反正这里能拿到所有服务的数据，编排写在这里最方便。写到后来总线里全是业务规则，谁也说不清一个流程的完整逻辑在哪。

现在的做法基本是把总线拆掉，路由和协议转换下沉到服务自身或者轻量的网关，编排放到具体的业务服务里。不是说中心化一定不好，而是中心化的组件必须严格限制职责：只做协议适配和流量治理，不承载任何业务编排。这条边界一旦破了，就会重演 ESB 的老路。

5.3 Serverless 与空间型架构：适合的场景其实很窄

Serverless 的吸引力在于按调用计费和免运维，适合的场景非常具体：突发、低频、无状态、执行时间短的任务。图片缩略图生成、webhook 接收、定时报表导出，这类用起来很舒服。反过来，长连接、常驻内存缓存、需要本地磁盘做大量临时文件的场景，用它就是自找麻烦。

成本这块要给个实感。假设一个函数配置 1GB 内存，单次执行 200 毫秒，每天调用 10 万次。计算方式是：0.2 秒 × 10 万 = 2 万秒的计费时长，按 1GB 折算就是 2 万 GB·秒。很多平台的免费额度就在几十万 GB·秒这个量级，也就是说这个量级还在免费区间内。但如果调用量涨到每天千万次，成本就会变得需要认真核算，而且高并发下的冷启动会让尾部延迟很难看。

冷启动这个问题值得单独说。函数实例闲置一段时间会被回收，下次请求要重新初始化运行环境、加载依赖、建立连接。Java 这类启动慢的运行时，冷启动几百毫秒到几秒都正常。缓解手段有：保持一定的预热实例、把依赖包压小、把初始化逻辑放到全局作用域只执行一次、避免在函数里建立重型连接池。我实测下来，把依赖从两百多兆压到三十兆以内，冷启动时间能砍掉一大半，这个优化性价比最高。

空间型架构（也叫云架构模式）解决的是另一个极端问题：高并发下数据库连接和会话状态成为瓶颈。做法是把应用状态放到共享内存网格里，处理单元无状态化，数据库只做持久化。这个模式在超高并发的场景下有它的价值，但对绝大多数系统来说是过度设计——你先把缓存用好、把慢查询干掉，通常就到不了需要它的地步。

6. 数据视角：CQRS 与事件溯源

6.1 CQRS：读写分离的进阶形态

CQRS 的核心是把"写模型"和"读模型"分开，写侧只负责接收命令、校验规则、产生状态变更，读侧用专门的模型响应查询。最轻的形态就是读写分离加一个查询服务，最重的形态是读写两套存储、两套模型、通过事件同步。

什么时候值得上？我的判断依据是读写两侧的诉求差异是否已经大到互相拖累。举几个我遇到过的真实信号：写侧的事务因为报表查询的锁竞争频繁超时；读侧要支持十几种维度的组合筛选，模型字段和写侧完全对不上；某个列表页要做多表聚合，SQL 已经优化不动了。出现这类信号，CQRS 就有意义。

代价主要有两个。第一是投影延迟，写完之后读模型要过一会儿才更新，用户点了保存刷新却没看到变化，这个体验问题必须有产品侧的配合，比如前端做乐观更新，或者提示"处理中"。第二是读模型重建，读侧逻辑改了或者数据出错了，要重放历史数据重建。我一般会保留原始事件日志或者变更日志，并且把读模型的构建逻辑做成可重放的纯函数，这样重建只是跑一遍的事。

落地顺序我建议从最轻的开始：先拆出一个独立的查询服务，读库做只读副本，写侧照旧。跑一段时间确认没问题，再考虑读模型完全独立存储。一上来就搞两套存储两套模型，工程量会让人怀疑人生。

6.2 事件溯源：不是所有系统都配得上它

事件溯源把状态存成一串不可变的事件，当前状态是重放事件算出来的。它的好处很诱人：完整的审计轨迹天然具备、可以回放到任意时间点、可以基于同一份事件构建多个不同的读模型。

但它的门槛比 CQRS 还高。第一是事件版本管理，业务规则变了，旧事件的语义怎么办？通常做法是事件结构只增不改，老事件靠升版器转换，这个转换逻辑要长期维护，是笔隐性成本。第二是重放性能，得算一算。假设每天产生 50 万条事件，单条重放耗时 1 毫秒，全量重放一天的数据就是 500 秒，接近九分钟。一个月的数据就是四个多小时，完全不可接受。所以必须做快照：每处理 N 条事件存一次状态快照，重放时从最近的快照开始往后补。N 的取值按"快照间隔内的重放时间控制在几秒"来定，1 毫秒一条的话，N 取 2000 到 5000 比较合适。

第三是查询极其不友好。你没法直接查"状态为已发货的订单有哪些"，因为状态不是存下来的。这就是为什么事件溯源几乎总是和 CQRS 一起出现：事件存储负责写，投影出来的读模型负责查。

我给的建议很直接：只有审计和追溯是核心诉求的系统才考虑事件溯源，比如账务流水、审批轨迹、风控决策记录。普通的业务系统用状态存储加变更日志表就能满足九成需求，硬上事件溯源会把简单问题复杂化。

7. 常见问题与排查技巧实录

7.1 架构误用的症状自查表

架构选错不会立刻报错，它表现为一堆说不清道不明的慢性病。我把这些年遇到的症状整理成一张表，看到对应症状基本就能定位到模式选型问题：

7.2 几个我踩过并记住的坑

坑一：把分层当成了微服务的前置步骤。有段时间我坚信"先把分层做好，将来拆服务就轻松了"，后来发现这两件事的收益方向不一样。分层解决的是依赖方向，拆服务解决的是部署和团队边界。一个分层做得完美的单体，拆服务时依然要处理数据归属、跨服务事务、链路追踪这些新问题。别指望做了一件事能顺带拿到另一件事的结果。

坑二：事件发出去就不管了。早期我做的第一个事件驱动模块，发布方发完就完事，消费方失败只打日志。上线三个月后发现积分少发了十几万条，原因是某个消费端在版本升级时把消费者组名改了，导致积压。后来我加了两样东西：消费延迟监控（积压超过阈值报警）和每日业务对账（下单数和积分发放数比对）。对账这个看起来很笨的手段，是所有最终一致系统最后的安全网。

坑三：为了架构图好看引入用不上的模式。我在一个只有六个表的内部系统里上过 CQRS，写了一套命令、事件、投影、读模型，代码量是原方案的三倍，团队三个人维护了半年，最后自己又改回去了。这件事教会我一个判断标准：如果引入一个模式，你说不出它具体省掉了哪件麻烦事，那就是不该引入。

坑四：忽略架构决策的记录。我们曾经在一个项目里争论了整整一周要不要拆某个模块，最后决定不拆。半年后新人进来又问同样的问题，因为没人记得当时的理由。后来我开始写架构决策记录，一页纸，四段内容：背景、可选方案、最终决定、放弃其他方案的理由。这东西的价值在半年后体现得最明显，比任何设计文档都实用。

7.3 我现在的选型流程

走到今天，我做一个新项目的选型基本是这么几步，分享出来供参考。

第一步，先算清楚三个数：团队人数、日活或者日请求量的量级、业务边界的稳定程度。这三个数基本能决定大方向。团队小、量不大、边界还在变，那答案几乎总是模块化单体加清晰分层，其他先别想。

第二步，找出真正的痛点，而不是想象中的痛点。拿最近三个月的线上问题和需求变更记录翻一遍，统计一下时间花在哪：是改需求花的时间多，还是排查故障花的时间多，还是发布协调花的时间多。痛点在哪，架构就往哪个方向优化。

第三步，做最小验证。想上事件驱动，先在一个非核心的流程上试，比如消息通知；想上 CQRS，先只读侧独立；想拆服务，先拆一个边界最清晰的。跑一两个月看数据，别一上来就全量重构。我见过太多"大爆炸式重构"，半年没上线，最后项目黄了。

第四步，把约束写进工具。架构靠人守不住，靠工具才守得住。模块间依赖检查、表前缀检查、跨层调用检查，能自动化的全自动化。人只会遵守能报错的规则。

最后再说一个小体会。这些年我看过的架构里，真正跑得好的系统，模式往往没什么花哨的，就是分层清晰、边界明确、日志齐全、补偿到位。反而是那些架构图画得很漂亮、模式堆了一堆的系统，维护起来最费劲。架构的目标是让改动变便宜，不是让设计显得高级。想清楚这句话，大部分选型纠结其实都能自己解开。