Akka HTTP+Akka Stream服务CPU持续高负载问题排查求助

先理清楚你的场景：用Akka HTTP搭了个GET API，业务流程是接收请求后通过Akka Stream先调用第一个响应较快的外部服务（并行度2），再用它的结果调用第二个响应较慢的服务（并行度1），部署在AWS ECS单节点上。运行一段时间后，请求越多CPU使用率越高，甚至停了请求CPU还是居高不下，怀疑是背压触发异常。结合你的代码和场景，给你几个具体的排查方向：

1. 先查连接/流泄露：未正确处理HTTP响应实体 #

你的代码里用了Akka HTTP的连接池（cachedHostConnectionPool/cachedHostConnectionPoolHttps），这类连接池依赖连接复用，但如果HTTP响应的Entity没被完全消费或关闭，连接就没法释放，会一直占着线程池资源，导致CPU持续高负载。

看你第一个服务的parseResponse方法：

• 成功分支里用了entity.dataBytes.alsoTo(Sink.ignore).runFold(...)，这确实能确保数据被消费，但失败分支直接throw ex——如果是请求发送后得到了失败响应（比如5xx），对应的HttpResponse的Entity根本没被处理，连接就会被卡住。
• 建议不管响应成功还是失败，都要确保Entity被处理。比如把失败分支改成返回失败的Future，同时如果有响应的话要丢弃Entity：

  case (Failure(ex), t) => 
    // 若存在响应实体，务必丢弃
    ex match {
      case HttpResponseException(_, response) => response.entity.discardBytes()
      case _ => // 无响应的情况无需处理
    }
    Future.failed(new RuntimeException("Request to first service failed", ex))
  

• 另外，你没贴第二个服务的parseResponse代码，一定要检查它是不是也有同样的问题——第二个服务响应慢，连接占用时间更长，泄露的影响会更明显。

2. 验证背压逻辑：上下游速度不匹配导致的缓冲区积压 #

第一个服务并行度2、响应1-2秒，每秒大概能处理1个请求；第二个服务并行度1、响应3-4秒，每秒只能处理0.25个请求。这种上下游速度差很容易导致上游生产的元素在下游缓冲区积压，如果背压信号没正确传递，Akka Stream的缓冲区会一直处于工作状态，CPU就降不下来。

可以这么排查：

• 显式配置流的缓冲区大小和溢出策略，比如在第一个服务的流后面加.buffer(2, OverflowStrategy.backpressure)，确保背压能及时传递到上游的HTTP请求源，避免无限制积压。
• 用Akka的监控 metrics（比如集成Prometheus+Grafana）查看每个Flow阶段的元素流入/流出速率、缓冲区占用情况——如果某个阶段的缓冲区一直处于满的状态，说明背压确实没起作用，或者下游处理能力跟不上。
• 注意你在第一个服务的流里加了.async，这会创建异步边界，缓冲区就在这里，积压的概率更高。

3. 检查线程池配置：避免上下文切换过载 #

Akka HTTP的连接池和Akka Stream都依赖Dispatcher线程池，如果配置不合理，比如核心线程数过多，会导致频繁的上下文切换，CPU利用率飙升。

针对你的ECS单节点场景：

• 检查application.conf里的akka.http.host-connection-pool dispatcher配置，应该用IO密集型的线程池（核心线程数建议设为CPU核心数的2倍左右，比如单节点2核的话设为4）：

  akka.http.host-connection-pool {
    dispatcher {
      type = Dispatcher
      executor = "thread-pool-executor"
      thread-pool-executor {
        core-pool-size-min = 4
        core-pool-size-max = 4
      }
      throughput = 100
    }
  }
  

• 用jstack或者jconsole查看线程状态，如果有大量处于RUNNABLE状态的线程，或者WAITING状态的线程占比异常，说明线程池配置有问题。

4. 排查异常处理：避免流频繁崩溃重启 #

看你第一个服务的parseResponse里，失败分支直接throw ex，这会导致当前流崩溃。如果你的API是每个请求创建一个独立流，那单个请求失败只会影响自己，但如果是多个请求共享一个流，崩溃后重启会持续消耗CPU；另外，大量未捕获的异常会导致日志打印过载，也会拉高CPU。

建议：

• 用Flow.recover或者Future.recover处理异常，不要直接抛出，比如把失败分支改成返回一个错误的结果，而不是让流崩溃。
• 检查日志，看有没有大量的连接超时、解析失败等异常信息——如果异常频繁发生，CPU会一直处理异常堆栈，无法降下来。

5. 环境层面检查：ECS资源限制与系统监控 #

AWS ECS的单节点任务可能有CPU资源限制，如果配额太少（比如0.5核），服务运行时会被系统节流，反而导致上下文切换更频繁，CPU利用率看起来很高。

可以这么做：

• 查看ECS任务的CPU配额，确保足够支撑你的服务负载（比如单节点2核的话，给服务分配1核以上的配额）。
• 用CloudWatch监控ECS实例的CPU使用率、网络连接数、线程数——如果连接数一直在增加没有下降，那基本可以确定是连接泄露了。
• 检查系统日志（比如dmesg），看有没有OOM killer或者其他系统级问题，这些也会导致CPU异常。

6. 检查代码中的阻塞操作 #

Akka Stream里如果有阻塞操作（比如同步IO、计算密集型任务），会占用Dispatcher线程，导致线程池无法处理其他任务，CPU持续高。

• 检查你的parse方法，有没有调用阻塞的API？如果有，把这些操作放到专门的阻塞Dispatcher里，比如用.async("blocking-dispatcher")隔离。
• 还要注意，如果你在API里用Await.result同步等待流的Future结果，会阻塞Akka的线程，导致线程池被占满，这也是常见的CPU高负载原因。

内容的提问来源于stack exchange，提问作者Saddam Abu Ghaida