从单体 + 微服务杂烩 → DDD + CQRS + Event Sourcing + Saga + Cell-based + 0 信任全栈架构现代化 42 天踩坑录:15 反模式 + 16 修法

2026 年 1 月初到 3 月中,我作为 chief architect 带 73 位工程师 / 架构师 / SRE,用 42 天把公司"核心系统架构"从 2022 年的"单体 + 微服务杂烩"重构为现代"事件驱动 + DDD + CQRS + Event Sourcing + Saga + Service Mesh + Multi-Cluster Active-Active + Cell-based + 多租户隔离 + 0 信任安全"的全栈现代化架构。覆盖 523 个微服务 + 14 个 BU + 9 个 region + 4 朵云 + 47 万 QPS 峰值 + 8.7 PB 数据,期间踩了 15 个反模式 + 11 次回滚 + 4 次 P0 + 9 次 P1,沉淀 16 套修法 + 30 个架构议题。这篇是 42 天踩坑全记录,献给所有还在和"分布式单体"搏斗的架构师同行。

一、架构演进的"4 个阶段"

2018-2026 我们公司架构演进 4 阶段:(1) 2018-2020 单体阶段:1 个 Java EE 巨石,1500 万行,400 工程师挤一个 repo;(2) 2020-2022 微服务阶段:盲目拆,服务 800+ 个,但还共享数据库 = 分布式单体;(3) 2022-2024 治理阶段:服务网格 + 服务降到 600,引入 DDD 限界上下文;(4) 2024-2026 现代化阶段:事件驱动 + CQRS + Saga + Cell-based + 0 信任,523 服务但边界清晰。4 阶段教训:架构不是终点,是持续演进过程。

二、DDD 限界上下文(Bounded Context)的"6 个识别法则"

DDD 限界上下文识别 6 法则:(1) 业务能力相对独立:订单 BC 不依赖营销 BC;(2) 团队边界对应:Conway's Law 强对应;(3) 数据模型独立:订单 BC 的"用户"≠ 用户中心的"用户";(4) 语言独立:同一术语在不同 BC 含义不同;(5) 部署独立:可独立发布;(6) 生命周期独立:可独立演进。实战:14 个 BU 识别出 47 个 BC,每个 BC 拥有 8-15 个微服务,跨 BC 通信全部走事件 + API,无直查 DB。

三、Event Storming 工作坊的"5 个步骤"

Event Storming 工作坊在 42 天的运作:(1) Big Picture Event Storming:全公司核心事件 200+ 张便利贴上墙;(2) Process Modeling:每个事件的 command / actor / policy / read model;(3) Software Design:把事件聚类成 Aggregate / BC;(4) 命名细化:统一术语表(ubiquitous language);(5) Tech mapping:每个 BC 落地到代码仓库 + DB + Topic。5 天工作坊出 47 个 BC + 320 个核心事件 + 720 个 command,所有团队语言对齐。

四、聚合根(Aggregate Root)的"7 条铁律"

聚合根设计 7 条铁律:(1) 一个事务只改一个聚合;(2) 聚合内强一致,跨聚合最终一致;(3) 聚合间通过 ID 引用,不持有对象;(4) 聚合应小:1 个聚合通常 ≤ 5 个实体;(5) 仓储(Repository)每聚合根 1 个,禁止聚合内实体直接查;(6) 聚合内业务规则封装在领域方法,无贫血;(7) Aggregate Root 是唯一事务一致性边界。523 服务遵守这 7 条后,分布式事务从 47 处降到 3 处(全部 Saga 化)。

五、CQRS 的"工程价值"

CQRS(Command Query Responsibility Segregation)在 4 个核心 BC 落地的工程价值:(1) Command 端:写 model,聚合 + 事件 + 强一致;(2) Query 端:多个 read model,各自优化(Elasticsearch / Redis / Postgres 物化视图);(3) 写读不互相阻塞,QPS 大幅提升;(4) Read model 可重建(replay events),业务逻辑变更不影响数据;(5) 复杂查询(报表 / BI)走专用 read model,不污染主流程。实测:订单 BC 读 QPS 从 8K 升到 47K,写 QPS 从 3K 升到 12K,p99 延迟降 60%。

@Aggregate
public class OrderAggregate {
    @AggregateIdentifier
    private OrderId orderId;
    private OrderStatus status;
    private Money totalAmount;
    private List<OrderItem> items;

    @CommandHandler
    public OrderAggregate(CreateOrderCommand cmd) {
        validateInventory(cmd.items());
        AggregateLifecycle.apply(new OrderCreatedEvent(
            cmd.orderId(), cmd.userId(), cmd.items(), cmd.totalAmount()
        ));
    }

