寫了一個慢介面，年終妥妥的325

一個專案要想抗住越大的壓力，那麼每個 API 都得在最短的時間內響應，這樣吞吐量才高。

在很多時候，開發壓根沒有去做過最佳化，等到某天壓力上來時，系統就扛不住了。

舉一個最常見的例子：

大家上班都會做地鐵（土豪可以開車哈）吧，地鐵都有固定的幾個入口，每個入口有幾個固定的閘機可以掃碼進入。

如果每個人掃碼進站的時間都控制在 2 秒內，那麼一個閘機一分鐘可以過 30 個人。如果有一個人他在那磨蹭半天，花了 20 秒，也就是這個閘機這一分鐘只能過 21 個人，吞吐量立馬就下降了。

這種生活中的案例在程式的世界中也是同樣適用的，而且是一個原理，只要有一個慢介面，就會影響整體的效能。總的來說就是隊友都要很給力，不要有 Pig 隊友。

下面看真實案例：

正在划水看美女的時候，突然收到告警，有幾個介面響應時間超長，高達幾十秒。慌得一批，估計哪裡又出問題了。

趕緊上 Cat 看看詳情情況，商品服務的一個 RPC 介面響應太慢了，而且也沒啥呼叫量，淚奔。。。

仔細看其實並不是有很長的耗時操作，但是整體耗時卻很長，肯定是請求被阻塞了。

然後去看對應機器的監控，發現 CPU 很高，幾乎 100%的狀態。

看了下 GC 情況，也挺正常的，後面看了執行緒池的情況才發現原因。

上面只是表面現象，告警的時候是有幾個慢介面的，排查的時候就選了第一個在看，忽略了其他的介面，以為是同一個問題。

真正慢的是另一個慢介面被 Job 大量呼叫了，服務執行緒都被打滿了。導致其他介面很慢。

最佳化方案：

• 定時任務時間調整，儘量在凌晨執行
• 單獨提供一個服務，只對 Job 提供服務，連從庫，影響降到最小
• 對慢介面進行效能最佳化

關於作者：尹吉歡，簡單的技術愛好者，《Spring Cloud 微服務-全棧技術與案例解析》, 《Spring Cloud 微服務 入門 實戰與進階》作者, 公眾號 猿天地 發起人。

有收穫，不要吝嗇你的轉發和在看。