从 巨型单体应用 + 几十张表共享一个数据库 + 服务间全是同步阻塞调用 + 模块边界靠口头约定 + 改一行回归整个系统 + 发布停掉整个应用 + 只有贫血 CRUD 远古架构 → 2026 DDD 领域驱动设计 + 限界上下文 + 微服务独立部署 + 事件驱动架构 + CQRS 读写分离 + Saga 最终一致性 + API 网关 + 每服务独立数据库 现代架构体系 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学

这是我们平台架构团队 16 个人耗时 87 天,把一套用了七年的"巨型单体应用 + 所有模块塞进一个进程 + 几十张表共享一个数据库 + 服务间全是同步阻塞调用 + 模块边界靠口头约定 + 改一行代码要回归整个系统 + 发布要停掉整个应用 + 没有任何领域模型只有贫血的 CRUD"的远古架构,整体重构到 2026 年"DDD 领域驱动设计 + 限界上下文清晰划界 + 微服务独立部署 + 事件驱动架构异步解耦 + CQRS 读写分离 + Saga 最终一致性 + API 网关 + 每服务独立数据库"现代架构体系的真实战役复盘。重构前,我们的系统是典型的"大泥球(big ball of mud)":一个几百万行的单体,任何一个小需求都要在层层缠绕的代码里小心翼翼地改,牵一发而动全身;一个非核心模块的内存泄漏能拖垮整个应用;团队几十人挤在一个代码库里相互踩脚,发布排队排到天荒地老。重构后,我们按业务领域把系统拆成了边界清晰、独立部署、各自拥有数据的微服务,服务间用事件异步解耦,复杂查询用 CQRS 分流,跨服务一致性用 Saga 保障。这 87 天里我们沉淀了 47 套工程修法、7 个 P0 事故复盘和 6 条工程哲学,本文毫无保留地分享出来。

需要先说明:架构现代化不是"把单体拆成微服务"这么简单——拆错边界的微服务比单体更痛苦,会带来分布式系统的全部复杂度却享受不到解耦的好处。真正的关键是先用 DDD 划清领域边界,再谈拆分。下面这张表,概括了我们重构前后在十个核心维度上的对比,每一行背后都是数周攻坚。

一、DDD 战略设计:用限界上下文划清服务边界

重构的第一仗,也是整场战役成败的关键,是 DDD(领域驱动设计)的战略设计。我们见过太多团队上来就按技术分层或数据表拆微服务,结果拆出一堆"贫血的 CRUD 服务",服务间互相疯狂调用,分布式单体比单体还糟。我们的做法是先做事件风暴(event storming),和业务专家一起把整个业务流梳理出来,识别出领域事件、命令、聚合,再据此划分限界上下文(bounded context)——每个上下文是一个内聚的业务能力边界,边界之内概念统一、模型自洽,边界之间通过明确的契约通信。一个限界上下文,往往就是一个微服务的合理粒度。下面是我们订单上下文里的聚合根设计:

// DDD 充血聚合根:业务规则内聚在领域对象里,而非散落在 Service 的 if-else
public class Order {  // 聚合根:订单是一致性边界,外部只能通过它操作订单项
    private final OrderId id;
    private OrderStatus status;
    private final List<OrderItem> items = new ArrayList<>();
    private final List<DomainEvent> events = new ArrayList<>();  // 暂存领域事件

    // 业务行为是方法,而非裸 setter——规则在聚合内强制执行
    public void pay(Money amount) {
        if (status != OrderStatus.CREATED)
            throw new IllegalStateException("只有待支付订单才能支付");
        if (!amount.equals(totalAmount()))
            throw new IllegalStateException("支付金额与订单金额不符");
        this.status = OrderStatus.PAID;
        // 发布领域事件:解耦后续动作(扣库存、通知发货),由订阅方异步处理
        events.add(new OrderPaidEvent(id, totalAmount(), Instant.now()));
    }

    private Money totalAmount() {
        return items.stream().map(OrderItem::subtotal)
                    .reduce(Money.ZERO, Money::add);
    }

    public List<DomainEvent> pullEvents() {  // 由仓储在持久化后取出并投递
        var pending = List.copyOf(events);
        events.clear();
        return pending;
    }
}