    @CommandHandler
    public void handle(PayOrderCommand cmd) {
        if (status != OrderStatus.CREATED) {
            throw new IllegalStateException("Order not payable");
        }
        AggregateLifecycle.apply(new OrderPaidEvent(orderId, cmd.paymentId()));
    }

    @EventSourcingHandler
    public void on(OrderCreatedEvent ev) {
        this.orderId = ev.orderId();
        this.status = OrderStatus.CREATED;
        this.totalAmount = ev.totalAmount();
        this.items = ev.items();
    }

    @EventSourcingHandler
    public void on(OrderPaidEvent ev) {
        this.status = OrderStatus.PAID;
    }
}

六、Event Sourcing 的"5 大优势"

Event Sourcing 在订单 / 库存 / 支付 / 风控 4 大 BC 上的 5 大优势:(1) 完整审计:每次状态变更都有事件,合规审计天然满足;(2) 时间旅行:任意时间点的状态可重建;(3) 多视角投影:同一份事件流投影到不同 read model;(4) 业务回放:bug 修复后可重放事件验证;(5) 易演进:新业务规则可基于历史事件重新计算。金融审计要求"何时何人改了订单",ES 让审计从 7 天降到 7 分钟。

七、Event Sourcing 的"5 大坑"

Event Sourcing 5 大坑:(1) 事件 schema 演进:JSON Schema 版本号 + upcaster 必备;(2) Snapshot:聚合事件超 100 必须建快照,否则启动慢;(3) 重放慢:大事件流(亿级)重放 24 小时+,需要 partition + 并行;(4) Eventual consistency 业务方理解难;(5) 查询复杂:必须配合 CQRS,不能直接 query event store。523 服务中只有 4 个核心 BC 用 ES,其他用普通 state-based 持久化。

八、Saga 模式的"2 种实现"

Saga 模式在跨 BC 流程的 2 种实现:(1) Choreography(编排):服务间通过事件协作,每个服务订阅相关事件,无中心 — 优:松耦合,适合简单 saga(3-4 步);(2) Orchestration(协调):中心 orchestrator 显式调度每一步 — 优:可视化、补偿逻辑集中,适合复杂 saga(5+ 步)。我们 73 个 saga 中,Choreography 占 60%(简单),Orchestration 占 40%(复杂业务流如下单 → 支付 → 库存 → 物流 → 通知)。

apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: order-saga-orchestrator
spec:
  entrypoint: order-flow
  arguments:
    parameters:
      - name: order_id
  templates:
    - name: order-flow
      dag:
        tasks:
          - name: reserve-inventory
            template: call-service
            arguments:
              parameters: [{name: action, value: "POST /inventory/reserve"}]
            onExit: handle-inventory-failure
          - name: charge-payment
            template: call-service
            dependencies: [reserve-inventory]
            arguments:
              parameters: [{name: action, value: "POST /payment/charge"}]
            onExit: refund-on-fail
          - name: create-shipment
            template: call-service
            dependencies: [charge-payment]
            arguments:
              parameters: [{name: action, value: "POST /shipment/create"}]
            onExit: cancel-on-fail
          - name: notify-user
            template: call-service
            dependencies: [create-shipment]
    - name: refund-on-fail
      template: call-service
      arguments:
        parameters: [{name: action, value: "POST /payment/refund"}]
    - name: handle-inventory-failure
      template: call-service
      arguments:
        parameters: [{name: action, value: "POST /inventory/release"}]

九、分布式事务的"5 个替代方案"

分布式事务在 2026 年的 5 个替代:(1) Saga(主流):事务步骤化 + 补偿;(2) Outbox Pattern:本地事务保证业务 + 事件原子,后台进程发事件;(3) TCC(Try-Confirm-Cancel):金融场景强一致;(4) Event Sourcing + Process Manager:事件流 + 状态机;(5) 业务上避免:重新设计避免跨服务原子。523 服务 0 个 XA / 2PC,Saga + Outbox 覆盖 95% 场景。

十、Outbox Pattern 的工程实现

Outbox Pattern 的工程实现 5 步:(1) 业务表 + outbox 表在同一数据库;(2) 业务事务同时写业务数据 + outbox 记录(本地原子);(3) Debezium CDC 监听 outbox 表;(4) CDC → Kafka topic;(5) outbox 记录定期清理(7 天)。过去 12 个月零事件丢失,outbox 7300 万行 / 月,CDC 延迟 < 200ms。

十一、消息系统选型:Kafka vs Pulsar vs RabbitMQ

2026 年消息系统选型:(1) Kafka 3.7:吞吐王者(单 broker 1M msg/s)、生态最全、KRaft 模式无 ZK;(2) Pulsar 3.3:多租户原生、分层存储 / 计算解耦、地域复制;(3) RabbitMQ 4.x:低延迟(< 1ms)、复杂路由、AMQP 标准。我们用 Kafka 跑事件流(523 服务,日均 470 亿事件),Pulsar 跑多租户消息(380 企业租户),RabbitMQ 跑 RPC fanout 与定时任务。

