1 背景

处理CPU突增问题时，首先要对整个系统的整体结构和流量路径做到心中有数。例如流量进入系统要经过负载均衡、网关、服务…

引起高利用率的原因可能多种多样，具体情况需要根据具体位置的警报来进行判断。

2 场景与解决

2.1 单机硬件故障

表现：整个系统链路上各个环节流量均正常。

可能原因：现如今微服务部署，一台物理机上可能划分多个虚拟机器，并分配给不同的业务使用。由于由于单机硬件性能影响，及同宿主机的其它业务影响，导致自身服务部可用。

解决：快速禁用服务，更换机器。通过服务管理中心禁用改机服务，随后替换。

注意事项：这种情况一定是先处理故障，再排查具体影响。保证业务稳定。

2.2 外部流量快速上涨

表现：监控系统上关于消息服务、HTTP、RPC等请求量快速增长。流量较低时，未出现问题，高流量时发生问题。

可能原因：

  • 系统业务逻辑存在瓶颈，例如某个环节有加锁处理计算逻辑。低流量时不会产生问题，流量突增后，导致异常。
  • 流量分配不均匀。例如采用同机房路由策略。而在某个机房下服务提供者机器过少，而上游流量又过大。

解决：

  • 接口限流，服务扩充，服务重启。
  • 调整服务路由策略。例如关闭同机房优先。
  • 事后压测，复现场景，找出高消耗CPU的任务。

注意事项：如果资源充足的情况，有限使用扩容，这样尽量保证服务可用。其次再考虑限流，同事要评估限流导致的损失是否可控。

2.3 服务内部逻辑缺陷

表现：与2.2原因一致，只是这种逻辑问题在小流量情况下也会导致服务不可用，单机CPU利用率过高。

可能原因：开发时逻辑有问题。

解决：

  • 尽快回滚系统。
  • 事后分析，例如java应用结合top、ps、jstack等工具组合分析，或根据监控系统分析。

注意事项：这种问题，在发布时，一定是要灰度发布，并有一个观察期。随后出现问题快速回滚。

3 总结

遇到这种问题，优先要保证服务可用。先不要去考虑原因。快速限流、重启、扩容、甚至混滚系统，随后逐步恢复流量。事后分析场景，解决问题。

在没有自动化平台时，要熟练了解解决这些问题的工具。