DDD 战略设计让我们的服务拆分从"按数据表或技术分层乱拆"进化到了"按业务能力的限界上下文来拆":每个微服务对应一个内聚的业务领域,边界之内模型统一、规则自洽,边界之间靠明确契约通信,服务粒度恰到好处,既不会碎到处处分布式调用,也不会粗到又变回单体;充血的聚合根把业务规则牢牢内聚在领域对象里,而不是散落在一堆 Service 的 if-else 中,代码第一次能让业务专家也读得懂;领域事件则成了上下文之间解耦的天然接缝。我们踩过的最大的坑,就是早期没做 DDD 就按表拆服务,拆出来的服务之间疯狂地同步互调,活活拆出一个比单体更难维护的分布式单体,返工重拆才走上正轨。架构现代化的第一性原理是:先理解业务、划清边界,再谈技术拆分——边界对了,后面的事件驱动、CQRS、Saga 才有意义;边界错了,再好的技术也是给错误的结构添乱。

二、微服务拆分:从巨型单体到独立部署单元

第二仗,是按划好的限界上下文把单体真正拆成独立部署的微服务。这里最反直觉、也最重要的一条原则是:每个微服务必须独占自己的数据库,绝不允许两个服务直接读写同一张表。共享数据库是微服务最隐蔽的耦合——表面上服务拆开了,实际上谁都不敢动那张共享表的结构,改一个字段要协调一圈,本质还是单体。我们为每个服务配了独立的数据库(schema 或物理库),服务间要数据只能通过对方的 API 或订阅对方的事件,绝不越界直连数据库。下面是我们用 docker-compose 描述的"每服务独立库"的拓扑:

# 微服务拓扑:每个服务独占自己的数据库,杜绝共享库这个隐蔽耦合
services:
  order-service:          # 订单上下文
    image: registry/order-service:2026.5
    environment:
      DB_URL: jdbc:postgresql://order-db:5432/orderdb
    depends_on: [order-db, kafka]
  order-db:               # 订单服务独占的库,其他服务不得直连
    image: postgres:17
    environment: { POSTGRES_DB: orderdb }

  inventory-service:      # 库存上下文,独立部署、独立扩缩容
    image: registry/inventory-service:2026.5
    environment:
      DB_URL: jdbc:postgresql://inventory-db:5432/invdb
    depends_on: [inventory-db, kafka]
  inventory-db:           # 库存服务独占的库
    image: postgres:17
    environment: { POSTGRES_DB: invdb }

  kafka:                  # 事件总线:服务间异步解耦的脊梁
    image: bitnami/kafka:3.7

微服务拆分 + 每服务独立数据库,让我们的系统从"几十人挤在一个代码库、共享一个大库、改任何东西都要全局协调"进化到了"按业务边界切分、各服务独立演进":每个服务有自己的代码库、自己的数据库、自己的部署节奏,一个团队可以完全自治地开发、测试、上线自己的服务,再不用排队等全站发布;故障也被隔离在服务边界内,某个非核心服务挂了不会再拖垮整个系统;独立的数据库让每个服务能根据自己的访问模式选择最合适的存储和索引,而不是所有人将就一个大库。我们坚持的铁律是"数据库私有"——服务间通信只走 API 和事件,任何"为了图快直接连人家库"的捷径都被严令禁止,因为那是把刚拆开的耦合又焊回去。拆分的本质不是把代码切碎,而是把"变化的边界"对齐到"团队和部署的边界",让系统的每一部分都能独立地变化、独立地发布、独立地失败。

三、事件驱动架构:用消息解耦同步阻塞调用

第三仗,是把服务间的同步阻塞调用换成事件驱动的异步通信。拆完微服务后我们立刻撞上一个新问题:订单支付成功后要扣库存、要通知发货、要发积分、要推消息,如果订单服务同步地一个个去 RPC 调这些下游,任何一个下游慢了或挂了,整条链路就被拖住甚至雪崩,服务间又退化成了紧耦合。事件驱动架构(EDA)的思路是:订单服务只管把"订单已支付"这个领域事件发到消息总线上,至于谁关心、谁要做什么,由各个订阅方自己决定——订单服务根本不需要知道下游有谁。这样上下游在时间和空间上都解耦了,下游临时挂掉也不会影响上游,消息会堆在队列里等它恢复。下面是我们基于 Kafka 的事件发布与消费:

