本周我发现有些服务框架写得并不是很好，特别是某些 Java 框架。当 CPU 占用达到 40% 左右的时候，就会出现大量的超时现象。这些服务，CPU 核心和内存容量不是不多，工作线 程数目也不是不够。但是，就是跑不满 CPU。用 Java 性能工具分析发现，其实发现大部分 工作线程处于 Idel 或者 Waiting 状态。目前综合所有情况分析，还是百思不得其解。NIO 也用上了，还用的是 Netty 框架，但是吞吐量就是上不去。通过对于线程的分析，发现并 没有特别繁忙的业务线程。推断应该是 IO 或者某种等待机制导致了这种低处理效率。 这 次我是准备通过削减节点数量来降本，在执行前并没有考虑特别多的因素。所以我在削减节 点容量的时候，只是通过查看 CPU 的负载来判断节点是否能够承受。当我将北京地域的 workload 平均 CPU 占用率提升到 35%-40%的时候，整个服务出现了大量的超时现象。当时 把我吓了一跳。后面从监控上分析，几乎是整个背景地域的节点都超时了，也就是处于一 种”休克“状态。

本周也继续重构某一个老的 PHP 网关服务，新的网关用 Java 写成。但是我其实不是很赞 成网关用 Java，毕竟 Java 这种语言的执行特性很大程度上决定了它不适合特别高的并 发。并且，我们目前所用的都是 JDK 8，并没有引入轻量级的线程，每个 4c8g 容器内线程 最多也就 800 个，多了线程切换开销就会特别大。所以单个容器的吞吐量有限，承载同样 的流量需要更多的容器。刚开始我是用 Go 重写的，这个框架很不错而且也有专门的团队维 护，但是 leader 还是让我用部门自研的那个 Java 框架。可能人事上的考虑居多吧，无 奈，我还是先写吧。