十二、事件 Schema 治理的"6 条铁律"

事件 Schema 治理 6 铁律:(1) Schema Registry(Confluent / Apicurio)强制注册;(2) 向后兼容:新字段 nullable 或带 default;(3) 向前兼容:消费者忽略未知字段;(4) 版本号在 topic 名(如 order.events.v3);(5) Major 变更需新 topic + 双写过渡;(6) 公司级 schema review 每周。过去 12 个月 schema 变更 1247 次,因 schema 引起的故障 0 次。

十三、Cell-based Architecture 的"5 大价值"

Cell-based Architecture(Amazon / Slack 推广)在我们 47 万 QPS 的 5 大价值:(1) 故障隔离:每 cell 服务一个 user shard,A cell 挂不影响 B cell;(2) Blast radius 控制:发布 / 配置 / 灰度按 cell 推;(3) 容量水平扩展:加 cell 即可,无需改服务;(4) Region 容灾:每 region 部署 N 个 cell;(5) Multi-tenant 强隔离:大客户独占 cell。14 个 cell 服务 14 个 BU,过去 12 个月 cell-level 故障 17 次但全部隔离,无跨 cell 影响。

十四、Service Mesh 治理的"7 大维度"

Istio 1.24 Ambient Mesh 在 523 服务上的 7 大治理:(1) mTLS 全网:STRICT 模式,0 内网信任;(2) 流量切分:HTTPRoute weighted backend;(3) 熔断:DestinationRule outlierDetection;(4) 重试:HTTPRoute retries.backoff;(5) 限流:EnvoyFilter rate limit;(6) Tracing:OTel + Tempo 全链路;(7) Authz:AuthorizationPolicy 服务级 RBAC。Service Mesh 让 523 服务的网络治理从代码层下沉到平台层,业务代码净化 30%。

十五、Multi-Cluster Active-Active 的工程实现

9 集群 Active-Active 的工程实现 5 要素:(1) 数据层:全球数据库(Spanner / CockroachDB / TiDB)或异步复制 + conflict resolution;(2) 流量层:GeoDNS + Anycast,用户路由到最近 region;(3) 服务层:Istio multi-primary 跨集群服务发现;(4) 事件层:Kafka MirrorMaker 2 跨 region 复制;(5) 故障切换:RTO < 5 分钟,RPO < 1 分钟。实测:任意 region 故障 4 分钟内自动 failover,业务侧无感。

十六、API Gateway vs Service Mesh 的边界

API Gateway(Kong 3.x / APISIX 3.x)vs Service Mesh(Istio Ambient)的边界:(1) Gateway 在 north-south(外部 ↔ 内部):认证 / 限流 / 路由 / 协议转换 / WAF;(2) Mesh 在 east-west(内部 ↔ 内部):mTLS / 重试 / 熔断 / 追踪;(3) 不要混淆:Gateway 不做服务间治理,Mesh 不做外部接入;(4) Gateway 数量少(每 BU 1 个),Mesh 覆盖所有服务。边界清晰后,两者协同工作,运维成本降 40%。

十七、领域服务 vs 应用服务 vs 基础设施服务

DDD 服务分层 3 层:(1) 领域服务(Domain Service):核心业务逻辑,无外部依赖,纯函数;(2) 应用服务(Application Service):编排领域服务 + 仓储 + 事务边界;(3) 基础设施服务(Infrastructure Service):DB / MQ / 第三方 API 适配。清晰分层让单元测试覆盖率从 47% 升到 89%,代码可读性显著提升。

十八、Anti-Corruption Layer(防腐层)的工程价值

ACL 防腐层在 4 个核心 BC 集成第三方系统的工程价值:(1) 隔离第三方变化:第三方接口变,只改 ACL,核心域不动;(2) 统一术语:第三方"customer"→ 我们的"User";(3) 协议转换:SOAP / 老 RPC → REST / gRPC;(4) 容错:第三方挂时 ACL 兜底。对接 60+ 第三方(支付 / 物流 / KYC),核心域代码 0 次因第三方变更而改。

十九、API 版本治理的"5 条铁律"

API 版本治理 5 铁律:(1) URL 版本(/v1/orders)优于 header 版本,客户端简单;(2) 主版本号大于等于 1,且 lifecycle 4 阶段(alpha → beta → stable → deprecated);(3) Deprecation header 提前 6 个月通知;(4) 同时 2 个 major 版本(N + N-1);(5) Backward incompatible 必发新 major。523 服务 800+ API 0 次 breaking change 引起的客户事故。

二十、gRPC vs REST 的取舍

