[微服務架構]及聯問題和斷路器
- 2019 年 12 月 19 日
- 筆記
及聯問題是一個很嚴重的問題，它的現象是多個業務共用一個資源池，如果其中一個業務訪問外部系統，當外部系統響應緩慢，且訪問量大的時候，這個業務會佔用所有的資源池 ，導致其它所有的業務都無法工作。
在微服務中，由於服務越來越多，從概率上說，其中某個服務發生概率的情況就越來越大。對於每個對其它服務的請求，我們都要考慮它可能會出問題，設計時考慮會不會產生及聯問題，和發生了應該怎麼處理，之前我在工作中就出現過一個類似的情況。
項目使用springboot作為微服務的框架，用@Async做統一的執行緒池管理去處理所有的非同步處理和外部系統調用，包括簡訊系統的請求，推送系統的請求等。有一天線上客戶回饋接受不到簡訊通知，好在日誌打的比較詳細，發現數據正常，但是沒有調用簡訊系統的請求日誌。由於程式碼一直執行的很好，認為不是程式碼的問題，可能是執行緒池堆積了其它調用任務。仔細檢查外部調用日誌，發現是某個政府的介面的請求任務很多，而且請求存在操時情況。考慮這個外部請求只會在一些極少數的校驗業務中出現，不是主要業務，於是我們停掉了這個政府介面調用，重新分步上線，問題就得到了解決，用戶可以收到簡訊了。之後我們對系統的外部系統請求都做了一個斷路器（超時閥值），如果超時數過多，就在一個時間斷不執行這個外部請求，直接返回請求失敗，就好像保險絲一樣，不能讓一個外部請求導致整個業務都不可用。
在微服務的架構中，某個外部請求不可用造成堵塞任務，耗盡資源的情況一定會出現，就可以採用斷路器來解決這種問題。
上面問題還可以使用艙壁來解決，即每個外部調用都用自己獨立的執行緒池，執行緒池之間互不干擾，但這樣的缺點是浪費資源，會有大量的執行緒，而且隨著業務的開發，人員的變更，大家都不知道這個項目開了多少個執行緒池。
