微服務(wù)服務(wù)容錯架構(gòu)設(shè)計

微服務(wù)服務(wù)容錯架構(gòu)設(shè)計Microservices引子我們都知道軟件開發(fā)的中，不僅僅要解決正常的業(yè)務(wù)邏輯，更重要的是對異常狀態(tài)的處理，這關(guān)系到我們程序的穩(wěn)定性和容錯性，在引入我們的微服務(wù)后我們的錯誤處理機制又面臨了新的挑戰(zhàn)，如圖所示，微服務(wù)中，多個服務(wù)之間可能存在著依賴關(guān)系，而底層的服務(wù)可能被多個服務(wù)所依賴，從而一個服務(wù)的失效可能導(dǎo)致多個服務(wù)不可用，從而進一步導(dǎo)致整個系統(tǒng)的不可用，面對這個問題，選擇正確的服務(wù)容錯處理方案就顯得格外重要了，今天我們就來討論服務(wù)容錯的設(shè)計和響應(yīng)的幾種模式Dflpcnd?nc^A10TTireafeHysFxoomm國nd/「Mpmngo=fiin二一b「B「而515Th「申cfsDependency&口巳pendencyCDependencyDependencyHg咐出啊P1。丁It陽m蟲Dep&iHi&iKyF1ftThreadsDepftndancyHWThread?O?pend?nG/10Thnesds-D&l>en-cfen-cyT10Th心dmQ&p&ndfrticySBBireadsQep^nd^ncvR/WThorisCep?ndeficy□15Tnr&^dSDependencyE&ThreattD^pe^dencvQ9BireactsDepend&ntyd8Threads配"也沖0IQTtir^^d^D郵MdM甥L4ThreadsD^IMHddnevM3Thr悍郁s1UTM翊擊[^pendencyD—f1DependencyEDependencyFDependencyOependennyI□e-peniencyHDependencyQ設(shè)計原則我們再來思考一下，容錯在我們設(shè)計上需要的功能，容錯的處理并非一個通用的模式，所以在面對不同的場景的時候，我們就應(yīng)該在設(shè)計上避免底層不可用帶來的影響，讓依賴的服務(wù)的故障不影響用戶的正常體驗，比如搜索功能故障，可以暫時禁用，并給予友好提示，而不應(yīng)該因此造成整個系統(tǒng)的不可用.其次應(yīng)該同時讓系統(tǒng)能應(yīng)對這個錯誤，并具有恢復(fù)能力，比如故障的服務(wù)可能在一段時間后會恢復(fù)正常后，對應(yīng)的依賴服務(wù)應(yīng)有所感知并進行恢復(fù)經(jīng)典的容錯模式當然經(jīng)過多年的實踐，業(yè)界已經(jīng)存在了一些優(yōu)秀可靠的設(shè)計模式，下面簡單介紹一下，我們可以根據(jù)我們的場景選擇正確的模式超時重試超時這個模式是我們比較常見的，比如在HTTP請求中我們就會設(shè)置一下超時時間，超過一定時間后我們就后斷開連接，從而防止服務(wù)不可用導(dǎo)致請求一直阻塞，從而避免服務(wù)資源的長時間占用.重試這個模式一般和超時配合出現(xiàn)，一般使用在對下層服務(wù)強依賴的場景，否則不建議使用利用重試來解決網(wǎng)絡(luò)異常帶來的請求失敗的情況，超時次數(shù)不應(yīng)該太多，超時時間的時間也比較關(guān)鍵，不能太長最好是根據(jù)服務(wù)的正常響應(yīng)時間來定，否則可能會導(dǎo)致長時間無響應(yīng)，拖垮系統(tǒng)實現(xiàn)方式比較簡單，通過設(shè)置請求時間和記錄請求次數(shù)來判斷是否需要重試即可框架實現(xiàn)有Springretry?限流我們應(yīng)用的異常情況不僅僅是內(nèi)部原因弓I起的，每個應(yīng)用的處理請求的能力是有限的，如果外部流量過大也會導(dǎo)致我們的服務(wù)不可用這時候就需要限流了.常見的限流有控制并發(fā)數(shù)量和限制訪問速率.控制并發(fā)，屬于常用的限流方式，比如有1000個請求，但是同時我們只允許100個請求進行處理，而其他的請求可以直接返回不進行處理，這樣保證了我們的并發(fā)數(shù)和我們的設(shè)計的負載水平相一致.在實現(xiàn)中我們可以使用Java的信號量來控制進入的請求數(shù)量.控制速率控制訪問的流量，效果上也是一樣的，實現(xiàn)上有所區(qū)別，一般使用令牌桶算法實現(xiàn)，簡單來說就是每秒會有N個令牌放入桶中，并且桶的大小是固定的也就是我們要限制流量的大小，多余的令牌會丟棄，每個請求會消耗對于請求的字節(jié)大小的令牌，如果令牌不足了請求就會被丟棄，從而實現(xiàn)訪問控制.?艙壁隔離這個模式借鑒造船行業(yè)的經(jīng)驗，在造船業(yè)人們往往利用艙壁將不同的船艙隔離起來，這樣如果一個船艙破了進水，只損失一個船艙，其它船艙可以不受影響.**線程隔離**就是了這個模式的思想，在開發(fā)過程中我們對每個不同的服務(wù)分配不同的線程池,比如serviceA分配了10個serviceB分配了20個，如果serviceA的線程用完了對serviceB也不會有影響，并不用占用另一個的資源，如果沒有這種隔離,serviceA出現(xiàn)異常后就可能占用了其他服務(wù)的資源，從而影響整個系統(tǒng).?熔斷器熔斷器模式類似我們家里的電路保險絲，如果出現(xiàn)異常熔斷器會打開,所有的請求都會直接返回，而不會等待或阻塞.在我們的項目當中，如果服務(wù)不可用會導(dǎo)致大量的請求等待，阻塞重要的系統(tǒng)資源CPU內(nèi)存等，并進一步消耗資源使系統(tǒng)的其他服務(wù)也不可用，而熔斷器會對異常狀態(tài)直接返回，從而減少這種資源的浪費，同時如圖所示，熔斷器還可以有一種半開的狀態(tài)，當熔斷器打開后，會定時接受一部分請求來檢測系統(tǒng)是否恢復(fù)，然后正常就會關(guān)閉熔斷器，恢復(fù)正常使用了.CallsfaiIingfastAttemptResetTripBreakerHalf-OpenCallsfaiIingfastAttemptResetTripBreakerHalf-OpenClosed實際使用中我們經(jīng)常使用熔斷器模式來實現(xiàn)微服務(wù)的優(yōu)雅降級Netflix開源的組件[Hystrix](/p/hystrix)就很好的實現(xiàn)了這一模式,回退以上所有的模式都會出現(xiàn)異常，針對這些異常的處理方式也是一種模式叫做回退模式，回退的策略主要有-快速失敗直接拋出異常，適應(yīng)于非數(shù)據(jù)類的服務(wù)和非強依賴的服務(wù).-故障沉默返回空數(shù)據(jù)或者默認值，適用于可降級的場景，比如推薦系統(tǒng)直接返回空也