服務拆分遷移，但是拆分後的子服務，會有一臺機器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小時。
根本解決
還得從代碼上根本解決，任務拆分，結構化計算邏輯。
去掉遞歸調用。
服務器壓力還是有的 。後面還抗不往就得加機器了。
總結
歷史包袱啊。。。 唉！只能說每個人儘量自覺些，寫代碼用點心。