分布式系统设计流程与实战推演

概述

系列定位 ：本文是"分布式系统架构认知与设计"系列的第 5 篇。在前 4 篇构建了认知框架、设计原则、架构模式和时间维度之后，本文将首次把这些知识整合为一个可操作的设计流程，并以一个完整的电商订单系统案例贯穿始终。目标是从"学知识"到"用知识"的关键转折。

总结性引言：如果你已经理解了分布式系统由通信、协作、存储、治理四大能力域组成（第 1 篇），掌握了故障是常态、无状态优先、异步解耦等设计原则和五大权衡框架（第 2 篇），熟悉了微服务、事件驱动、数据密集型和云原生四种架构模式（第 3 篇），也知道了时间参数如何从 Raft 传递到 K8s 探针（第 4 篇）------但当你真正面对一个业务需求时，你可能仍然不知道"第一步该做什么"。本文正是为了解决这个问题。我将以一个电商订单系统（QPS 10000、延迟 <100ms、月数据量 1TB、订单强一致+库存最终一致+通知异步）为贯穿案例，展示从需求分析到系统设计的完整六步流程。每一步都会给出决策理由、量化计算和完整的架构图与时序图。在面试高频专题部分，还会通过一个社交 Feed 系统设计题完整演示六步法的实战应用。

---

文章组织架构

flowchart TD A["1. 设计流程六步法总览"] --> B["2. Step1-2 需求分析与能力域拆解"] B --> C["3. Step3 架构模式选型与组合推演"] C --> D["4. Step4 关键技术选型------填充能力域×分层矩阵"] D --> E["5. Step5 时间参数设计------超时/重试/TTL/探针计算"] E --> F["6. Step6 容量规划与部署方案"] F --> G["7. 全架构图与时序图 完整呈现"] G --> H["8. 与前后系列的衔接"] H --> I["9. 面试高频专题"] I --> J["9.8 系统设计题：社交Feed系统完整推演"] classDef default fill:#f1f5f9,stroke:#334155,stroke-width:2px,color:#0f172a

图表主旨概括 ：该图展示了全文的 10 个核心模块，以六步法为主线，从需求逐步推演到部署，最后以衔接和深度面试题收尾，系统设计题独立成章。
逐元素分解 ：模块 1 建立全局认知；模块 2-6 是设计流程的详细推演；模块 7 将设计成果可视化；模块 8 说明知识关联；模块 9 和 9.8 提供面试巩固及完整系统设计演练。
设计原理映射 ：遵循"需求→能力→模式→组件→参数→容量"的自顶向下分解逻辑，并与前文知识紧密关联。
工程联系与关键结论 ：分布式系统设计是可以方法论化的六步流程，本文每一步都有明确的输入、输出和决策理由，并通过两个完整案例帮助工程师建立可复用的系统设计能力。

---

1. 设计流程六步法总览

设计流程六步法源自将前 4 篇的抽象知识转化为可执行步骤的需求。其哲学是：从业务需求出发，逐层分解到技术组件，再量化配置参数，每一步都产出结构化文档，确保设计可追溯、可评审、可演进。

设计流程六步法总览图

flowchart TB A[Step1 需求分析] --> B[Step2 能力域拆解] B --> C[Step3 架构模式选型] C --> D[Step4 关键技术选型] D --> E[Step5 时间参数设计] E --> F[Step6 容量规划与部署] A1[输入: 业务文档/PRD] --> A A2[输出: 需求规格单 量化指标+优先级] --> A B1[输入: Step1产出] --> B B2[输出: 能力域映射表 技术挑战与策略] --> B C1[输入: Step2能力域挑战] --> C C2[输出: 模式组合方案与理由] --> C D1[输入: 模式组合+能力域矩阵] --> D D2[输出: 技术选型矩阵 每格有组件+理由] --> D E1[输入: 选型矩阵+第4篇方法论] --> E E2[输出: 时间参数配置表 数值+计算依据] --> E F1[输入: 选型+时间参数] --> F F2[输出: 部署拓扑+资源清单 容量预估] --> F

图表主旨概括 ：展示了六步流程的递进关系，每一步都标注了输入来源和产出物，体现设计的逻辑链条。
逐元素分解 ：从 Step1 的业务需求开始，经过能力映射、模式选择、组件填充、参数计算，最终到容量和部署，形成闭环。
设计原理映射 ：符合"问题域→解决方案域→实现域"的经典架构设计方法，每步的解耦保证了设计灵活性。
工程联系与关键结论 ：这六步形成一个可复用的模板，任何分布式系统设计都可以直接套用，产出物构成了完整的架构设计文档。后续面试题将反复使用该模板。

---

2. Step1-2：需求分析与能力域拆解

Step1 需求分析

需求分析的目标是将模糊的业务期望转化为可度量、可验证、有优先级的技术指标。通常包括业务功能提取和服务质量（QoS）量化。

业务功能需求（电商订单系统核心流程）：

• 创建订单：用户下单，锁定优惠，生成订单。
• 支付回调：第三方支付成功通知，修改订单状态。
• 库存扣减：支付成功后同步扣减真实库存。
• 通知发送：订单状态变更异步推送消息（短信/推送）。

服务质量需求量化：

指标项	目标值	说明
日常 QPS	10000	订单创建接口
峰值 QPS	50000	大促秒杀场景，需弹性扩容
延迟 P99	<100ms	核心链路（下单到返回成功）
可用性	99.99%	全年宕机时间 <53分钟
月数据增量	1TB	订单表为主，年增长约3倍
一致性要求	订单与库存强一致（AT），库存缓存最终一致（<1s），通知异步（<5s）	分级一致性

需求优先级排序（MoSCoW 原则）：

• P0 核心链路：下单扣库存（强一致 + 低延迟 + 高可用），任何降级都不能影响。
• P1 重要链路：订单查询、库存查询（最终一致，低延迟）。
• P2 一般链路：历史订单导出、用户行为分析（离线，允许分钟级延迟）。

Step2 能力域拆解

将 Step1 的每条量化需求映射到四大能力域，识别技术挑战。第1篇已详细介绍了四大能力域，此处直接应用。

需求分析到能力域映射图

flowchart LR subgraph 业务需求 R1[QPS 10000/延迟<100ms] R2[订单强一致/库存最终一致] R3[月数据1TB 年增长3倍] R4[峰值5万 弹性伸缩] end subgraph 通信域 C1[同步RPC低延迟 <10ms网络开销] C2[异步解耦 削峰填谷 消息堆积] C3[统一入口 鉴权 限流] end subgraph 协作域 D1[跨DB强一致事务 AT/TCC] D2[缓存最终一致 延迟<1s] D3[秒杀分布式锁防超卖] end subgraph 存储域 S1[水平分库分表 单分片<500GB] S2[全文检索商品] S3[海量历史订单低成本冷存储] S4[实时OLAP聚合统计] end subgraph 治理域 G1[服务发现与动态扩缩] G2[流量洪峰限流保护] G3[事务失败监控与手动恢复] G4[全链路可观测 TraceId] end R1 --> C1 R1 --> C3 R1 --> D1 R2 --> D1 R2 --> D2 R2 --> D3 R3 --> S1 R3 --> S2 R3 --> S3 R3 --> S4 R4 --> C2 R4 --> G1 R4 --> G2 R1 --> G3 R4 --> G4