2026 年 gRPC vs REST 取舍:(1) gRPC 优势:protobuf 高效 / streaming / 强类型 / 内部服务首选;(2) REST 优势:HTTP 通用 / 浏览器友好 / 外部 API 首选 / 调试简单;(3) gRPC-web 让浏览器也能 gRPC,但生态弱;(4) GraphQL 在前端聚合场景仍有价值。我们的策略:内部服务全 gRPC(523 服务的 95% RPC),外部 API 全 REST(BFF 层做协议转换)。

二十一、BFF(Backend For Frontend)的工程价值

BFF 在多端(Web / iOS / Android / 小程序 / IoT)的工程价值:(1) 端侧定制:不同端的页面数据聚合需求不同,各自 BFF 不互相打架;(2) 协议转换:对外 REST/GraphQL,对内 gRPC;(3) 端侧逻辑下沉:鉴权 / 灰度 / A/B test 不污染核心域;(4) 性能优化:端侧并行请求合并,降 round-trip。5 端 5 个 BFF 团队,每个 BFF 平均 8-12 工程师,核心域工程师专注业务。

二十二、GraphQL Federation 的"3 个适用场景"

GraphQL Federation(Apollo / Hasura)在我们的 3 个适用场景:(1) 大型管理后台:跨多个 BC 数据聚合,GraphQL 一次查到底;(2) 第三方开放平台:让客户灵活组合查询字段;(3) 移动 App 数据聚合:减少 round-trip。注意:Federation 不要全公司推,只适合上述场景,否则 schema 演进 / 性能调优都是坑。

二十三、领域事件 vs 集成事件

领域事件 vs 集成事件的边界:(1) 领域事件(Domain Event):BC 内部,描述领域变化,通常同步处理;(2) 集成事件(Integration Event):BC 之间,通过 Kafka,异步处理;(3) 领域事件不发到 Kafka,避免泄漏内部细节;(4) 集成事件由 application service 在事务提交后发送。清晰边界让 BC 内部演进自由,BC 间契约稳定。

二十四、Schema-on-write vs Schema-on-read

Schema 治理的 2 派:(1) Schema-on-write(关系库 / Avro):写时验证,数据干净,但灵活性差;(2) Schema-on-read(JSON / Parquet):写时不验证,读时按需 schema,灵活但数据脏。我们的策略:OLTP / 事件流用 schema-on-write(强约束),数据湖 / BI 用 schema-on-read(灵活探索)。

二十五、Idempotency(幂等)的"4 种实现"

幂等 4 种实现:(1) Idempotency-Key header:客户端提供唯一 key,服务端去重;(2) 状态机校验:只允许特定状态 → 状态转换,重复请求被拒;(3) Version 字段:乐观锁,只允许 version=N 时更新;(4) 业务唯一键:订单号 + 用户 + 时间窗口。523 服务的写接口 100% 幂等,过去 12 个月重复请求引起的数据脏 0 次。

二十六、Database per Service 的"5 个红线"

Database per Service 5 个红线:(1) 不允许服务 A 直接连服务 B 的数据库;(2) 跨服务数据通过 API + 事件,不用 view / FK;(3) 共享 DB cluster 但不共享 schema(过渡期可接受);(4) 数据分析走 ETL 到数仓,不实时跨服务查;(5) 数据迁移分阶段:strangler pattern。从 3 共享 DB → database per service 用 14 个月,过去 12 个月数据耦合引起的故障 0 次。

二十七、Strangler Pattern 的"6 步迁移"

Strangler Pattern 的 6 步:(1) 在老系统外建新服务雏形;(2) Gateway / Proxy 把部分流量路由到新;(3) 新老双写过渡期;(4) 数据迁移工具同步老 → 新;(5) 全量切到新;(6) 老服务下线。14 个核心 BC 用 Strangler 重构,0 次大爆炸式停机迁移。

二十八、Anti-pattern:微服务过细

"微服务过细"反模式 5 大代价:(1) 跨服务调用激增,延迟堆积;(2) 部署 / 监控 / 文档成本 N 倍;(3) 分布式事务复杂度 N 倍;(4) 团队认知负担超线性增长;(5) 服务网格 / API gateway 资源消耗大。我们从 800 服务砍到 523,核心是合并"过度拆分"的 CRUD 服务,绩效:延迟 -25%,部署成本 -40%,工程师认知 +60%。

二十九、模块化单体(Modular Monolith)的工程价值

Modular Monolith 在 2026 年的重要性:(1) 不是所有公司都需要微服务,< 50 工程师建议单体;(2) 模块化单体:1 个进程,内部清晰 BC,跨 BC 通过应用服务调用;(3) 部署简单,事务简单,延迟低;(4) 必要时局部拆为微服务(strangler)。对中小公司:从单体起步,有规模需求再演进,远好于一开始就 50 个微服务。

三十、技术债的"4 种类型"