// 事件驱动:订单服务只发事件,不关心谁消费——彻底解耦上下游
@Service
public class OrderEventPublisher {
    private final KafkaTemplate<String, String> kafka;

    // 仓储保存订单后,把聚合暂存的领域事件投递到总线
    public void publish(List<DomainEvent> events) {
        for (DomainEvent e : events)
            // key 用聚合 id,保证同一订单的事件有序;topic 即事件类型
            kafka.send("order.paid", e.aggregateId(), toJson(e));
    }
}

// 库存服务:订阅订单事件,自主决定"扣减库存"——上游对此一无所知
@Component
public class InventoryEventListener {
    @KafkaListener(topics = "order.paid", groupId = "inventory")
    public void on(String payload) {
        OrderPaidEvent e = fromJson(payload, OrderPaidEvent.class);
        // 幂等消费:用事件 id 去重,防止重复投递导致重复扣减
        if (processed.contains(e.eventId())) return;
        inventory.deduct(e.orderId(), e.items());
        processed.add(e.eventId());
    }
}

事件驱动架构让我们的服务通信从"同步阻塞、一环卡死全链路雪崩"进化到了"异步解耦、上下游互不拖累":上游发完事件就返回,不必同步等待任何下游,响应延迟大幅下降;下游临时故障或重启,消息安静地堆在队列里等它恢复后继续消费,再不会出现"发货服务挂了导致用户连下单都失败"的荒唐级联;新增一个订阅方(比如要加个数据分析消费)对上游零侵入,上游代码一行都不用改,系统的可扩展性发生了质变。我们也认真处理了 EDA 的代价:消息可能重复投递,所以每个消费者都做了基于事件 id 的幂等;消息是最终一致而非强一致,所以我们在产品层面接受了"支付成功后库存扣减有毫秒级延迟"这种弱一致。事件驱动的本质,是把"我命令你做某事"的命令式耦合,变成"我宣布发生了某事,有兴趣的自取"的事实广播——前者让系统紧紧缠绕,后者让系统松散自治。

四、CQRS:读写分离应对复杂查询

第四仗是 CQRS(命令查询职责分离)。微服务 + 独立库解决了写入侧的解耦,但很快暴露出查询的难题:过去单体一个大库,前端要个"订单列表带商品名、带库存状态、带物流信息"的页面,一条多表 JOIN 就搞定了;拆成微服务后这些数据分散在订单库、库存库、物流库,没法 JOIN 了。如果让 BFF 去同步调三个服务再内存拼装,既慢又脆。CQRS 的思路是把"写模型"和"读模型"彻底分开:写侧维护规范化的领域聚合,专注保证业务规则和一致性;读侧则订阅各服务的事件,把数据预先冗余、反规范化地拼成一张专门为查询优化的读模型(物化视图),查询时直接读这张宽表,飞快。下面是我们的读模型投影器:

// CQRS 读模型投影:订阅多个服务的事件,拼成一张为查询优化的宽表
@Component
public class OrderViewProjector {
    private final OrderViewRepository views;  // 专门的读库,反规范化宽表

    // 写侧发生了什么,读侧就把投影更新成什么——读写在事件处异步同步
    @KafkaListener(topics = "order.paid", groupId = "order-view")
    public void onPaid(OrderPaidEvent e) {
        OrderView v = views.findById(e.orderId()).orElseGet(OrderView::new);
        v.setOrderId(e.orderId());
        v.setStatus("PAID");
        v.setTotalAmount(e.totalAmount());
        views.save(v);  // 一次写入,查询时无需任何 JOIN
    }

    @KafkaListener(topics = "inventory.deducted", groupId = "order-view")
    public void onDeducted(InventoryDeductedEvent e) {
        // 把库存服务的状态冗余进订单视图——查询时一站式拿到
        views.findById(e.orderId()).ifPresent(v -> {
            v.setStockStatus("RESERVED");
            views.save(v);
        });
    }
}