图表主旨概括 ：展示了从业务需求到四大能力域技术挑战的映射关系，每个需求都对应具体的域内挑战。
逐元素分解 ：左侧是量化的业务目标，右侧四个子图分别代表通信、协作、存储、治理域需解决的问题，箭头表示对应关系。
设计原理映射 ：体现了"关注点分离"原则，将复杂系统分解到独立的能力维度，降低设计复杂度，便于独立选型和优化。
工程联系与关键结论 ：能力域拆解是架构设计的核心步骤，它把业务需求转化为明确的技术攻关方向。该电商系统将在通信域采用同步 RPC+异步 MQ，协作域使用 AT 事务+分布式锁，存储域使用分库分表+多引擎，治理域依赖 K8s+Istio。

能力域映射表（产出物）：

能力域	技术挑战	初步策略
通信	核心链路同步低延迟 RPC	Dubbo 同步调用，超时严格控制
通信	非核心链路异步解耦	RocketMQ 事务消息，削峰填谷
协作	订单/库存强一致分布式事务	Seata AT 模式，TC 集群高可用
协作	秒杀防超卖	Redis 分布式锁 (Redisson)
存储	订单表水平分库分表	ShardingSphere-JDBC，user_id 分片
存储	商品搜索、实时分析、冷数据	ES、ClickHouse、MinIO (S3) 多引擎
治理	弹性伸缩、流量防护	K8s HPA + Sentinel + Istio
治理	全链路追踪	SkyWalking + Prometheus + Loki

---

3. Step3：架构模式选型与组合推演

根据第3篇四种架构模式（微服务、事件驱动、数据密集型、云原生）的特点，结合需求特征进行决策。

架构模式选型决策树

flowchart TD Start[需求特征分析] --> Q1{核心链路延迟要求?} Q1 -->|<100ms 同步低延迟| Micro[微服务模式] Q1 -->|允许异步/最终一致| Event[事件驱动模式] Micro --> Q2{数据量级与查询复杂度?} Q2 -->|海量数据 多维查询| Data[数据密集型模式] Q2 -->|简单CRUD| Simple[普通单体/简单微服务] Data --> Q3{弹性与基础设施要求?} Q3 -->|需要自动扩缩 灰度发布| CloudNative[云原生模式] Q3 -->|静态部署| Traditional[传统运维] Event --> Q2 CloudNative --> Final[全模式组合: 微服务+事件驱动+数据密集型+云原生]

图表主旨概括 ：以决策树形式展示了根据核心延迟、数据复杂度和弹性需求逐步选择架构模式的过程。
逐元素分解 ：从核心延迟要求开始分支，同步低延迟选微服务；接着判断数据量级，海量数据选数据密集型；最后看基础设施需求，弹性伸缩选云原生。
设计原理映射 ：体现了"康威定律"和"演化式架构"思想，根据非功能需求确定架构风格，每种模式解决特定痛点。
工程联系与关键结论 ：电商订单系统同时满足所有条件，因此最终采用四种模式的组合，各司其职。选型过程通过量化的延迟和数据指标驱动，避免主观臆断。

电商订单系统模式组合推演与理由

• 微服务模式 ：按业务边界拆分为订单、库存、支付、通知四个独立服务。每个服务独立数据库（分片）、独立部署、独立扩缩。理由：核心链路（下单）需要强一致且低延迟，同步 RPC 最合适，微服务边界清晰，团队可并行开发。
• 事件驱动模式 ：订单状态变更后通过 RocketMQ 发布事件，通知服务异步消费；数据库变更通过 Debezium CDC 发往 Kafka，再由消费者写入 ES 和 ClickHouse。理由：通知、搜索、分析等非核心链路允许异步，利用事件驱动解耦并削峰填谷，避免拖慢主流程。
• 数据密集型模式 ：针对订单表的月增 1TB，采用 ShardingSphere 分库分表；针对搜索需求引入 ES；实时分析引入 ClickHouse；历史数据归档至 MinIO (S3 兼容) 实现冷热分离。理由：单一数据库无法承载容量和查询压力，需要多组件数据架构。
• 云原生模式 ：所有服务运行在 K8s 上，通过 HPA 根据 CPU/Memory 或自定义指标（如 QPS）弹性伸缩；使用 Istio 实现流量管理（金丝雀发布、负载均衡、mTLS）。理由：应对促销峰值 5 万 QPS，自动化运维、灰度发布和故障自愈是刚需。

为什么不选其他模式？

• 不选单体：无法水平扩展，单库连接数、存储容量都会成为瓶颈，且耦合度高不利于多团队协作。
• 不选纯事件驱动：核心下单同步返回需要阻塞等待库存扣减结果，若全部异步则无法在 100ms 内给予用户明确响应（需要异步回调或轮询，体验差）。
• 暂不选 TCC：订单场景 SQL 操作简单（insert order, update inventory），Seata AT 零侵入，开发效率高。当前 TPS 10000 通过 4 分片 + AT 完全可以支撑，不必过早优化引入 TCC 的高侵入性（详见第2篇权衡框架：实用性优先）。

---

4. Step4：关键技术选型------填充能力域×分层矩阵

根据第1篇的"能力域×分层"矩阵（接入层、服务层、数据层、基础设施层）进行选型填充。每个格子需要明确组件、版本和选型理由。

关键技术选型矩阵图（能力域×分层）

flowchart LR subgraph 分层 L1[接入层] L2[服务层] L3[数据层] L4[基础设施层] end subgraph 通信域 A1[Spring Cloud Gateway + Nginx] A2[Dubbo 3.x + RocketMQ 5.x] A3[RocketMQ CommitLog] A4[-] end subgraph 协作域 B1[-] B2[Seata 1.6.x AT + Redisson 3.23.x] B3[Seata undo_log + 本地消息表] B4[-] end subgraph 存储域 C1[-] C2[-] C3[ShardingSphere-JDBC 5.4.x + MySQL 8.0 + Redis 7.x Cluster + ES 8.x + ClickHouse 24.x + MinIO] C4[-] end subgraph 治理域 D1[Sentinel 1.8.x Gateway整合] D2[Nacos 2.x + Resilience4j 2.x] D3[-] D4[Kubernetes 1.28.x + Istio 1.20.x + Prometheus + SkyWalking + Loki] end A1 --- L1 A2 --- L2 A3 --- L3 D1 --- L1 B2 --- L2 D2 --- L2 B3 --- L3 C3 --- L3 D4 --- L4