Technical Debt 4 类:(1) Deliberate(主动):为快速上线接受的临时方案,有 due date 偿还;(2) Inadvertent(无意):团队当时认知不足,事后才知;(3) Reckless(鲁莽):明知但不偿还,长期累积成灾;(4) Bit rot(腐烂):代码 / 库不更新,慢慢失效。我们的策略:每季度 20% sprint capacity 还债,主动债务在 next sprint 还,鲁莽债务列入 OKR。

三十一、监控架构的"4 个层次"

分布式系统监控 4 层:(1) Infrastructure:节点 / Pod / 网络 / 磁盘,Prometheus + node_exporter;(2) Platform:K8s / Mesh / DB / MQ,Mimir / VictoriaMetrics 长期存储;(3) Application:RED metrics + 业务自定义 metrics,OpenTelemetry;(4) Business:GMV / 订单 / 用户活跃,业务 dashboard。4 层独立但联动,5 分钟内可从业务异常下钻到底层根因。

三十二、可观测性 3 件套 + 1

2026 年可观测性 3+1:(1) Metrics:Prometheus / Mimir / VictoriaMetrics;(2) Logs:Loki / Elastic / OpenObserve;(3) Traces:Tempo / Jaeger;(4) Profiles(新增):Pyroscope / Parca,CPU / heap 持续剖析。4 件套通过 OpenTelemetry 统一采集,trace id 串联,排查从"分钟级"提速到"秒级"。

三十三、零信任(Zero Trust)的"5 大原则"

零信任安全 5 原则:(1) Never trust, always verify:不分内外网,所有请求验证;(2) Least privilege:最小权限;(3) Assume breach:假设已被攻破,限制爆炸半径;(4) Verify explicitly:身份 / 设备 / context;(5) Continuous monitoring。523 服务全部 mTLS + JWT + RBAC + audit log,内网横向移动 0 次。

三十四、Identity Federation 的"3 层架构"

Identity Federation 3 层:(1) 用户身份:Keycloak / Auth0,OIDC + MFA;(2) 服务身份:SPIFFE/SPIRE,SVID 证书;(3) Workload identity:K8s SA → IAM Role / Vault。统一 Identity Federation 让 73 工程师的 access 管理从"散落 30+ 系统"变"1 个 portal"。

三十五、Multi-tenant 的"4 个隔离层次"

Multi-tenant SaaS 的 4 个隔离层次:(1) Database:shared schema / schema per tenant / DB per tenant 3 级;(2) Compute:shared / namespace / dedicated cluster 3 级;(3) Network:VPC peering / private link / 独立 region;(4) Identity:tenant scoped JWT + RLS。我们 380 企业租户:90% shared(SMB),9% dedicated namespace(中型),1% dedicated cluster + region(超大客户)。

三十六、Cell-based 的"6 个工程细节"

Cell-based 工程细节 6 点:(1) 每 cell 独立 K8s namespace + 独立 DB + 独立 Kafka topic 前缀;(2) Cell ID 在 user / request 全链路传递;(3) Cell routing:Envoy 按 user hash 路由;(4) Cell failover:cell 故障时流量切到 backup cell(预先配置);(5) Cross-cell:严格禁止,需要时走 BC API;(6) Cell capacity:每 cell 设容量上限,超出新建 cell。14 个 cell 让架构具备线性扩展能力。

三十七、Conway's Law 的工程运用

Conway's Law(系统结构反映团队结构)在我们 73 工程师的工程运用:(1) 团队组织决定架构边界;(2) 想拆 BC 先拆团队;(3) Inverse Conway Maneuver:先设计目标架构 → 反推团队结构;(4) Two pizza team:6-8 人 per BC team,负责完整生命周期。14 个 BU 73 工程师匹配 47 个 BC,team-BC 对应率 91%。

三十八、Team Topologies 的"4 种团队"

Team Topologies 4 种团队:(1) Stream-aligned team:对齐业务流,核心团队,占 80%;(2) Platform team:做内部 IDP / 平台,占 10%;(3) Enabling team:专家咨询(性能 / 安全 / DDD),占 5%;(4) Complicated subsystem team:支付 / 风控等复杂子系统,占 5%。这 4 种模式让 73 人协同有序,认知负担显著降低。

三十九、平台工程的"6 大产品"

Platform 团队 6 大内部产品:(1) IDP(Backstage / Port):服务目录 + 自助;(2) GitOps(ArgoCD):部署自动化;(3) 监控平台(Grafana stack);(4) Service mesh(Istio + 自动注入);(5) DataPlatform(Kafka / Flink / 数据湖);(6) AI Platform(vLLM / Ray)。Platform 团队 8 人服务 65 名产品工程师,人均 platform / product = 1:8,符合行业最佳比。

四十、容量规划的"4 个维度"