CQRS 让我们的查询从"跨服务同步调用再内存拼装、又慢又脆"进化到了"直接读一张为查询量身定制的反规范化宽表,飞快且稳定":读模型由各服务的事件异步驱动更新,查询时无需任何跨服务调用、无需任何 JOIN,复杂列表页的响应从几百毫秒降到个位数毫秒;写模型则卸下了查询的包袱,可以专心用规范化的聚合保证业务规则和写入一致性,读写两侧各自用最适合的存储和模型,互不掣肘;读侧还能独立扩缩容,大促时查询压力大就单独给读库加副本,完全不影响写入。CQRS 的代价是读模型相对写模型有最终一致的延迟,以及要额外维护投影逻辑,所以我们只在"查询模式复杂、读写比例悬殊"的核心场景上用它,简单的增删改查并不强行 CQRS。它的本质是承认一个朴素的事实:读和写是两种诉求截然不同的操作——写要一致、读要快——硬用一个模型同时服务两者,只会两头都将就。

五、Saga:分布式事务的最终一致性

第五仗,是分布式事务。单体时代一个下单流程"扣库存、扣余额、建订单"用一个数据库本地事务就能保证原子性,要么全成要么全滚。拆成微服务后,这三步分属三个服务三个库,没有了横跨它们的本地事务,传统的两阶段提交(2PC)又重又慢还会长时间锁资源,在高并发下根本不可用。我们用 Saga 模式来保证跨服务的最终一致性:把一个大事务拆成一串本地事务,每一步都有对应的"补偿操作",如果某一步失败了,就反向依次执行前面已成功步骤的补偿,把系统回滚到一致状态。下面是我们的编排式(orchestration)Saga:

// Saga 编排:一步步推进,任一步失败则反向补偿,保证最终一致
public class PlaceOrderSaga {
    public void execute(OrderContext ctx) {
        var completed = new ArrayDeque<Runnable>();  // 已成功步骤的补偿栈
        try {
            inventory.reserve(ctx.items());                 // 步骤1:预留库存
            completed.push(() -> inventory.release(ctx.items()));  // 其补偿:释放
            payment.charge(ctx.userId(), ctx.amount());     // 步骤2:扣款
            completed.push(() -> payment.refund(ctx.userId(), ctx.amount()));
            order.confirm(ctx.orderId());                   // 步骤3:确认订单
        } catch (Exception e) {
            // 任一步失败:依次执行已完成步骤的补偿,反向回滚到一致状态
            while (!completed.isEmpty()) {
                try { completed.pop().run(); }
                catch (Exception ce) { alert.send("补偿失败需人工介入", ce); }
            }
            throw new SagaFailedException("下单失败已补偿回滚", e);
        }
    }
}

Saga 让我们的跨服务一致性从"要么用 2PC 重锁拖垮性能、要么干脆不管导致数据错乱"进化到了"用补偿换最终一致、高并发下依然顺畅":一个下单流程被拆成预留库存、扣款、确认订单几个本地事务,各服务只管好自己库里的本地事务,无需任何分布式锁,吞吐和单体本地事务相当;一旦中途某步失败,Saga 自动反向执行已成功步骤的补偿操作,把库存放回、把钱退回,系统最终回到一致状态,绝不会出现"钱扣了但订单没建"的资损;补偿失败这种极端情况则触发告警转人工兜底,而不是默默吞掉。我们的经验是:Saga 要求每一步都设计出幂等的、可补偿的操作,这对业务建模提出了更高要求,但回报是在分布式下既保住了一致性又不牺牲性能。分布式事务的本质认知是:在微服务世界里,强一致(ACID)往往是奢侈且危险的,拥抱最终一致、用补偿而非锁来保证正确性,才是符合分布式系统物理规律的工程选择。

六、API 网关与 BFF:统一入口与按端定制

