这一周主要是确保在春节前各类服务的稳定。近期发现某个服务经常在流量高峰时段报超 时，我提醒转交服务负责人处理。但是几天过去，服务负责人依然无法说明原因。只好亲自 处理这个问题，因为报警已经十分严重，部分节点超时率能够达到 20%。
在这段时间中，应该是由于临近假期，流量大幅度上涨，12 月底相比已经上涨了 100%。所 以首先是怀疑服务的承载力不足，所以先进行了一次扩容。但是，扩容后并未解决此问题， 告警频率和超时率基本未变化。这种情况下，对服务的源代码进行分析后发现，该服务的接 口会首先调用一个下游服务，然后再异步地向数据库中插入数据。因为异步操作并不阻塞工 作线程，所以首先应该怀疑是这个下游调用的问题（实际上，我在数据库那边纠结了很 久）。 从终端登录进一个节点检查日志，发现所有下游调用走的居然是同一个 IP 和端 口，并且走的是稻草人节点。所以我先将该服务做上云操作，排除稻草人转发损失造成的影 响。上云完成后，刚切流量的时候发现某个地域（不是原先的地域）下有大量超时产生，做 了扩容后也无解，十分疑惑，所以暂时切回来了。我非常奇怪，为什么上云之后，超时率却 变得更高了。
从云上监控分析问题，发现在切流量后，下游服务的某个云上节点 CPU 占用非常高，而其 他的节点却很低。开始怀疑是负载均衡的问题，所以又回去检查服务的源代码。果然，该服 务从注册中心拿到下游服务可用节点列表后，只会调用列表中的第一项。所以某个地域的几 乎所有流量都集中在下有服务的某一个节点上了。而原先通过稻草人转发的时候，稻草人调 用云上节点的时候会做一次负载均衡。所以，最初的问题应该是流量大量上涨，该服务却没 有负载均衡，所以导致某个稻草人过载，进而导致超时。稻草人是代理节点本身没有逻辑， 所以能够处理的并发数更大，超时问题不是很明显。而一旦上云，流量会直接集中在某个业 务节点上，大量流量一齐涌入，会瞬间导致该业务节点大批量超时。 有了上述的论断后， 回去找稻草人的监控，发现某个稻草人确实已经过载了，CPU 占用居然达到了 95 以上。知 道原因后，接下来继续上云，先最大限度消除超时告警，然后再改代码添加随机负载均衡算 法。这样做是因为节前修改代码，流程上会比较麻烦。
所以首先，我加倍了下游服务的单个节点的核数，这大大增加处理能力。然后，做切流量的 操作，一个下游节点的 CPU 占用数突然升高，最终一直保持在比其他节点高很多的比例 上，这是意料之中的事情。当整个服务平稳下来后，上云就成功了，这个时候告警已经消 除，超时率归零。接着，就是修改改服务的代码，添加负载均衡的机制，在各个流程审批通 过后为该服务发布新的代码版本。 在我发布完新版本后，下游服务的各个节点的 CPU 占用 就接近了，最终问题解决。