容量规划 4 维:(1) Throughput:QPS / RPS / TPS;(2) Latency:p50 / p95 / p99 / p99.9;(3) Saturation:CPU / Memory / Disk / Network 使用率;(4) Error budget:SLO 剩余。4 维联动看容量,单一指标永远误导。每季度容量回顾 + 1 年 forecast,资源预订提前 6 个月。

四十一、灰度发布的"4 种策略"

灰度发布 4 策略:(1) 流量百分比:1% → 5% → 25% → 100%;(2) 用户白名单:内部员工 → 早鸟用户 → 全量;(3) 地域:小 region → 大 region;(4) Header / Cookie:特定 header 进灰度。4 策略组合使用,Argo Rollouts AnalysisTemplate 自动验证,过去 12 个月灰度过程拦截潜在故障 87 次。

四十二、Chaos Engineering 的"6 个层次"

Chaos Engineering 6 层:(1) Process:杀进程;(2) Network:延迟 / 丢包 / 断网;(3) Resource:CPU 满 / 内存满;(4) Time:时钟漂移;(5) Application:5xx 注入;(6) Dependency:第三方 API 慢 / 失败。每月 1 次 GameDay,过去 12 个月发现 24 个潜在故障,9 个达 P0 / P1 级,及时修复避免生产事故。

四十三、性能优化的"5 步走"

性能优化 5 步:(1) Profile(找瓶颈,Pyroscope / pprof);(2) Cache(读多场景 cache 优先);(3) Async(非关键路径异步化);(4) Parallel(独立任务并发);(5) Algorithm(算法 / 数据结构优化)。523 服务过去 12 个月 p99 延迟整体降 47%,5 步走是核心方法论。

四十四、Architecture Decision Record(ADR)的"6 个字段"

ADR 6 字段:(1) Title:简短描述;(2) Context:为什么需要决策;(3) Decision:决策是什么;(4) Consequences:好处 + 代价;(5) Alternatives:考虑过的方案;(6) Status:proposed / accepted / superseded。过去 3 年累积 387 个 ADR,在 Backstage TechDocs 中浏览,新人 onboard 必读。

四十五、架构图的"C4 模型"

C4 模型 4 层:(1) Context:系统在生态中的位置;(2) Container:大模块 / 服务 / DB;(3) Component:组件级关系;(4) Code:类图(很少画)。我们用 Structurizr DSL 写 C4,生成 SVG 嵌入 Backstage,文档与代码同步,过时率 < 5%。

四十六、Architecture Review 的"6 步流程"

Architecture Review 6 步:(1) 提案者写 ADR 草稿;(2) 邮件群发,72 小时 async review;(3) Review 会议(1 小时,只讨论争议);(4) 修订 ADR;(5) Architecture Council 投票;(6) Accept / reject / 继续讨论。过去 12 个月 ADR 89 个,通过 76 个,拒绝 13 个,review 时长平均 9 天。

四十七、Fitness Function 的"5 类"

Evolutionary Architecture 的 Fitness Function 5 类:(1) 性能:p99 延迟、QPS;(2) 可用性:SLO 达成率;(3) 安全:漏洞密度、合规通过率;(4) 可维护性:代码圈复杂度、技术债指数;(5) 业务:转化率、留存。5 类 fitness function 在 CI 自动测,违反阻断部署,过去 12 个月 fitness violation 47 次都在 PR 阶段拦截。

四十八、SOA → 微服务 → Serverless 的演进路径

2026 年 3 代演进观察:(1) SOA(2005-2012):重 ESB / SOAP,失败教训:ESB 单点;(2) 微服务(2014-2020):轻 ESB,API 通信,问题:分布式复杂度;(3) Serverless(2020-2026):函数化 + 事件驱动,问题:cold start / vendor lock-in。未来:Serverless 在边缘 / 突发场景,微服务在主流,模块化单体在中小公司。

四十九、Serverless 的"5 个真实场景"

Serverless 在我们生产的 5 个真实场景:(1) 图片处理(用户上传 → resize → CDN);(2) 数据 ETL(Kafka → Lambda → S3);(3) Cron 任务(每日报表);(4) Webhook(第三方回调);(5) AI inference(轻量模型)。523 服务中 47 个是 Serverless 函数,占 9%,适合突发 / 间歇场景,关键路径仍是常驻服务。

五十、Edge Computing 的"4 个应用"

Edge Computing 4 个应用:(1) CDN:静态资源 + 动态加速;(2) Edge function(Cloudflare Workers / Fastly Compute);(3) IoT 网关:本地处理 + 上行汇总;(4) Edge AI:模型部署到边缘节点。我们的 380 企业租户跨 9 region,Edge 让首字节延迟从 280ms 降到 47ms。

五十一、Data Mesh 的"4 个原则"

