服务拆分迁移，但是拆分后的子服务，会有一台机器CPU 飙100%，持续一下就没了。
背景
一个定时任务服务，由于定时任务属于边缘业务，各业务线发展拆分时，一直没有动这个服务。 最近这个服务改动太过频繁，太多业务在一个服务上，今天这个上线，明天那个上线。
那就拆吧，各个业务线自己拎走自己的业务。
其中一个2B 业务线的定时任务，在拆分后，会有一台服务器CPU 飙100%。
问题表象
一个凌晨的定时任务，会对所有企业客户做一次一天内的数据统计。
然后这个任务在执行时，就会有 CPU 飙100%。
问题排查
一） 查监控
查了下监控，在 CPU 飙高时，是 java 线程飙起来的。
此时没有 YGC 和 FGC。没有系统异常。
排队服务问题
二）看代码
任务流程比较长，长期打补丁的操作，使任务的性能比较低。
都是一些比较频繁的计算动作。典型的 CPU 密集型服务。
更要命的是，任务中有多处递归调用。还有几处的嵌套递归调用。
这玩意，CPU 不高才怪。
三）为啥没拆之前没会飙高呢？
没拆之前，各业务线在同一上服务上，服务扩容最后有10台服务器。拆分后这个业务上只拿到2台服务器。
线上数百家的企业客户，由10台变2台。处理是有点费劲。
问题一下子明了了。
根本问题
一）代码写的不好 ，很需要优化。但逻辑又臭又长，一时没人下得了手。
二）由10台服务器一下子降到2台。任务略有压力
解决
好在是定时任务，没有时效要求。
当前服务器 CPU 是 4 核 4 线程。任务线程池的线程数降到2 。
2个线程打爆了也只占50% 。
任务时间由原来的20分钟，延长到了2小时。
根本解决
还得从代码上根本解决，任务拆分，结构化计算逻辑。
去掉递归调用。
服务器压力还是有的 。后面还抗不往就得加机器了。
总结
历史包袱啊。。。 唉！只能说每个人尽量自觉些，写代码用点心。