4. 系统架构理解：从单体到分布式，架构如何塑造压力特征

压力测试不是盲目的“并发打满”，而是基于系统架构的精准施压。不同的架构决定了瓶颈位置、资源竞争模式和扩展能力，进而直接影响压力测试的特征清单。本章将剖析三种主流架构及其对压力特征的影响，并给出关键链路识别的系统方法。

4.1 常见系统架构概览

现代软件系统架构经历了从单体到微服务、再到分布式的发展历程。下表从压力测试视角对比三种架构的核心差异：

4.2 架构对压力特征的影响

架构决定了压力测试中需要关注的特征维度。以下从三个核心维度展开：

4.2.1 资源竞争模式

• 单体架构： 所有请求共享同一进程资源（CPU、内存、线程池、数据库连接池）。压力特征表现为资源耗尽型——当并发数超过线程池上限时，请求直接排队或拒绝。
• 微服务架构： 每个服务独立部署，资源隔离。压力特征表现为级联效应——一个服务过载会导致上游服务等待超时，进而引发雪崩。
• 分布式架构： 资源分布在多台机器上，但共享数据层（如数据库、缓存）。压力特征表现为热点争用——某些数据分片或节点成为瓶颈。

4.2.2 延迟与超时特征

• 单体架构： 延迟主要来自数据库查询和本地计算，通常呈正态分布。
• 微服务架构： 延迟包含网络开销（序列化/反序列化、网络传输）。特征表现为长尾延迟——少量慢服务拖慢整体响应。
• 分布式架构： 延迟受网络分区、数据复制、分布式事务影响。特征表现为抖动延迟——延迟曲线出现周期性或突发性尖峰。

4.2.3 扩展能力与瓶颈迁移

• 单体架构： 扩展能力有限，瓶颈固定（通常是数据库）。压力测试中瓶颈位置不迁移。
• 微服务架构： 可以按服务独立扩展。压力测试中瓶颈会动态迁移——当A服务扩容后，瓶颈可能转移到B服务或数据库。
• 分布式架构： 扩展能力最强，但瓶颈可能出现在协调层（如ZooKeeper、配置中心）或数据层（如分库分表中间件）。

4.3 关键链路识别方法

关键链路是指用户请求经过的、对系统性能影响最大的路径。识别关键链路是构建压力测试特征清单的前提。以下是系统化的识别方法：

1. 业务价值排序： 列出所有核心业务场景，按用户量、交易额、影响面排序。前20%的场景通常覆盖80%的流量。
2. 调用链分析： 使用APM工具（如SkyWalking、Zipkin）或日志追踪，绘制请求的完整调用链。标记每个节点的平均耗时、P99耗时和错误率。
3. 依赖关系梳理： 识别服务间的同步依赖（HTTP/RPC）和异步依赖（消息队列）。同步依赖是压力传递的关键路径。
4. 资源消耗评估： 对每个节点评估CPU、内存、IO、网络带宽的消耗占比。资源消耗最高的节点通常是瓶颈。
5. 容错机制标记： 标记熔断、降级、限流、重试等容错策略的位置。这些机制在压力下会触发，改变链路行为。

4.4 架构与关键链路关系图

下图展示了三种架构下关键链路的典型形态，以及压力特征在链路中的分布：

4.5 关键链路识别实战案例

以电商“下单”场景为例，展示关键链路识别过程：

4.6 架构视角下的压力测试特征清单模板

基于架构理解，压力测试特征清单应包含以下核心字段：

{
  "架构类型": "微服务架构",
  "关键链路": [
    {
      "链路名称": "下单流程",
      "节点列表": ["网关", "订单服务", "库存服务", "支付服务"],
      "脆弱节点": "库存服务（P99波动大，有熔断）",
      "瓶颈迁移路径": "订单服务→库存服务→数据库"
    }
  ],
  "压力特征": {
    "资源竞争模式": "级联效应",
    "延迟特征": "长尾延迟",
    "扩展能力": "按服务独立扩展",
    "容错机制": "熔断（库存服务）、降级（支付服务）"
  },
  "压测策略": {
    "施压方式": "全链路混合施压",
    "监控重点": "服务间调用耗时、熔断触发次数、数据库连接池",
    "数据隔离": "使用Mock模拟支付服务"
  }
}

4.7 架构演进对压力测试的启示

随着架构从单体向分布式演进，压力测试的复杂度呈指数级增长。以下是架构演进对压力测试特征清单构建的启示：

• 单体架构： 特征清单聚焦于单点资源极限（CPU、内存、数据库连接）。压测场景简单，但需要精确测量资源耗尽点。
• 微服务架构： 特征清单必须包含服务间依赖图、容错机制触发条件和级联效应传播路径。压测场景需要模拟真实调用链。
• 分布式架构： 特征清单需要增加数据一致性、网络分区、分布式锁等高级特征。压测场景需要模拟网络故障和数据热点。