這篇文章我們來聊聊在微服務架構中，到底如何保證整套系統的高可用？
排除掉一些基礎設施的故障，比如說redis集群掛了，elasticsearch集群故障了，mysql宕機。
微服務架構本身最最核心的保障高可用的措施，就是兩點：
乙個是基於hystrix做資源隔離以及熔斷；
另乙個是做備用降級方案。
如果資源隔離和降級都做的很完善，那麼在雙11這種高併發場景下，也許可能會出現個別的服務故障，但是絕不會蔓延到整個系統全部宕機。
這裡大家如果忘了如何基於hystrix做資源隔離、熔斷以及降級的話，可以回顧一下之前的文章： 拜託！面試請不要再問我spring cloud底層原理
如上圖，核心服務a呼叫了核心服務b和c，在核心服務b響應過慢時，會導致核心服務a的某個執行緒池全部卡死。
當然這種情況在生產系統中，是絕對不被允許的，所以大家不要讓上述情況發生。
好，現在問題來了，在生產環境中，我們到底應該如何設定服務中每個hystrix執行緒池的大小？
假設你的服務a，每秒鐘會接收30個請求，同時會向服務b發起30個請求，然後每個請求的響應時長經驗值大概在200ms，那麼你的hystrix執行緒池需要多少個執行緒呢？
計算公式是：30（每秒請求數量） * 0.2（每個請求的處理秒數） + 4（給點緩衝buffer） = 10（執行緒數量）。
如果對上述公式存在疑問，不妨反過來推算一下，為什麼10個執行緒可以輕鬆抗住每秒30個請求？
乙個執行緒200毫秒可以執行完乙個請求，那麼乙個執行緒1秒可以執行5個請求，理論上，只要6個執行緒，每秒就可以執行30個請求。
也就是說，執行緒裡的10個執行緒中，就6個執行緒足以抗住每秒30個請求了。剩下4個執行緒都在玩兒，空閒著。
那為啥要多搞4個執行緒呢？很簡單，因為你要留一點buffer空間。
萬一在系統高峰期，系統效能略有下降，此時不少請求都耗費了300多毫秒才執行完，那麼乙個執行緒每秒只能處理3個請求了，10個執行緒剛剛好勉強可以hold住每秒30個請求。所以你必須多考慮留幾個執行緒。
老規矩，給大家來一張圖，直觀的感受一下整個過程。
執行緒數量ok了，那麼請求的超時時間設定為多少？答案是300毫秒。
為啥呢？很簡單啊，如果你的超時時間設定成了500毫秒，想想可能會有什麼後果？
考慮極端情況，如果服務b響應變慢，要500毫秒才響應，你乙個執行緒每秒最多只能處理2個請求了，10個執行緒只能處理20個請求。
而每秒是30個請求過來，結局會如何？
咱們回看一下第一張圖就知道了，大量的執行緒會全部卡死，來不及處理那麼多請求，最後使用者會刷不出來頁面。
還是有點不理解？再給你一張圖，讓你感受一下這個不合理的超時時間導致的問題！
如果你的執行緒池大小和超時時間沒有配合著設定好，很可能會導致服務b短暫的效能波動，瞬間導致服務a的執行緒池卡死，裡面的執行緒要卡頓一段時間才能繼續執行下乙個請求。
哪怕一段時間後，服務b的介面效能恢復到200毫秒以內了，服務a的執行緒池裡卡死的狀況也要好一會兒才能恢復過來。
你的超時時間設定的越不合理，比如設定的越長，設定到了1秒、2秒，那麼這種卡死的情況就需要越長的時間來恢復。
所以說，此時你的超時時間得設定成300毫秒，保證乙個請求300毫秒內執行不完，立馬超時返回。
這樣執行緒池裡的執行緒不會長時間卡死，可以有條不紊的處理多出來的請求，大不了就是300毫秒內處理不完立即超時返回，但是執行緒始終保持可以執行的狀態。
這樣當服務b的介面效能恢復到200毫秒以內後，服務a的執行緒池裡的執行緒很快就可以恢復。
這就是生產系統上的hystrix引數設定優化經驗，你需要考慮到各種引數應該如何設定。
否則的話，很可能會出現上文那樣的情況，用了高大上的spring cloud架構，結果跟黑盒子一樣，莫名其妙系統故障，各種卡死，宕機什麼的。
好了，我們繼續。如果現在這套系統每秒有6000請求，然後核心服務a一共部署了60臺機器，每台機器就是每秒會收到100個請求，那麼此時你的執行緒池需要多少個執行緒？
很簡單，10個執行緒抗30個請求，30個執行緒抗100請求，差不多了吧。
這個時候，你應該知道服務a的執行緒池呼叫服務b的執行緒池分配多少執行緒了吧？超時時間如何設定應該也知道了！
其實這個東西不是固定死的，但是你要知道他的計算方法。
根據服務的響應時間、系統高峰qps、有多少臺機器，來計算出來，執行緒池的大小以及超時時間！
設定完這些後，就應該要考慮服務降級的事了。
如果你的某個服務掛了，那麼你的hystrix會走熔斷器，然後就會降級，你需要考慮到各個服務的降級邏輯。
舉一些常見的例子：
具體用什麼降級策略，要根據業務來定，不是一成不變的。
最後總結一下，排除那些基礎設施的故障，你要玩兒微服務架構的話，需要保證兩點：
如何保障微服務安全
原文 securing microservices摘要 如何保護微服務，確保微服務的安全，作者從保護應用程式安全和保護容器的安全兩個方面進行了闡述，以下是譯文 實現乙個微服務很難。部署乙個微服務應用程式複雜性也很高。保護微服務的安全就更難更複雜。從 開始呢？腦海中首先出現的一些詞是身份驗證和授權 防...
如何實現微服務架構
一 技術選型 相對單體應用的交付，微服務應用交付要複雜得多，不僅需要開發框架支援，還需要一些自動化部署的工具，以及iaas paas或caas的支援。下面從開發和執行平台兩個維度考慮挑選技術選型 1 開發框架的選擇 可使用spring cloud作為微服務開發框架。首先，spring cloud具備...
如何支撐微服務架構落地
如今微服務如日中天，優勢和弊端也有各種描述，那麼我們是否應該採用微服務架構？如何規避微服務的弊端，放大微服務優勢？如何在先進性和實用性中作出平衡，順利落地？t.cn rkjfqlz 微服務 模組化開發 分布式計算 我認為微服務架構帶來了兩個好處。第乙個好處就是降低了系統的複雜度，第二個是提公升了我們...