4、服务间调用风险分析：网络延迟、服务不可用、资源耗尽、级联故障的成因与模拟

在微服务架构中，服务间调用不再是本地方法调用，而是一次跨越网络、依赖远端进程的远程过程调用（RPC）。每一次调用都暴露在分布式系统的“八宗罪”之下：网络延迟、服务不可用、资源耗尽、级联故障——这四大风险是导致系统雪崩的核心诱因。本章将逐一剖析其成因，并通过模拟手段验证其破坏力。

4.1 四大核心风险成因

4.2 网络延迟：看不见的“慢请求”杀手

网络延迟是分布式系统中最隐蔽的风险。一次正常的数据库查询可能只需 5ms，但若网络出现抖动，同一查询可能耗时 500ms。在 NestJS 应用中，默认的 HTTP 客户端（如 axios）如果没有设置超时，会无限等待。

4.2.1 延迟的典型成因

• 物理距离： 跨机房、跨地域调用，光速限制带来固定延迟。
• 网络拥塞： 带宽打满导致排队，TCP 拥塞控制算法降低发送速率。
• DNS 解析： DNS 缓存失效后，递归查询可能耗时数百毫秒。
• TCP 握手与重传： 三次握手、慢启动、丢包重传都会增加延迟。

4.2.2 模拟网络延迟

在开发与测试环境中，可以使用 tc（Linux 流量控制）或 Node.js 的 express 中间件模拟延迟：

// 模拟 200ms 固定延迟的 NestJS 中间件
import { Injectable, NestMiddleware } from '@nestjs/common';
import { Request, Response, NextFunction } from 'express';

@Injectable()
export class LatencySimulationMiddleware implements NestMiddleware {
  use(req: Request, res: Response, next: NextFunction) {
    const delay = parseInt(req.query._delay as string) || 200;
    setTimeout(() => next(), delay);
  }
}

4.3 服务不可用：从“慢”到“挂”的临界点

服务不可用通常分为“部分不可用”（如某个接口返回 500）和“完全不可用”（进程挂掉）。在 NestJS 中，常见的不可用场景包括：

• 数据库连接池耗尽： TypeORM 或 Prisma 的连接池配置过小，突发流量导致所有连接被占用，后续请求排队超时。
• 内存泄漏： 未正确销毁的订阅、闭包引用导致堆内存持续增长，最终 OOM。
• 死锁： 多个事务互相等待锁释放，数据库连接被长时间持有。

4.3.1 模拟服务不可用

在测试中，可以通过动态关闭服务端口或返回固定错误码来模拟：

// 模拟服务不可用：返回 503
@Get('/unstable')
unstableEndpoint(@Query('fail') fail: string) {
  if (fail === 'true') {
    throw new HttpException('Service Unavailable', 503);
  }
  return { status: 'ok' };
}

4.4 资源耗尽：线程池与连接池的“隐形天花板”

资源耗尽往往是网络延迟和服务不可用的“放大器”。以 NestJS 默认的异步事件循环模型为例，虽然 Node.js 是单线程事件循环，但 连接池、线程池（libuv）、数据库连接池 仍然是有限资源。

4.4.1 资源耗尽模拟实验

// 模拟数据库连接池耗尽（使用 TypeORM）
@Injectable()
export class UserService {
  constructor(
    @InjectRepository(User)
    private userRepo: Repository<User>,
  ) {}

  async slowQuery(id: number): Promise<User> {
    // 模拟 5 秒慢查询，占住连接不放
    await new Promise(resolve => setTimeout(resolve, 5000));
    return this.userRepo.findOneBy({ id });
  }
}

4.5 级联故障：雪崩效应的完整链路

级联故障是前三种风险叠加后的最终形态。其传播路径通常如下：

1. 触发点： 服务 C 因数据库慢查询变得响应缓慢（延迟升高）。
2. 资源占满： 服务 B 调用服务 C 的 HTTP 连接池被慢请求占满，所有线程都在等待 C 响应。
3. 拒绝服务： 服务 B 的线程池耗尽，无法处理来自服务 A 的新请求。
4. 反向传播： 服务 A 调用服务 B 超时，A 的连接池也开始被占满。
5. 雪崩： 整个调用链上的所有服务都进入“假死”状态。

4.6 模拟实验：在 NestJS 中复现级联故障

为了在本地环境验证级联故障，我们可以搭建一个三节点调用链：

// 服务 C：模拟慢查询
@Get('/data')
async getData() {
  await new Promise(resolve => setTimeout(resolve, 5000)); // 5s 延迟
  return { data: 'ok' };
}

// 服务 B：调用服务 C，无超时保护
@Get('/proxy')
async proxy() {
  const response = await lastValueFrom(
    this.httpService.get('http://service-c/data')
  );
  return response.data;
}

// 服务 A：调用服务 B，并发 20 个请求
async simulate() {
  const promises = [];
  for (let i = 0; i < 20; i++) {
    promises.push(
      lastValueFrom(this.httpService.get('http://service-b/proxy'))
    );
  }
  await Promise.all(promises);
}

4.7 风险量化指标

在架构设计中，我们需要用数据衡量风险程度。以下是四个关键指标：

4.8 本章小结