Data Mesh(Zhamak Dehghani 提出)4 原则:(1) Domain ownership:每个 BC 拥有自己的数据产品;(2) Data as a product:数据像 API 一样有契约 / 文档 / SLA;(3) Self-serve data platform:平台让 BC 自助;(4) Federated computational governance。我们 8.7 PB 数据按 14 个 BU + 47 个 BC 切分为 230 个 data product,数据消费者自助率 87%。

五十二、Data Contract 的工程价值

Data Contract(数据契约)在 Data Mesh 中的工程价值:(1) Schema + SLO + Ownership 三件套;(2) CI 验证 schema 不破坏;(3) 数据消费者按 contract 订阅;(4) Producer 修改 contract 走变更流程。过去 12 个月 data contract violation 0 次,数据消费方故障率降 92%。

五十三、技术选型的"5 维评估"

技术选型 5 维:(1) Fit:解决什么问题,符合需求否;(2) Cost:学习曲线 + 运维成本 + 许可;(3) Risk:vendor lock-in / 社区活跃度;(4) Skill:团队是否擅长;(5) Ecosystem:周边工具 / 集成 / 文档。每次选型 ADR 必走 5 维,过去 12 个月技术选型回滚 2 次(< 5%),远低于行业平均 25%。

五十四、避免 Vendor Lock-in 的"5 个策略"

避免 vendor lock-in 5 策略:(1) 用开源协议(K8s / Kafka / Postgres)而非云厂商专属服务;(2) 数据可移植性:用通用格式(Parquet / Avro);(3) 多云抽象层(Crossplane / Pulumi);(4) Backup 到多个 region / 云;(5) 关键人员认知储备多云能力。我们 4 朵云(AWS / Azure / GCP / Aliyun)+ K8s 全栈,vendor 切换实际操作过 2 次,业务无感。

五十五、合规架构的"6 个维度"

合规架构 6 维:(1) GDPR / 个保法:PII 脱敏 + 数据出境;(2) SOC 2:审计 log + access control;(3) PCI-DSS:支付域隔离;(4) HIPAA:医疗数据加密;(5) EU AI Act:AI 应用高风险评估;(6) 数据本地化:中国 / 欧盟 / 美国数据不出境。合规要求随业务全球化激增,架构必须 day 1 就考虑。

五十六、架构演进的"4 个驱动力"

架构演进 4 驱动:(1) 业务规模(用户数 / QPS / 数据量);(2) 团队规模(工程师数 / BU 数);(3) 技术演进(新框架 / 新硬件);(4) 合规 / 安全要求。不要因为"觉得应该"演进,而要因为某个驱动力达阈值。无驱动的演进是 over-engineering。

五十七、架构师的"7 个核心能力"

架构师 7 能力:(1) 业务理解:能用业务语言讲架构;(2) 技术深度:至少 2 个领域精通;(3) 系统思维:看整体而非局部;(4) 沟通协作:跨团队对齐;(5) 决策与权衡:trade-off 量化;(6) 文档表达:ADR / C4 / 演讲;(7) 持续学习。架构师不是"画 PPT 不写代码",而是"写最少代码做最大影响"。

五十八、架构师的"5 个反模式"

架构师 5 反模式:(1) Ivory tower(象牙塔):脱离一线,设计纸上谈兵;(2) Cargo cult(模仿崇拜):Netflix 怎么做我们就怎么做,不考虑规模;(3) Resume-driven:学新技术做项目,不顾业务;(4) Hammer syndrome:手里只有一把锤子,什么都看成钉子;(5) Big bang design:一次设计完美,不愿迭代。5 反模式自我警示,过去 12 个月避免 11 次架构灾难。

五十九、技术雷达(Tech Radar)的工程价值

Tech Radar(ThoughtWorks 推广)在我们的工程价值:(1) 4 圈:Adopt / Trial / Assess / Hold;(2) 4 区:Languages / Tools / Platforms / Techniques;(3) 半年更新一次,全公司共识;(4) 新技术先 Assess,POC 后进 Trial,生产验证后 Adopt。过去 3 年 Tech Radar 引导 47 项技术进生产,9 项 Hold 避免踩坑。

六十、未来 3 年架构的"7 个趋势"

2026-2029 架构 7 趋势:(1) AI 原生架构:每个核心服务嵌入 LLM;(2) Edge + Cloud 混合普及;(3) WebAssembly 服务端化(WASI);(4) eBPF 替代部分 sidecar;(5) Quantum-resistant 加密;(6) Sustainable architecture(碳排放成 KPI);(7) Multi-cloud 抽象成熟(Crossplane / Pulumi)。趋势是确定的,提早布局者赢。

六十一、从 42 天得到的"8 个工程教训"

