文章轉載於
https://my.oschina.net/yu120/blog/664747?p={{currentPage+1}}
摘要
微服務是當前業界的一個趨勢，其原理是將職責單一的功能獨立化成子服務，一個後臺服務依賴多個微服務。假設某服務由30個微服務組成，每個微服務的可用性是99.99%，那麼99.99%的30次方≈99.7%，也就是說有0.3%的請求會失敗，若有一億次請求則有300000次失敗。熔斷隔離就是爲服務穩定性而生。
1 什麼是微服務
對於微服務，我們可以簡單的理解成對一個服務解耦，以降低業務系統的複雜性，將服務系統中的功能進行拆分成多個輕量的子服務，各個自服務間通過RPC實現服務間的關聯，這樣做的好處是將業務簡單化，每個子服務可以有自己獨立的編程語言，模式等且能夠獨立維護，獨立部署，功能複用。
2 爲什麼需要做服務隔離與熔斷
由於微服務間通過RPC來進行數據交換，所以我們可以做一個假設：在IO型服務中，假設服務A依賴服務B和服務C，而B服務和C服務有可能繼續依賴其他的服務，繼續下去會使得調用鏈路過長，技術上稱1->N扇出。如果在A的鏈路上某個或幾個被調用的子服務不可用或延遲較高，則會導致調用A服務的請求被堵住，堵住的請求會消耗佔用掉系統的線程、io等資源，當該類請求越來越多，佔用的計算機資源越來越多的時候，會導致系統瓶頸出現，造成其他的請求同樣不可用，最終導致業務系統崩潰，又稱：雪崩效應。
1->N扇形
雪崩效應
3 服務雪崩的原因
（1）某幾個機器故障：例如機器的硬驅動引起的錯誤，或者一些特定的機器上出現一些的bug（如，內存中斷或者死鎖）。
（2）服務器負載發生變化：某些時候服務會因爲用戶行爲造成請求無法及時處理從而導致雪崩，例如阿里的雙十一活動，若沒有提前增加機器預估流量則會造服務器壓力會驟然增大二掛掉。
（3）人爲因素：比如代碼中的路徑在某個時候出現bug
4 解決或緩解服務雪崩的方案
一般情況對於服務依賴的保護主要有3中解決方案：
（1）熔斷模式：這種模式主要是參考電路熔斷，如果一條線路電壓過高，保險絲會熔斷，防止火災。放到我們的系統中，如果某個目標服務調用慢或者有大量超時，此時，熔斷該服務的調用，對於後續調用請求，不在繼續調用目標服務，直接返回，快速釋放資源。如果目標服務情況好轉則恢復調用。
（2）隔離模式：這種模式就像對系統請求按類型劃分成一個個小島的一樣，當某個小島被火少光了，不會影響到其他的小島。例如可以對不同類型的請求使用線程池來資源隔離，每種類型的請求互不影響，如果一種類型的請求線程資源耗盡，則對後續的該類型請求直接返回，不再調用後續資源。這種模式使用場景非常多，例如將一個服務拆開，對於重要的服務使用單獨服務器來部署，再或者公司最近推廣的多中心。
（3）限流模式：上述的熔斷模式和隔離模式都屬於出錯後的容錯處理機制，而限流模式則可以稱爲預防模式。限流模式主要是提前對各個類型的請求設置最高的QPS閾值，若高於設置的閾值則對該請求直接返回，不再調用後續資源。這種模式不能解決服務依賴的問題，只能解決系統整體資源分配問題，因爲沒有被限流的請求依然有可能造成雪崩效應。
5 熔斷設計
在熔斷的設計主要參考了hystrix的做法。其中最重要的是三個模塊：熔斷請求判斷算法、熔斷恢復機制、熔斷報警
（1）熔斷請求判斷機制算法：使用無鎖循環隊列計數，每個熔斷器默認維護10個bucket，每1秒一個bucket，每個blucket記錄請求的成功、失敗、超時、拒絕的狀態，默認錯誤超過50%且10秒內超過20個請求進行中斷攔截。
（2）熔斷恢復：對於被熔斷的請求，每隔5s允許部分請求通過，若請求都是健康的（RT<250ms）則對請求健康恢復。
（3）熔斷報警：對於熔斷的請求打日誌，異常請求超過某些設定則報警
6 隔離設計
隔離的方式一般使用兩種
（1）線程池隔離模式：使用一個線程池來存儲當前的請求，線程池對請求作處理，設置任務返回處理超時時間，堆積的請求堆積入線程池隊列。這種方式需要爲每個依賴的服務申請線程池，有一定的資源消耗，好處是可以應對突發流量（流量洪峯來臨時，處理不完可將數據存儲到線程池隊裏慢慢處理）
（2）信號量隔離模式：使用一個原子計數器（或信號量）來記錄當前有多少個線程在運行，請求來先判斷計數器的數值，若超過設置的最大線程個數則丟棄改類型的新請求，若不超過則執行計數操作請求來計數器+1，請求返回計數器-1。這種方式是嚴格的控制線程且立即返回模式，無法應對突發流量（流量洪峯來臨時，處理的線程超過數量，其他的請求會直接返回，不繼續去請求依賴的服務）
7 超時機制設計
超時分兩種，一種是請求的等待超時，一種是請求運行超時。
等待超時：在任務入隊列時設置任務入隊列時間，並判斷隊頭的任務入隊列時間是否大於超時時間，超過則丟棄任務。
運行超時：直接可使用線程池提供的get方法
8 隔離與熔斷代碼實現
後續會放到github上
9 性能損耗測試
由於存在計數統計和線程切換等的開銷，所以對每個請求會有一定的性能損耗，測試結果表明在線程池隔離模式中，平均一個請求的損耗在0.5ms以內。
測試方法：順序請求，記錄業務運行時間和隔離器運行業務的時間，請求數量500次。
變量解釋：
單個請求耗時：爲業務的運行時間（使用Thread.sleep()模擬）;
隔離消耗=請求總用時-業務用時;
隔離評價消耗=隔離消耗/請求次數/
測試時間統計（單位ms）：
|
單個請求耗時 |
請求總用時 |
業務用時 |
隔離消耗 |
隔離平均消耗 |
|
1 |
586 |
510 |
76 |
0.152 |
|
5 |
2637 |
2514 |
124 |
0.248 |
|
10 |
5248 |
5136 |
112 |
0.024 |
|
50 |
25261 |
25111 |
150 |
0.3 |
|
100 |
50265 |
50130 |
135 |
0.27 |
|
200 |
100657 |
100284 |
373 |
0.746 |
10 參考
在設計和實現的過程中參考了一些現有的設計和一些文章：
1、Hystrix官方文檔：https://github.com/Netflix/Hystrix/wiki
2、Hystrix使用與分析：http://hot66hot.iteye.com/blog/2155036
3、Facebook文章：http://queue.acm.org/detail.cfm?id=2839461
4、Facebook文章：http://queue.acm.org/detail.cfm?id=2209336
4、分佈式服務容錯模式和實踐：http://www.atatech.org/articles/31559