图表主旨概括 ：在经典的4行（分层）×4列（能力域）矩阵中填充了具体的组件名称和版本，直观展示整体技术栈。
逐元素分解 ：横向为通信、协作、存储、治理四大域，纵向为接入、服务、数据、基础设施四层，交叉点放置主要组件，空白处表示该域在该层无核心组件。
设计原理映射 ：体现了"正交分解"的系统设计思想，确保每个关注点都有对应组件覆盖，且组件在合适的分层。
工程联系与关键结论 ：该矩阵是后续部署和运维的基础，选型时重点关注团队技术栈、生态兼容性和性能指标。所有选型都有明确的对比依据。

下面详细说明关键选型的理由和备选对比，并提供核心配置片段。

通信域

• 接入层 × 通信：Spring Cloud Gateway

  路由、鉴权、协议转换。与 Nacos 整合动态路由。
  核心配置：

  spring:
    cloud:
      gateway:
        routes:
          - id: order-service
            uri: lb://order-service
            predicates:
              - Path=/api/order/**
            filters:
              - StripPrefix=1

  解读 ：lb://order-service 实现负载均衡，StripPrefix 去除前缀转发给后端。

• 服务层 × 通信：Dubbo 3.x (同步RPC) + RocketMQ 5.x (异步消息)
  为什么 Dubbo 而非 gRPC？ 团队 Java 技术栈成熟，Dubbo 对 Spring Boot 整合更完善，服务治理（多协议、多注册中心）功能更丰富，且国内社区活跃。gRPC 在多语言场景更优，但本系统纯 Java。
  为什么 RocketMQ 而非 Kafka？ 核心需求是事务消息（支付回调 → 确保通知可靠投递）。RocketMQ 原生支持事务消息且延迟低（ms 级），Kafka 虽吞吐更高但事务消息需额外协调。
  配置示例：

  @DubboReference(version = "1.0.0", timeout = 3000)
  private InventoryService inventoryService;

  RocketMQ 生产者：

  rocketMQTemplate.sendMessageInTransaction("order-event", 
      MessageBuilder.withPayload(orderEvent).build(), null);

协作域

• 服务层 × 协作：Seata 1.6.x AT 模式 + Redisson 3.23.x
  为什么 Seata AT 而非 XA/TCC？ XA 锁持有过长，性能差 3-5 倍（见第2篇）。TCC 侵入性高，需要实现 try/confirm/cancel 接口。订单场景 SQL 简单，AT 基于 undo_log 自动回滚，零侵入，开发效率优先。
  配置 ：

  seata:
    tx-service-group: order_tx_group
    service:
      vgroup-mapping:
        order_tx_group: default

  @GlobalTransactional(timeoutMills = 30000)
  public void createOrder(OrderDTO dto) { ... }

  Redisson 分布式锁 （秒杀）：

  RLock lock = redissonClient.getLock("sku:" + skuId);
  lock.lock(10, TimeUnit.SECONDS); // 看门狗自动续期

存储域

• 数据层 × 存储：ShardingSphere-JDBC 5.4.x（分片） + MySQL 8.0 + Redis 7.x Cluster + ES 8.x + ClickHouse 24.x + MinIO
  为什么 ShardingSphere-JDBC 而非 Mycat？ 客户端代理，零网络额外开销，性能更高，且与 Spring Boot 集成简便，Java 团队可控性强。Mycat 需独立部署维护。
  分片配置（YAML）：

  rules:
    - !SHARDING
      tables:
        t_order:
          actualDataNodes: ds_${0..3}.t_order_${0..3}
          databaseStrategy:
            standard:
              shardingColumn: user_id
              shardingAlgorithmName: order_db_inline
          tableStrategy:
            standard:
              shardingColumn: order_id
              shardingAlgorithmName: order_table_inline
      shardingAlgorithms:
        order_db_inline:
          type: INLINE
          props:
            algorithm-expression: ds_${user_id % 4}
        order_table_inline:
          type: INLINE
          props:
            algorithm-expression: t_order_${order_id % 4}

  解读 ：user_id % 4 分库，order_id % 4 分表，保证同一用户的订单落在同一分片。初期 4 分片足够。

• Redis 缓存 TTL 随机化：

  int ttl = 300 + ThreadLocalRandom.current().nextInt(300);
  redisTemplate.opsForValue().set(key, value, ttl, TimeUnit.SECONDS);

治理域

• 服务层 × 治理：Nacos 2.x (CP) + Resilience4j 2.x

  Nacos 作为注册中心和配置中心，CP 模式保证一致性。Resilience4j 提供轻量级熔断降级。
  熔断配置：

  CircuitBreakerConfig config = CircuitBreakerConfig.custom()
      .failureRateThreshold(50)
      .waitDurationInOpenState(Duration.ofMillis(5000))
      .slidingWindowSize(10)
      .build();

• 基础设施层 × 治理：Kubernetes 1.28.x + Istio 1.20.x + Prometheus + SkyWalking + Loki

  K8s 负责编排，HPA 弹性伸缩，Istio 提供流量管理、mTLS、可观测性增强。
  Istio VirtualService 金丝雀发布：

  apiVersion: networking.istio.io/v1beta1
  kind: VirtualService
  spec:
    hosts:
    - order-service
    http:
    - match:
      - headers:
          version:
            exact: v2
      route:
      - destination:
          host: order-service
          subset: v2
        weight: 10
    - route:
      - destination:
          host: order-service
          subset: v1
        weight: 90

完整的矩阵选型对比表（节选）：

决策点	方案 A	方案 B	选择	理由
RPC 框架	Dubbo	gRPC	Dubbo	Spring 生态集成、服务治理成熟度
消息队列	RocketMQ	Kafka	RocketMQ	事务消息原生支持、延迟低
分布式事务	Seata AT	TCC	AT	低侵入、开发效率、满足性能
数据分片	ShardingSphere-JDBC	Mycat	ShardingSphere	客户端代理性能高、Java 可控
注册中心	Nacos (CP)	Eureka (AP)	Nacos	同时支持配置中心，CP 保证一致性

---

5. Step5：时间参数设计------各层超时/重试/TTL/探针计算

依据第4篇的时间参数传递链和重试策略方法论，逐层设计参数，确保约束关系成立。

时间参数配置全景图

flowchart TD Client[客户端] -->|HTTP| GW[Gateway 超时 5s] GW -->|Dubbo| OS[订单服务 RPC 超时 3s] OS -->|Dubbo| IS[库存服务 RPC 超时 1s] OS -->|RocketMQ| MQ[RocketMQ 发送超时 1s] OS -->|Seata| TC[TC 全局事务超时 30s] TC -->|DB| DB[(MySQL innodb_lock_wait_timeout=20s)] IS -->|Redis| REDIS[Redis 缓存 TTL 300s+random] OS -->|Sentinel| SENTINEL[限流窗口 1s] subgraph K8s POD[Pod] -->|Probe| LP[LivenessProbe 15s initialDelay 30s] end

图表主旨概括 ：从客户端到基础设施，展示了各层的核心时间参数及其约束关系。
逐元素分解 ：Gateway 超时 > Dubbo 超时 > 库存服务单次调用超时；AT 事务超时 > DB 锁超时；缓存 TTL 避免雪崩。
设计原理映射 ：遵循"超时链式传递"原则，下游超时必须小于上游，防止悬挂资源；TTL 随机化利用"缓存雪崩"预防策略。
工程联系与关键结论 ：参数设计需逐层推导并验证，任何一层违规都可能导致连锁超时或资源耗尽。

详细计算过程：

1. Gateway 超时 5s
   5s = max(Dubbo RPC超时3s, RocketMQ发送超时1s) + 安全余量1s + 协议转换开销

   必须大于内部RPC超时，避免网关提前断开连接导致后端无效处理。

2. Dubbo RPC 超时 3s

   针对订单服务调用库存服务的路径：
   3s > 库存服务自身超时1s + 支付服务处理时间预估1s + GC暂停最大0.5s ×2 + 网络RTT 2ms ×3 + 业务处理最大1.5s

   配置：@DubboReference(timeout=3000)。

3. Seata AT 全局事务超时 30s
   30s = GC_max 3s ×2 + 业务执行 10s + 网络往返 2ms×3 + Phase1/Phase2协调 10s + 余量 4s

   需覆盖两阶段提交的所有锁持有时间，且必须大于 DB 锁超时。

4. MySQL 锁超时 20s

   设置 innodb_lock_wait_timeout=20，小于 AT 的 30s，保证在事务回滚前锁不会因超时而被释放，导致数据不一致。

5. Redis 缓存 TTL 300s + random(0,300)

   防缓存雪崩，热点数据基础 TTL 5 分钟，加上随机偏移避免同时失效。

6. Sentinel 限流窗口 1s

   统计窗口 1s，QPS 10000 的设置直接映射到 grade: QPS, count: 10000，快速响应流量变化。

7. K8s LivenessProbe
   initialDelaySeconds: 30（等待应用启动），periodSeconds: 10, failureThreshold: 5，即探测失败 5 次（共 50s）后重启，但通过合理 timeoutSeconds 控制单次探测超时 3s，总探测持续 15s 后标记失败。此处简化展示。

完整时间参数表：

层级	参数	数值	计算依据/配置
Gateway	连接超时/响应超时	5s	>RPC超时+安全余量
Dubbo RPC	服务超时	3s	库存1s+支付1s+GC+余量
Seata AT	全局事务超时	30s	两阶段+业务+GC
MySQL	innodb_lock_wait_timeout	20s	<AT超时，确保回滚前锁持有
Redis	缓存TTL	300s+random(300)	防雪崩
Sentinel	统计窗口	1s	快速限流
K8s Probe	Liveness 失败阈值	15s (5次×3s)	initialDelay=30s

---

6. Step6：容量规划与部署方案

容量规划计算

1. 订单表分片存储规划

• 月增量：1TB，3年预估 36TB。
• 舒适单分片容量：500GB（约 5000万行，按行大小 1KB 估算）。
• 分片数计算：36TB / 0.5TB × 1.3（30% 冗余）≈ 93.6，向上取2的幂次 → 128 分片（初期实际部署4分片，按需逐年扩容）。
• 每分片存储：500GB 数据 + 索引（1.5倍）≈ 750GB，主从复制 ×2 ≈ 1.5TB SSD。
• 3 年后总存储：128 × 1.5TB = 192TB SSD。

初期配置：4个分片（ds_0~ds_3），每分片一主两从，半同步复制，数据量约 4TB/月。

2. Redis 容量规划

• 热点商品缓存：10 万条 × 2KB ≈ 200MB。
• Redis Cluster：3主3从，每节点 16GB 内存，总可用 48GB，远满足需求，并预留大量空间应对促销。

3. 应用实例容量规划

• 单 Pod 压测 TPS：500（包含 Dubbo 调用、AT 事务、业务逻辑）。
• 日常 QPS 10000，需 Pod 数 = 10000 / 500 = 20。
• 峰值 50000，HPA 自动扩容至 60 个 Pod。
• 单 Pod 资源请求：CPU 2核，内存 4Gi。

4. 连接池规划

• 每 Pod 数据库连接池：HikariCP maxPoolSize=20。
• DB 总连接数：20 Pod × 20 连接 × 4 分片 = 1600 连接，每个 MySQL 分片支撑 400 连接，需确保 max_connections 设置足够（如 1000），或采用 ProxySQL 收敛连接。
• Redis 连接：每 Pod Lettuce maxTotal=20。

容量规划计算表格图

flowchart TD subgraph 存储容量 MYSQL[MySQL 128分片 192TB SSD] REDIS[Redis 48GB 总内存] end subgraph 应用容量 APP[订单服务 日常20Pod/峰值60Pod] APP_CPU[每Pod 2C/4Gi] end subgraph 连接数 DB_CONN[MySQL 1600总连接] REDIS_CONN[Redis 1200总连接] end MYSQL --> DB_CONN APP --> APP_CPU REDIS --> REDIS_CONN

图表主旨概括 ：汇总了计算出的存储、应用和连接资源需求。
逐元素分解 ：展示了 MySQL 3年后的总存储容量、Redis 内存、应用 Pod 数和 CPU/内存配比，以及衍生出的连接数。
设计原理映射 ：基于业务增长预估和性能压测数据进行容量推导，符合容量管理最佳实践。
工程联系与关键结论 ：容量规划需留有弹性，初期按需部署，后续通过分片扩容和 HPA 应对增长。连接数过大需使用数据库中间件收敛。

部署方案（K8s 拓扑）

所有服务部署于同一 K8s 集群，跨3个可用区（AZ）。通过 podAntiAffinity 保证 Pod 分散部署。

核心 Deployment 配置 (订单服务)：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 20
  template:
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - order-service
            topologyKey: topology.kubernetes.io/zone
      containers:
      - name: order-service
        image: order-service:1.0.0
        resources:
          requests:
            cpu: "2000m"
            memory: "4Gi"
          limits:
            cpu: "4000m"
            memory: "8Gi"
        env:
        - name: JAVA_OPTS
          value: "-Xms3g -Xmx3g"
        livenessProbe:
          httpGet:
            path: /actuator/health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
          failureThreshold: 5

HPA 配置：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  scaleTargetRef:
    kind: Deployment
    name: order-service
  minReplicas: 20
  maxReplicas: 60
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: dubbo_qps
      target:
        type: AverageValue
        averageValue: "450"

Istio 已集成，实现金丝雀发布和 mTLS。整体部署拓扑如下图所示（将在全架构图中体现）。

---

7. 全架构图与时序图：电商订单系统的完整设计呈现

电商订单系统全架构图

flowchart LR subgraph "接入层" CDN["CDN"] --> Nginx["Nginx"] Nginx --> GW["Spring Cloud Gateway + Sentinel"] GW --> IstioGW["Istio Ingress Gateway"] end subgraph "服务层" IstioGW --> OS["订单服务 OrderService"] IstioGW --> IS["库存服务 InventoryService"] IstioGW --> PS["支付服务 PaymentService"] OS --> Dubbo["Dubbo RPC"] Dubbo --> IS OS --> RocketMQ["RocketMQ"] RocketMQ --> NS["通知服务 NotificationService"] OS --> SeataTC["Seata TC集群"] SeataTC --> OS SeataTC --> IS end subgraph "数据层" OS --> ShardingSphere["ShardingSphere-JDBC"] ShardingSphere --> MySQL_0[("MySQL 分片0")] ShardingSphere --> MySQL_1[("MySQL 分片1")] ShardingSphere --> MySQL_2[("MySQL 分片2")] ShardingSphere --> MySQL_3[("MySQL 分片3")] IS --> MySQL_0 IS --> RedisC["Redis Cluster 缓存+锁"] CDC["Debezium CDC"] --> MySQL_0 CDC --> Kafka["Kafka"] Kafka --> ES[("Elasticsearch 搜索")] Kafka --> ClickHouse["ClickHouse 分析"] Kafka --> S3["MinIO 归档"] OS --> Outbox["本地消息表"] end subgraph "基础设施层" K8s["Kubernetes 1.28"] --> OS K8s --> IS K8s --> PS K8s --> NS Istio["Istio 1.20"] --> K8s Nacos["Nacos 注册配置中心"] Prometheus["Prometheus"] --> Metrics["Metrics"] SkyWalking["SkyWalking"] --> Tracing["Tracing"] Loki["Loki"] --> Logs["Logs"] end Nacos --- OS Nacos --- IS Resilience4j["Resilience4j"] --- OS classDef access fill:#f1f5f9,stroke:#334155,stroke-width:2px,color:#0f172a classDef service fill:#ede9fe,stroke:#8b5cf6,stroke-width:2px,color:#3b2f4b classDef data fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a8a classDef infra fill:#e2e8f0,stroke:#475569,stroke-width:2px,color:#1e293b class CDN,Nginx,GW,IstioGW access class OS,IS,PS,NS,Dubbo,RocketMQ,SeataTC service class ShardingSphere,MySQL_0,MySQL_1,MySQL_2,MySQL_3,RedisC,CDC,Kafka,ES,ClickHouse,S3,Outbox data class K8s,Istio,Nacos,Prometheus,Metrics,SkyWalking,Tracing,Loki,Logs,Resilience4j infra

图表主旨概括 ：基于能力域×分层展示了电商订单系统的完整技术组件、调用关系和数据流。
逐元素分解 ：接入层由 CDN、Nginx、Gateway 和 Istio Ingress 组成；服务层是核心微服务通过 Dubbo 同步调用和 RocketMQ 异步通信，Seata TC 协调事务；数据层展示了分库分表、多引擎存储以及 CDC 数据管道；基础设施层展示 K8s、Istio 和可观测性组件。
设计原理映射 ：体现了分层解耦、关注点分离以及数据密集型架构的多组件协作。
工程联系与关键结论 ：此图可作为团队沟通、部署和故障排查的蓝图，明确每个组件的位置和交互。

一次下单的完整时序图

sequenceDiagram participant C as 客户端 participant GW as Gateway participant OS as 订单服务 participant Nacos as Nacos participant IS as 库存服务 participant TC as Seata TC participant DB as MySQL (分片) participant MQ as RocketMQ participant NS as 通知服务 participant CDC as Debezium participant ES as Elasticsearch participant CH as ClickHouse participant Redis as Redis participant Prom as Prometheus C->>GW: HTTP POST /order (能力域:通信, 分层:接入) GW->>GW: Sentinel限流检查 (通信/治理) GW->>OS: 路由转发 (Dubbo) [超时设置5s] OS->>Nacos: 发现库存服务地址 (治理) OS->>TC: 开启全局事务 xid (协作) [AT超时30s] OS->>DB: 插入订单 (undo_log) (存储域) OS->>IS: Dubbo调用扣减库存 (通信) [超时3s] IS->>DB: 更新库存 (协作,存储) IS-->>OS: 返回扣减结果 OS->>TC: 提交全局事务 TC->>DB: 异步删除 undo_log OS->>MQ: 发送事务消息"订单已创建" (通信域) OS-->>GW: 返回成功 GW-->>C: 200 OK (P99<100ms) MQ->>NS: 推送通知 (异步) CDC->>DB: 监听binlog CDC->>MQ: 发布数据变更事件 MQ->>ES: 更新订单索引 MQ->>CH: 写入分析数据 OS->>Redis: 更新缓存 (最终一致, TTL随机) OS->>Prom: 上报指标 (治理)

图表主旨概括 ：演示了从客户端下单到数据最终一致的全链路交互，标注了每步的能力域、分层和部分时间参数。
逐元素分解 ：开始于客户端请求，经过网关路由、服务发现，开启全局事务，执行订单插入和库存扣减，事务提交后发送消息，并行异步更新搜索和分析，最后返回。
设计原理映射 ：体现了同步核心链路（微服务+AT事务）与异步扩展点（事件驱动）的完美结合，以及时间参数的层次化传递。
工程联系与关键结论 ：此时序图是理解系统运行时行为的核心视图，清晰展示了强一致路径和最终一致路径的分离，以及各组件的时间约束。

---

8. 与前后系列的衔接

• 前4篇知识的整合 ：
  • Step1-2 基于第 1 篇的能力域模型和分层架构。
  • Step3 基于第 3 篇的四种架构模式及其组合策略。
  • Step4 基于第 1 篇的矩阵框架和第 2 篇的权衡哲学（如 AT vs TCC 的取舍）。
  • Step5 直接应用第 4 篇的时间参数传递链和重试策略设计。
  • Step6 涉及第 3 篇的云原生模式和第 4 篇的故障传播分析（如探针设置防止雪崩）。
• 对后篇的铺垫 ：
  • 第 6 篇《分布式系统架构评审与检查清单》将使用本文的六步产出物作为评审基线，验证架构是否合理。
  • 后续所有系列将对本文选用的技术进行深入原理剖析：Seata AT（分布式事务第2篇）、ShardingSphere（分布式数据架构第1篇）、Redis 缓存（分布式数据架构第6篇）、Sentinel（高并发与稳定性第1篇）、Kubernetes 生产化运维等。

---

9. 面试高频专题

本部分独立于正文，提供深度问答和系统设计实战，帮助你应对相关面试题。

9.1 请简述分布式系统设计的六步流程？每一步的核心产出是什么？

回答 ：需求分析→能力域拆解→架构模式选型→关键技术选型→时间参数设计→容量规划与部署。产出依次为：量化需求规格单、能力域映射表、模式组合方案、技术选型矩阵、时间参数表、资源清单与部署拓扑。
详细解释 ：这六步将模糊需求逐步具体化为可实施的架构。需求分析保证目标可度量；能力域拆解识别通信、协作、存储、治理挑战；模式选型确定宏观骨架；技术选型填充具体组件；时间参数协调全链路超时与重试；容量规划保证资源满足业务量级。整个过程就像建筑工程从需求到施工图，每一步都有明确的决策依据和交付物。
多角度追问：

• 如果需求变更怎么办？
  六步法支持迭代：当需求变化时，回溯到 Step1 更新规格单，然后逐步向下调整能力域映射和后续选型。架构模式通常不变，但技术选型和参数可能需要修改。关键决策记录（ADR）帮助追踪变化。
• 如何保证选型的前瞻性？
  在 Step4 对比选型时，除了满足当前需求，还需评估技术发展趋势、社区活跃度和团队技能栈。例如选择 Dubbo 而非 gRPC 是基于 Java 生态优势，即使未来引入少量 Go 服务，也可通过 Sidecar 或 Mesh 化集成。
  加分回答：引入架构权衡分析法（ATAM），对每个步骤产出的关键决策记录（ADR）进行版本管理，确保可追溯。定期进行架构评审（第6篇）验证设计是否仍符合业务发展。

9.2 如何根据业务需求选择架构模式？以电商订单系统为例，说明组合理由。

回答 ：核心低延迟同步链路选微服务，非核心异步链路选事件驱动，海量数据复杂查询选数据密集型，弹性伸缩需求选云原生。电商系统下单需要强一致低延迟，用微服务同步 RPC；通知、分析异步处理用事件驱动解耦；订单数据分片存储和多引擎满足海量数据需求；K8s+HPA 应对促销峰值。
详细解释 ：模式选择依据非功能需求。不能因为单一体模式简单而忽视扩展性，也不能全盘事件驱动牺牲同步响应。组合模式使各子域采用最合适风格。在电商系统中，微服务处理核心交易边界清晰，事件驱动将非核心流程异步化，数据密集型解决存储和查询扩展，云原生提供弹性基础设施。
多角度追问：

• 模式组合会不会增加系统复杂度？如何管理？
  会增加一定复杂度，但可通过领域驱动设计（DDD）划定限界上下文，每个微服务内部保持架构简洁。治理域统一使用 Istio 和 K8s 提供流量管理、可观测性，屏蔽底层差异。团队按能力域分工，模式组合反而促进并行开发。
• 为什么不用纯事件驱动模式？
  核心下单需要同步返回结果，若全部异步，用户无法立即知道库存是否充足。补偿流程复杂，违反低延迟要求。因此采用分段式，核心同步+外围异步。
  加分回答：采用"绞杀者模式"逐步从单体演进至微服务+事件驱动，降低风险。Netflix 的微服务实践表明，模式组合需要强大的基础设施（服务网格、可观测性）支撑。

9.3 在技术选型中，如何对比 Dubbo 和 gRPC、RocketMQ 和 Kafka？你的选型决策依据是什么？

回答 ：Dubbo 选型考虑 Java 生态和治理成熟度；gRPC 适合多语言。RocketMQ 因支持事务消息和低延迟而被选；Kafka 适合超高吞吐的大数据管道。决策依据：功能匹配度、团队技能、性能基准。
详细解释 ：Dubbo 3.0 支持 Triple 协议，兼容 gRPC，但阿里生态集成更好，提供丰富的服务治理功能。RocketMQ 的事务消息实现可靠投递（如订单状态变更通知），Kafka 的 exactly-once 语义复杂且延迟偏高。在电商场景，事务消息是刚需，RocketMQ 的延迟通常低于 Kafka。
多角度追问：

• 如果系统需要支持其他语言如 Go，如何调整？
  可采用 gRPC 作为统一 RPC 协议，结合 Dubbo 的 Mesh 化部署，或者通过 Istio 的 Sidecar 代理实现协议转换。对于消息队列，RocketMQ 也提供多语言客户端。
• RocketMQ 和 Kafka 的性能差异？
  Kafka 在顺序写和批量操作上吞吐更高，适合日志、大数据场景；RocketMQ 在低延迟、事务消息、多 Topic 路由方面更优。京东、阿里在金融场景大量使用 RocketMQ。
  加分回答：从 CAP 角度看，RocketMQ 支持主从异步复制或同步复制，可根据一致性需求配置。Kafka 的 ISR 机制在可用性和一致性之间平衡。选型必须结合生产压测数据，而不能仅凭理论。

9.4 分布式事务方案（XA/AT/TCC/Saga）在电商订单系统中如何选型？为什么选 Seata AT 而不是 TCC？

回答 ：选型依据：一致性需求、性能要求和侵入性。订单/库存强一致不需要高并发补偿，AT 模式零侵入性能可接受。TCC 虽性能高但代码侵入大，Saga 适用于长事务。
详细解释 ：XA 锁全程持有，性能差；TCC 需要实现 try/confirm/cancel，改造量大；Saga 是最终一致性，不适合核心链路。AT 基于数据库 undo_log，在一阶段提交本地事务，二阶段异步删除日志，性能损失约 10%。订单 TPS 1万通过分片可以消化，没必要过早优化为 TCC。
多角度追问：

• AT 模式在热点库存扣减时是否会性能瓶颈？
  通过库存分片和 Redis 分布式锁预扣减，减少数据库锁冲突。热点商品可以采用缓存扣减+异步回写，避免数据库行锁竞争。
• 如果未来 TPS 达到 10 万，AT 还能胜任吗？
  可能需要升级为 TCC，但在此之前可通过更多分片、优化 AT 参数（如异步删除 undo_log）、甚至引入库存服务端的队列串行化来支撑。
  加分回答：Seata AT 的 undo_log 基于数据库，额外存储开销约 10-20%。高并发下可考虑定期清理历史 undo_log，并结合 TC Server 集群提升吞吐。阿里在生产环境使用 AT 承载过亿级交易。

9.5 如何为分布式系统设计时间参数？从 Gateway 到 K8s 探针的超时是如何计算的？

回答 ：自顶向下，下游超时必须小于上游，保证调用链不会悬挂。Gateway 5s > Dubbo 3s > 库存服务 1s；Seata AT 30s > DB 锁 20s。缓存 TTL 设置随机值防雪崩，探针时间考虑应用启动和 GC。
详细解释 ：如果 Dubbo 超时设为 5s，Gateway 设 3s，可能网关超时断开，但后端仍在执行，浪费资源并可能造成数据不一致。因此必须遵循公式逐层推导。探针的 initialDelaySeconds 必须大于应用启动时间，避免滚动更新时 Pod 被误杀。
多角度追问：

• GC 停顿参数如何确定？
  通过压测和 JVM 监控获取 P99 GC 暂停时间，再乘以安全系数（如 2-3 倍）。例如 CMS 或 G1 通常暂停 100-200ms，ZGC 可达到亚毫秒级，系数可调低。
• 如果外部依赖服务不可控怎么办？
  使用 Resilience4j 的 TimeLimiter 主动设置超时，配合熔断快速失败，避免线程阻塞。
  加分回答：设计时间参数时，需画出全局依赖图，从最下游开始计算，向上累加。分布式追踪（SkyWalking）可用来验证实际耗时，反馈优化超时设置。

9.6 如何进行容量规划？订单表的分片数、Redis 内存、应用 Pod 数是怎样计算出来的？

回答 ：基于业务量预估和性能压测。订单分片数根据数据总量和单分片舒适容量（500GB）计算，预留 30% 冗余，向上取 2的幂次；应用 Pod 数 = 目标 QPS / 单 Pod 实测 TPS；Redis 内存根据热点数据大小并预留。
详细解释 ：3年36TB，每分片500GB，理论72片，加上冗余和扩容便利性取128片（初期4片）。压测得出单 Pod 500 TPS，日常 1万 QPS 需20个 Pod，峰值5万对应60个。Redis 缓存10万商品仅需200MB，但考虑大 key 和过期，集群 48GB 足够。
多角度追问：

• 如何应对突发流量导致 HPA 来不及扩容？
  设定一定的 Pod 冗余 minReplicas 高于日常需要，并配合预热和限流降级，保证在扩容期间系统不崩溃。还可以使用预测式扩缩（如基于趋势的 KEDA）。
• 连接数过大除了 ProxySQL 还有什么办法？
  使用数据库连接池的复用能力，或采用 ShardingSphere 的读写分离和连接管理，对业务透明。
  加分回答：容量规划不是一次性工作，需结合监控持续调整。Netflix 使用"红黑部署"和"金丝雀"逐步验证新版本资源消耗，避免大规模扩容失败。

9.7 分布式系统设计中最常见的错误是什么？如何通过六步流程避免这些错误？

回答 ：最常见是忽略超时传递与约束，导致资源悬挂；或者过度设计（过早采用 TCC）。六步法强制进行需求量化、时间参数逐层推导和容量规划，每一步评审可预防此类错误。
详细解释 ：很多系统直接拷贝配置，Gateway 超时 30s，RPC 超时 10s，导致雪崩。而六步法 Step5 要求计算并验证约束。Step3 的模式选型要求给出理由，避免盲目引入复杂模式。另一个常见错误是未考虑数据分层，单一数据库承载所有查询压力。
多角度追问：

• 有没有其它常见陷阱？
  忽视缓存与数据库一致性、未考虑分布式事务失败恢复、日志和指标设计缺失。Step4 矩阵中的治理域和 Step6 的可观测性部署均覆盖这些。
• 如何防止设计偏离实际？
  每一步产出都必须经过团队评审，并使用故障注入（Chaos Engineering）验证假设。
  加分回答：采用"架构决策记录"（ADR）记录每个选型背后的上下文和权衡，便于新成员理解，防止重复踩坑。六步法本身就是一种强制性的 ADR 流程。

9.8 系统设计题：社交 Feed 系统完整推演

题目：一个社交 Feed 系统，要求支持 10 万 QPS 的 Feed 流读取、1 万 QPS 的发布写入、P99 延迟 <50ms、可用性 99.99%，数据量每日新增 500GB。请使用六步法给出：（1）需求分析与优先级排序；（2）能力域拆解；（3）架构模式选型与组合理由；（4）关键技术选型矩阵；（5）时间参数设计方案；（6）容量规划与部署方案。画出系统的全架构图与时序图。

（1）需求分析与优先级排序

• 业务功能：用户发布动态（文本/图片）、好友关系维护、Feed 流聚合（关注用户动态按时间线展示）、评论/点赞。
• 服务质量量化 ：
  • 读 QPS：10 万（查看时间线）
  • 写 QPS：1 万（发布动态）
  • 读延迟 P99 < 50ms
  • 写入延迟 P99 < 200ms（允许一定异步）
  • 可用性 99.99%
  • 日数据增量：500GB（年增约 180TB）
  • 一致性要求：发布后最终在 Feed 流可见（<1s），好友关系强一致（必须实时），点赞数最终一致（<5s）。
• 优先级 ：
  • P0：读取 Feed 流（高吞吐低延迟）、发布动态（保证可靠写入不丢）
  • P1：好友关系变更（一致性要求高）、点赞评论
  • P2：历史动态归档、数据分析

（2）能力域拆解

能力域	技术挑战	策略
通信	读负载高，需扇出推送或拉取；写需异步削峰	推拉结合：大V推，普通用户拉，使用消息队列解耦写入
协作	好友关系维护需强一致，粉丝数等可最终一致	好友关系使用分布式事务或可靠本地消息表，计数使用缓存最终一致
存储	海量小数据（每条动态平均 2KB），时序访问模式，需冷热分离	热数据 Redis Cluster，温数据 HBase/Cassandra（按时间范围扫描），冷数据归档至对象存储
治理	流量突增（热点事件），需弹性扩缩；强依赖缓存	K8s + HPA；多级缓存（客户端缓存/CDN 边缘缓存）；熔断降级

（3）架构模式选型

• 微服务模式：拆分 Feed 读取服务、发布服务、好友服务、评论服务。服务独立部署，独立数据库。
• 事件驱动模式：动态发布后发送事件到 Kafka，异步触发推送给粉丝（写扩散）或更新缓存；好友变更通过事件同步更新 Feed 权限。
• 数据密集型模式：Feed 数据按 user_id 分片，热数据在 Redis，全量数据在 HBase（按时间范围高效扫描），ES 用于搜索动态，对象存储归档图片/视频。
• 云原生模式：K8s 编排，基于 QPS 的 HPA，Istio 实现金丝雀和负载均衡。

组合理由：微服务保证独立迭代，事件驱动异步扇出解耦，数据密集型解决海量小文件存储与查询，云原生保障可靠性和弹性。

（4）关键技术选型矩阵

flowchart LR subgraph 分层 L1[接入层] L2[服务层] L3[数据层] L4[基础设施] end subgraph 通信域 A1[OpenResty/LVS + Spring Cloud Gateway] A2[Dubbo 3.x + Kafka] A3[Kafka Log] end subgraph 协作域 B2[Redisson + Seata AT 好友关系] B3[本地消息表] end subgraph 存储域 C3[Redis Cluster + HBase/Cassandra + ES + MinIO + MySQL 分片] end subgraph 治理域 D1[Sentinel] D2[Nacos + Resilience4j] D4[K8s + Istio + Prometheus + SkyWalking] end A1 --- L1 A2 --- L2 A3 --- L3 B2 --- L2 B3 --- L3 C3 --- L3 D1 --- L1 D2 --- L2 D4 --- L4

核心选型理由：

• Dubbo：同步调用好友服务、评论服务（需低延迟）。
• Kafka：异步发布事件，高吞吐扇出，适合 1 万写 QPS 扩散。
• Redis Cluster：缓存热点 Feed 和用户时间线（预聚合的前 1000 条），保证读 <50ms。
• HBase：按用户 ID + 时间戳存储全量 Feed，顺序扫描性能极佳，适合读取历史时间线。MySQL 分片存储元数据和好友关系。
• ES：全文搜索动态内容。
• Nacos、Sentinel、K8s：常规治理组件。

（5）时间参数设计

• Gateway 读超时：200ms（留给后端 150ms）
• Dubbo RPC 读超时：100ms（Feed 服务 Redis 查询 80ms + 余量）
• Kafka 发送超时：100ms（确保写入快速返回，内部异步扇出）
• 好友关系 Seata AT 超时：10s
• Redis TTL：热点 Feed 缓存 60s + random(30s)
• 探针：同电商案例

（6）容量规划与部署

• 存储：日增 500GB，年 180TB。采用 HBase 集群存储，每节点 10TB HDD，20 节点可存 200TB，并留存余量。对象存储（MinIO/S3）存放原始图片视频，不占用 HBase。
• Redis 内存：假设 5000 万活跃用户，每人缓存时间线 100 条，每条 1KB，共 5TB。使用 Redis Cluster，每个节点 64GB，共需 100 个分片左右（考虑副本 3 主 3 从，约 200 节点）。可采用内存压缩或只缓存部分用户。
• 应用 Pod：读服务 10 万 QPS，单 Pod 压测 2000 QPS（Redis 查询），需 50 Pod。写服务 1 万 QPS，单 Pod 1000 TPS，需 10 Pod。HPA 配置相应扩缩。
• 部署拓扑：K8s 集群跨 3AZ，podAntiAffinity 保证分散。

全架构图（社交 Feed 系统）

flowchart TB subgraph "接入层" CDN["CDN"] --> LVS["LVS/Nginx"] LVS --> GW["Spring Cloud Gateway + Sentinel"] GW --> IstioGW["Istio Ingress"] end subgraph "服务层" IstioGW --> FeedRead["Feed读取服务"] IstioGW --> FeedWrite["发布服务"] IstioGW --> Friend["好友服务"] IstioGW --> Comment["评论服务"] FeedRead --> Dubbo["Dubbo RPC"] Dubbo --> Friend FeedWrite --> Kafka["Kafka"] Kafka --> Fanout["扇出处理器"] Fanout --> RedisTime["Redis 时间线缓存"] Friend --> MySQL["MySQL 分片"] end subgraph "数据层" RedisTime --> RedisC["Redis Cluster 热数据"] Fanout --> HBase["HBase 全量Feed"] Kafka --> ES["ES 搜索"] FeedWrite --> OSS["MinIO 图片/视频"] end subgraph "基础设施层" K8s["Kubernetes"] Istio["Istio"] Observability["Prometheus + SkyWalking + Loki"] end classDef access fill:#f1f5f9,stroke:#334155,stroke-width:2px,color:#0f172a classDef service fill:#ede9fe,stroke:#8b5cf6,stroke-width:2px,color:#3b2f4b classDef data fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a8a classDef infra fill:#e2e8f0,stroke:#475569,stroke-width:2px,color:#1e293b class CDN,LVS,GW,IstioGW access class FeedRead,FeedWrite,Friend,Comment,Dubbo,Kafka,Fanout,RedisTime,MySQL service class RedisC,HBase,ES,OSS data class K8s,Istio,Observability infra

一次发布的完整时序图

sequenceDiagram participant U as 用户 participant GW as Gateway participant Pub as 发布服务 participant FriendS as 好友服务 participant MQ as Kafka participant Fanout as 扇出服务 participant Redis as Redis Cluster participant HBase as HBase participant CDN as CDN U->>GW: POST /publish (通信域) GW->>Pub: 路由 Pub->>FriendS: Dubbo 查询好友列表 (通信/协作) FriendS-->>Pub: 返回粉丝列表 Pub->>MQ: 发布事件 (内容+粉丝列表) [超时100ms] Pub-->>GW: 返回发布成功 GW-->>U: 200 OK MQ->>Fanout: 消费事件 Fanout->>Redis: 将动态ID写入每个粉丝时间线缓存 (存储) Fanout->>HBase: 持久化动态 (存储) Fanout->>CDN: 图片/视频上传加速

图表主旨概括 ：展示了社交 Feed 系统的核心组件和写入流程，推拉结合模式下，发布时异步扇出到粉丝缓存。
逐元素分解 ：用户发布请求到达，发布服务查询好友列表，然后将事件放入 Kafka 快速返回；扇出服务消费事件，将动态 ID 推入每个粉丝的 Redis 时间线，并持久化到 HBase。
设计原理映射 ：采用事件驱动实现写扩散，解耦核心链路；Redis 提供低延迟读取，HBase 保证海量存储。
工程联系与关键结论 ：该设计满足了 10 万读 QPS 和 1 万写 QPS，通过异步扇出，写入延迟可由 200ms 保障，读取直接从 Redis 获取，延迟 <50ms。

---

设计流程速查表

步骤	输入	关键决策点	产出	关联前文	关联后文
Step1 需求分析	业务文档	量化QPS/延迟/一致性	需求规格单	第1篇能力域基础	第6篇评审清单
Step2 能力域拆解	需求规格单	映射通信/协作/存储/治理挑战	能力域映射表	第1篇四大能力域	后续各技术专题
Step3 架构模式选型	能力域挑战	选择微服务/事件驱动等组合	模式组合方案	第3篇架构模式	-
Step4 技术选型	模式方案+能力域矩阵	填充组件，对比备选	技术选型矩阵+配置	第2篇权衡哲学	Seata、ShardingSphere 等篇
Step5 时间参数	选型矩阵	逐层计算超时/重试/TTL	时间参数配置表	第4篇时间维度	-
Step6 容量部署	时间参数+选型	计算分片、Pod、存储	部署拓扑+资源清单	第3篇云原生、第4篇故障传播	K8s 运维系列

延伸阅读：

• 《Designing Data-Intensive Applications》第1-2部分，第12章。
• 《Microservices Patterns》第1-5章。
• 阿里 Seata 官方文档，美团分库分表实践。
• Netflix 微服务实践 (Netflix OSS)。
• Twitter Fanout 服务架构论文。

至此，我们通过电商和社交两个完整案例，将分布式系统设计的六步法彻底落地。当你面对任何分布式系统设计需求时，都可以有条不紊地按照这六步推演，构建出鲁棒、可扩展的架构。