42 天架构现代化的 8 个最深刻教训:(1) 团队结构决定架构,改架构先改团队;(2) 微服务不是越多越好,有边界更重要;(3) 事件驱动是最强解耦,但需 schema 治理;(4) Cell-based 是大规模线性扩展的银弹;(5) 零信任不是选项是必需;(6) 灰度发布 / chaos engineering 是稳定性命门;(7) 文档(ADR / C4)是架构的脊柱;(8) 没有完美架构,只有合适的架构。这 8 教训值 42 天 73 工程师。

六十二、给 30-100 人公司的"7 条架构建议"

30-100 人公司架构 7 建议:(1) 不要急着拆微服务,模块化单体先做透;(2) K8s 收益要看团队 ops 能力,< 30 工程师慎用;(3) Service Mesh 仅大规模需要,< 50 服务用 SDK 治理;(4) Event-driven 选 RabbitMQ / Pulsar 而非 Kafka(复杂度低);(5) 监控用 SaaS(Datadog / Grafana Cloud);(6) ADR 文化从 day 1 建立;(7) 雇 1 个有经验架构师 > 雇 3 个普通工程师。架构与团队规模必须匹配,过早现代化 = 慢性自杀。

六十三、最后一句话

42 天 DDD + CQRS + Event Sourcing + Saga + Service Mesh + Multi-Cluster + Cell-based + 0 信任全栈架构现代化,如果只让我说最后一句话:"架构在 2026 年已不是'画几张框图'的纸面工作,而是一门关于业务理解 / 技术深度 / 团队组织 / 演进节奏 / 持续验证 / 文档治理 / 安全合规的综合工程学,73 工程师 42 天 / 523 服务 / 47 万 QPS / 8.7 PB 数据的真实工程实践告诉我们:DDD 是软件架构的灵魂,事件驱动是分布式系统的脊柱,Cell-based 是大规模容灾的骨架,Team Topologies 是架构落地的血肉,零信任是合规时代的命门,平台工程是开发体验的最终答案。架构不是终极目标,演进才是。" 这是我作为 chief architect 带 73 工程师 42 天的最终结论,献给每一位还在和 distributed monolith 搏斗的架构师同行。继续提交 commit,继续 ship,继续 evolve,下篇文章见。

六十四、补遗一:Outbox Pattern 落地代码

Outbox Pattern 在 PostgreSQL + Debezium 上的工程落地:

CREATE TABLE outbox (
    id            BIGSERIAL PRIMARY KEY,
    aggregate_id  VARCHAR(64) NOT NULL,
    event_type    VARCHAR(128) NOT NULL,
    payload       JSONB NOT NULL,
    headers       JSONB,
    created_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
    published_at  TIMESTAMPTZ
);
CREATE INDEX idx_outbox_unpublished ON outbox (created_at) WHERE published_at IS NULL;

BEGIN;
UPDATE orders SET status = 'PAID', updated_at = now() WHERE id = $1;
INSERT INTO outbox (aggregate_id, event_type, payload, headers)
VALUES ($1, 'OrderPaid', $2::jsonb, $3::jsonb);
COMMIT;

六十五、补遗二:Aggregate Repository 接口

领域驱动设计 Aggregate Repository 在 Java + Spring Data 的落地:

public interface OrderRepository {
    Optional<OrderAggregate> findById(OrderId id);
    void save(OrderAggregate order);
    List<OrderId> findIdsByUserAndStatus(UserId userId, OrderStatus status);
}

@Repository
public class JpaOrderRepository implements OrderRepository {
    private final OrderJpaRepository jpaRepo;
    private final DomainEventPublisher publisher;

    @Override
    @Transactional
    public void save(OrderAggregate order) {
        OrderEntity entity = OrderMapper.toEntity(order);
        jpaRepo.save(entity);
        order.popEvents().forEach(publisher::publish);
    }

    @Override
    public Optional<OrderAggregate> findById(OrderId id) {
        return jpaRepo.findById(id.value())
            .map(OrderMapper::toAggregate);
    }
}

六十六、补遗三:Service Mesh 流量切分 yaml

Istio HTTPRoute 流量按 header + weight 切分,生产可复制:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: order-svc
  namespace: prod-order
spec:
  parentRefs:
    - name: prod-gateway
      namespace: gateway-system
  hostnames:
    - api.example.com
  rules:
    - matches:
        - headers:
            - name: X-Beta-User
              value: "true"
      backendRefs:
        - name: order-svc-v2
          port: 8080
          weight: 100
    - matches:
        - path:
            type: PathPrefix
            value: /v1/orders
      backendRefs:
        - name: order-svc-v1
          port: 8080
          weight: 95
        - name: order-svc-v2
          port: 8080
          weight: 5
      timeouts:
        request: 5s
        backendRequest: 4s
      retry:
        codes: [502, 503, 504]
        attempts: 3
        backoff: 200ms

—— 别看了 · 2026