拆成微服务后,客户端直连后端的老路就走不通了——前端难道要知道有几十个服务、各自的地址、各自的鉴权方式?我们在所有微服务前面架了一层 API 网关,把横切关注点(鉴权、限流、熔断、日志、协议转换)统一收口到网关层,后端服务只管纯粹的业务逻辑;对客户端则只暴露一个稳定的统一入口,内部服务怎么拆分、怎么迁移,客户端完全无感。API 网关让我们把散落在每个服务里重复实现的鉴权、限流、熔断等横切逻辑统一收口到一处,后端服务彻底卸下这些非业务负担、变得更纯粹,横切策略的调整也只需改网关一处而非几十个服务;客户端则永远只面对一个稳定入口,我们在背后拆分、合并、迁移服务时,客户端一行代码都不用改。在网关之上,我们进一步为不同前端(Web、App、小程序)做了 BFF(Backend For Frontend)——每个前端有一个专属的后端聚合层,按该端的页面需求把多个微服务的数据聚合裁剪成正好合适的形状,既避免了前端发起一堆碎请求,也避免了用一个臃肿的通用接口去将就所有端。网关与 BFF 的本质,是在"服务自治的内部"和"体验统一的外部"之间架一道转换层,让内外两侧都能按各自最舒服的方式演进。

七、服务发现与配置中心:让动态拓扑可治理

微服务的实例是动态的——会扩缩容、会重启、会漂移到不同节点,硬编码 IP 地址那一套彻底失效了。我们引入服务发现:每个服务实例启动时自动注册到注册中心,调用方通过服务名而非 IP 来寻址,注册中心实时维护着"谁还活着、在哪里"的拓扑,实例上下线对调用方透明。配置同理,我们把散落在各服务配置文件里的参数收拢到统一的配置中心,支持环境隔离、动态下发、灰度推送,改个限流阈值不用重启服务、不用重新发布。服务发现让我们的服务调用从"硬编码 IP、实例一变就要改配置重启"进化到了"按服务名寻址、实例动态增减全程透明":扩容时新实例自动加入、被自动分流,缩容或宕机的实例被自动摘除,调用方无需任何感知;配置中心则让我们告别了"改个参数要改文件、重新打包、重新发布"的笨重流程,配置变更秒级动态生效、可灰度、可一键回滚,运维敏捷度大幅提升。这两件基础设施看似不起眼,却是动态微服务拓扑能够被治理的前提——没有它们,几十个会自由伸缩漂移的服务就是一团没人管得住的乱麻。它们的共同本质是把"硬编码的静态假设"换成"运行时的动态发现",让系统能够从容地应对自身拓扑的持续变化。

八、绞杀者模式:零中断地把单体迁移到微服务

把一个跑了七年、承载着核心业务的巨型单体重写成微服务,如果选择"停下来花一年重写、然后某天一次性切换",几乎注定失败——业务不会为你暂停,大爆炸式重写的风险高到无法承受。我们用了绞杀者模式(strangler fig pattern):在单体前面架一层路由(就是上面的 API 网关),然后一个限界上下文一个限界上下文地把功能从单体里剥离出来、重写成新的微服务,每剥离一块,就把网关上对应的流量从单体切到新服务,单体的职责被一点点"绞杀"、新体系的版图一点点扩大,直到老单体被完全架空、下线。绞杀者模式让我们在业务零中断的前提下完成了整个架构的更替:任何时刻系统都是可用的,我们只是把流量逐个上下文地从老单体迁到新服务;每迁移一块都是小步、可灰度、可回退的,新服务出问题就把网关流量切回单体,风险被切成了无数个可控的小块;团队也能边迁移边交付新需求,而不是冻结业务陪着重写。最关键的一条纪律是:绝不允许"新服务直接读老单体的数据库"这种过渡期捷径长期存在,数据所有权必须随功能一起迁移干净,否则迁移永远完不成。架构迁移的本质智慧,是承认"推倒重来"在真实业务面前几乎总是错的——唯有"渐进式地、保持系统始终运行地演进",才是大型系统现代化唯一可靠的路径。

九、7 个 P0 事故复盘

