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

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