7 事故:(1) 早期没做 DDD 就按表拆服务,拆出分布式单体、服务间疯狂同步互调,返工用事件风暴重划限界上下文;(2) 两个服务图快直连了同一张表,改字段时一方崩溃,强制数据库私有 + 只走 API/事件;(3) 同步调用链过长,下游抖动引发上游雪崩,改事件驱动异步 + 熔断降级;(4) Kafka 消息重复投递导致库存重复扣减,所有消费者加基于事件 id 的幂等;(5) Saga 补偿操作自身失败导致状态卡死,补偿设计为幂等 + 失败转人工告警兜底;(6) CQRS 读模型投影滞后,用户支付完看订单还是待支付,前端加"处理中"过渡态 + 缩短投影延迟;(7) 配置中心一次错误推送瞬间影响所有服务,配置变更改为灰度推送 + 强制二次确认。每个 P0 都做 5-Why 复盘,固化成架构评审清单或自动化校验,确保同类问题不再复发。

十、架构师的 6 条工程哲学

6 哲学:(1) 先划边界再谈拆分——DDD 限界上下文是微服务的前提,边界错了一切皆错;(2) 数据库必须私有——共享库是最隐蔽的耦合,服务间只走 API 和事件;(3) 能异步就别同步——事件驱动让系统松散自治,同步调用让系统紧紧缠绕;(4) 拥抱最终一致——分布式下强一致是奢侈品,用 Saga 补偿而非分布式锁;(5) 读写分而治之——读要快写要一致,复杂查询场景上 CQRS;(6) 演进而非重写——大型系统现代化只能用绞杀者模式渐进迁移。这 6 条哲学,是我们用 7 个 P0 事故和 87 天攻坚换来的集体共识。它们共同指向一个认知:微服务不是银弹,它用分布式的复杂度换取了团队和部署的自治——只有当系统大到单体的协作成本超过了分布式的复杂度成本时,这笔交易才划算。架构的精髓不在追新技术,而在判断何时该拆、按什么边界拆、以及拆开后如何用事件、CQRS、Saga 把分布式的复杂度重新管理好。

十一、重构收益的量化:7 个关键数字

7 数字:(1) 单次发布影响范围:整个单体 → 单个服务,爆炸半径缩小一个数量级;(2) 发布频率:每两周一次全站发布 → 各服务每天独立发布数十次;(3) 复杂列表页响应:几百毫秒多表 JOIN → CQRS 宽表个位数毫秒;(4) 故障爆炸半径:一处崩全站崩 → 隔离在单个服务内;(5) 新需求平均交付周期:数周(要协调全局)→ 天级(单团队自治);(6) 核心链路峰值吞吐:同步阻塞受限 → 事件异步解耦后提升数倍;(7) 架构迁移期间业务中断:预想的停机切换 → 绞杀者模式零中断。这些数字背后,是 87 天里 16 个人无数次的边界论证、迁移演练和深夜攻坚,但每一个都实打实地转化成了交付效率和系统韧性的提升。当我们把这份数据汇报给管理层时,最有说服力的不是任何架构名词,而是"发布从全站停机到各服务每天几十次、故障再不会一崩全崩"这两条。

十二、留给后来者的最后一句话

87 天的架构现代化战役,我们走过的不只是一条从巨型单体到微服务、从同步阻塞到事件驱动、从共享大库到数据自治的技术升级路,更是一次从"一团缠绕的大泥球"到"边界清晰、各自自治、松散协作的服务生态"的认知跃迁。当一个团队第一次能完全自主地发布自己的服务而不必看全公司脸色、当一个非核心服务的崩溃第一次没有拖垮整个站点、当一个复杂查询页第一次从几百毫秒降到个位数毫秒、当我们用绞杀者模式不停机地把七年单体平滑迁走的那一刻,真正点燃我们的,不是微服务这个时髦词,而是"系统的复杂度终于从无人能掌控的混沌,变成了被边界、事件和契约清晰治理的有序"的踏实与笃定。架构没有银弹,微服务更不是终点——关键是理解 DDD、事件驱动、CQRS、Saga 各自解决什么问题、代价是什么,然后诚实地评估自己的系统是否真的大到需要这些,再做体系化的取舍。尤其要克制"为了微服务而微服务"的冲动:如果你的单体还能让团队从容协作,那它就是好架构;只有当协作和部署的痛超过了分布式的复杂度时,拆分才真正划算。愿每一位还困在大泥球里、被牵一发动全身折磨的同行,都能早日为自己的系统划清边界、重获秩序。共勉,后会有期。

—— 别看了 · 2026