在企業(yè)業(yè)務(wù)領(lǐng)域，錦禮是針對(duì)福利、營銷、激勵(lì)等員工采購場景的一站式解決方案，包含面向員工、會(huì)員等彈性激勵(lì)SAAS平臺(tái)。由于其直接面向公司全體員工，其服務(wù)的高可用尤其重要，本文將介紹錦禮商城大促前夕，通過混沌工程實(shí)戰(zhàn)演習(xí)，降低應(yīng)用的MTTR。
MTTR（平均恢復(fù)時(shí)間）是從產(chǎn)品或系統(tǒng)故障中恢復(fù)所需的平均時(shí)間。 這包括整個(gè)中斷時(shí)間——從系統(tǒng)或產(chǎn)品出現(xiàn)故障到其恢復(fù)完全運(yùn)行為止。
如何在混沌演練的場景中降低應(yīng)用的MTTR，必須需要根據(jù)監(jiān)控定位，然后人工進(jìn)行反饋進(jìn)行處理嗎？是否可以自動(dòng)化，是否有方案可以降低混沌演練過程中的影響？以此達(dá)到快速止血，進(jìn)一步提高系統(tǒng)的穩(wěn)定性。
本篇文章將根據(jù)一些思考和實(shí)踐來解答以上問題。
故障無處不在，而且無法避免。
我們將從宿主機(jī)重啟問題以及底層服務(wù)混沌演練的排查與舉措說起。
背景
【客戶端視角】：出現(xiàn)大量接口（包括提單）超時(shí)報(bào)錯(cuò)、可用率跳點(diǎn)，部分客戶命中，產(chǎn)生客訴。
通過定位發(fā)現(xiàn)大促備戰(zhàn)前期宿主機(jī)重啟及底層服務(wù)混沌演練原因，較長時(shí)間影響我側(cè)系統(tǒng)可用率及性能。尤其是核心接口的部署應(yīng)用，會(huì)大范圍的影響到多個(gè)接口的可用率，進(jìn)一步影響采購端客戶的體驗(yàn)問題。
特別在TOB領(lǐng)域，本身就存在大客戶的口碑效應(yīng)，如果恰好頭部客戶碰到該問題，那么極易被放大和激化。
臨時(shí)舉措
一方面協(xié)同運(yùn)維組確認(rèn)宿主機(jī)重啟未及時(shí)通知的情況，另一方面與底層服務(wù)提供者同步演練影響，建議其遵守演練原則最小化爆炸半徑，控制影響范圍，保證演練是可控的。
除了以上協(xié)同外部的情況外，我們內(nèi)部也產(chǎn)生了思考，首先情況故障本身就是不可控的，無論宿主機(jī)還是混沌演練，真實(shí)場景也是有概率發(fā)生的（并且已發(fā)生）。那么我們只能通過監(jiān)控定位，然后手動(dòng)摘除機(jī)器或者通知服務(wù)提供者處理嗎？是否可以自動(dòng)化，是否有方案可以降低影響？以此達(dá)到快速止血，進(jìn)一步提高系統(tǒng)的穩(wěn)定性。
長期方案——JSF中間件能力實(shí)踐
既然無法避免故障，那么就擁抱故障，通過一些技術(shù)手段來構(gòu)建獲取應(yīng)用故障的能力，從而保證應(yīng)用的高可用。
由于內(nèi)部的調(diào)用90+%為（JSF）RPC調(diào)用，所以我們還是把目光放到了JSF中間件的容錯(cuò)能力上，以下主要介紹通過JSF中間件的超時(shí)與重試、自適應(yīng)負(fù)載均衡、服務(wù)熔斷來進(jìn)行故障轉(zhuǎn)移的理論與實(shí)踐。
實(shí)踐是檢驗(yàn)真理的唯一標(biāo)準(zhǔn)。
關(guān)于超時(shí)和重試
實(shí)際開發(fā)過程中，相信大家也見過太多由于超時(shí)未設(shè)置、設(shè)置有誤導(dǎo)致的故障。當(dāng)超時(shí)未設(shè)置或者設(shè)置不合理，會(huì)導(dǎo)致請(qǐng)求響應(yīng)變慢，慢請(qǐng)求的不斷累計(jì)疊加，就會(huì)引起連鎖反應(yīng)，甚至產(chǎn)生應(yīng)用雪崩。
不僅我們自身的服務(wù)，還有外部的依賴服務(wù)，不僅HTTP服務(wù)，還是中間件服務(wù)，都應(yīng)該設(shè)置合理的超時(shí)重試策略，并且重視起來。
首先讀寫服務(wù)的超時(shí)重試策略也是大不相同的，讀服務(wù)天生適合重試（如設(shè)置合理超時(shí)時(shí)間后重試兩次），但是寫服務(wù)大多是不能重試的，不過如果均是冪等設(shè)計(jì)，也是可以的。
另外設(shè)置調(diào)用方的超時(shí)時(shí)間之前，需要先了解清楚依賴服務(wù)的TP99響應(yīng)時(shí)間是多少（如果依賴服務(wù)性能波動(dòng)大，也可以看TP95），調(diào)用方的超時(shí)時(shí)間可以在此基礎(chǔ)上加50%Buff。當(dāng)然服務(wù)的響應(yīng)時(shí)間并不是恒定的，在某些長尾條件下可能需要更多的計(jì)算時(shí)間，所以為了有足夠的時(shí)間等待這種長尾請(qǐng)求響應(yīng)，我們需要把超時(shí)設(shè)置足夠合理。
最后重試次數(shù)不宜太多（高并發(fā)時(shí)可能引發(fā)一系列問題（一般2次，最多3次），雖然重試次數(shù)越大，服務(wù)可用性越高，但是高并發(fā)情況下會(huì)導(dǎo)致多倍的請(qǐng)求流量，類似模擬DDOS攻擊，嚴(yán)重情況下甚至于加速故障的連鎖發(fā)生。因此超時(shí)重試最好是和熔斷、快速失敗等機(jī)制配合使用，效果更佳，這個(gè)后面會(huì)提到。
除了引入手段，重要的是驗(yàn)證手段的有效性。
模擬場景（后續(xù)另兩個(gè)手段也是用該場景）
方案：采用故障注入（50%機(jī)器網(wǎng)絡(luò)延遲3000-5000ms）的方式模擬類似場景，并驗(yàn)證。
機(jī)器部署如下：
壓測接口（QPS-300）及故障接口監(jiān)控Key值：
1、壓測接口：jdos_b2b2cplatform.B2b2cProductProviderImpl.queryProductBpMap
2、服務(wù)消費(fèi)：jdos_b2b2cplatform.ActivityConfigServiceRPCImpl.queryActivityConfig
3、服務(wù)提供：jdos_b2b2cshop.com.jd.ka.b2b2c.shop.service.impl.sdk.ActivityConfigServiceImpl.queryActivityConfig
【注意】網(wǎng)絡(luò)場景不支持如下情形:
1、應(yīng)用容器所在機(jī)房:xxx
2、物理機(jī)的內(nèi)核版本:xxx
正常情況（未注入故障）
注入故障——超時(shí)設(shè)置不合理情況下（超時(shí)2000ms，重試2）
注入故障——超時(shí)設(shè)置合理情況下（超時(shí)10ms，重試2）
該接口TP99在6ms，設(shè)置超時(shí)10ms，重試2。即：jsf:methodname="queryActivityConfig"timeout="10"retries=“2”/
超時(shí)重試小結(jié)
通過合理的超時(shí)重試，整體請(qǐng)求平穩(wěn)，重試后的故障轉(zhuǎn)移，大幅提升接口可用率。
超時(shí)重試補(bǔ)充
在接口維度拆分不合理的情況下，我們可以更細(xì)粒度的使用方法維度的超時(shí)重試配置，不過這里有一個(gè)注意項(xiàng)JSF當(dāng)前注解方式不支持方法維度的超時(shí)重試設(shè)置，僅支持接口維度，如已使用注解類，可進(jìn)行遷移XML方式進(jìn)行配置使用，
關(guān)于自適應(yīng)負(fù)載均衡
對(duì)于shortestresponse自適應(yīng)負(fù)載均衡設(shè)計(jì)目的是解決在 provider 節(jié)點(diǎn)能力不均的場景下，讓處理能力較弱的provider少接受些流量，不會(huì)因個(gè)別性能較差的 provider 影響到 consumer 整體調(diào)用的請(qǐng)求耗時(shí)和可用率。
能者多勞拙者閑，智者多憂愚者無所慮。
但是該策略下也是存在一些問題的：
- 流量的過度集中高性能實(shí)例，服務(wù)提供者的單機(jī)限流或成為瓶頸。
- response的時(shí)間長短有時(shí)也并不能代表機(jī)器的吞吐能力。
- 大多數(shù)的場景下，不同provider的response時(shí)長在沒有非常明顯的區(qū)別時(shí)，shortestresponse同random（隨機(jī)）。
現(xiàn)有的shortestresponse的實(shí)現(xiàn)機(jī)制，類似P2C（Power of Two Choice）算法，不過計(jì)算方式不是采用當(dāng)前正在處理的連接數(shù)，而是默認(rèn)隨機(jī)選擇兩個(gè)服務(wù)提供者參與最快響應(yīng)比較計(jì)算，即：統(tǒng)計(jì)請(qǐng)求每個(gè)provider的請(qǐng)求耗時(shí)、訪問量、異常量、請(qǐng)求并發(fā)數(shù)，比較平均響應(yīng)時(shí)間 * 當(dāng)前請(qǐng)求數(shù)，用于最快響應(yīng)負(fù)載計(jì)算。選取優(yōu)勝者來避免羊群效應(yīng)。以此自適應(yīng)的衡量 provider 端機(jī)器的吞吐能力，然后將流量盡可能分配到吞吐能力高的機(jī)器上，提高系統(tǒng)整體服務(wù)的性能。
<jsf:consumer id="activityConfigService"
interface="com.jd.ka.b2b2c.shop.sdk.service.ActivityConfigService"
alias="${jsf.activityConfigService.alias}" timeout = "3000" filter="jsfLogFilter,jsfSwitchFilter"
loadbalance="shortestresponse">
<jsf:method name="queryActivityConfig" timeout="10" retries="2"/>
</jsf:consumer>
注入故障（設(shè)置自適應(yīng)負(fù)載均衡）
自適應(yīng)負(fù)載均衡小結(jié)
通過引入自適應(yīng)負(fù)載均衡，從接口最初調(diào)用就開始了”能者多勞“模式，選舉出的機(jī)器承載著更高的流量，故障注入后，接口可用率短時(shí)間窗口消失，變成可用率跳點(diǎn)，進(jìn)一步保障了服務(wù)的高可用及性能。
關(guān)于服務(wù)熔斷
當(dāng)電路發(fā)生短路或嚴(yán)重過載時(shí)，熔斷器中的熔斷體將自動(dòng)熔斷，對(duì)電路進(jìn)行保護(hù)。避免對(duì)設(shè)備產(chǎn)生重大影響，甚至火災(zāi)。
服務(wù)熔斷是面向不穩(wěn)定服務(wù)場景的一種鏈路保護(hù)機(jī)制。
其背后的基本思想非常簡單，將受保護(hù)的函數(shù)調(diào)用包裝在熔斷對(duì)象中，該對(duì)象會(huì)監(jiān)視故障。當(dāng)調(diào)用鏈路的某個(gè)服務(wù)不可用或者響應(yīng)時(shí)間太長導(dǎo)致故障達(dá)到設(shè)定閾值時(shí)，會(huì)進(jìn)行服務(wù)熔斷，熔斷窗口內(nèi)不再有該節(jié)點(diǎn)服務(wù)的調(diào)用，以此來最大限度避免下游服務(wù)不穩(wěn)定對(duì)上游服務(wù)帶來的影響。
<!-- 服務(wù)熔斷策略配置 -->
<jsf:reduceCircuitBreakerStrategy id="demoReduceCircuitBreakerStrategy"
enable="true" <!-- 熔斷策略是否開啟 -->
rollingStatsTime="1000" <!-- 熔斷器指標(biāo)采樣滾動(dòng)窗口時(shí)長，單位 ms，默認(rèn) 5000ms -->
triggerOpenMinRequestCount="10" <!-- 單位時(shí)間內(nèi)觸發(fā)熔斷的最小訪問量，默認(rèn) 20 -->
triggerOpenErrorCount="0" <!-- 單位時(shí)間內(nèi)的請(qǐng)求異常數(shù)達(dá)到閥值，默認(rèn) 0，小于等于0 代表不通過異常數(shù)判斷是否開啟熔斷 -->
triggerOpenErrorPercentage="50" <!-- 單位時(shí)間內(nèi)的請(qǐng)求異常比例達(dá)到閥值，默認(rèn) 50，即 默認(rèn) 50% 錯(cuò)誤率 -->
<!-- triggerOpenSlowRT="0" 判定請(qǐng)求為慢調(diào)用的請(qǐng)求耗時(shí)，單位 ms，請(qǐng)求耗時(shí)超過 triggerOpenSlowRT 則認(rèn)為是慢調(diào)用 （默認(rèn)為 0，即默認(rèn)不判定）-->
<!-- triggerOpenSlowRequestPercentage="0" 采樣滾動(dòng)周期內(nèi)觸發(fā)熔斷的慢調(diào)用率（默認(rèn)為 0，即默認(rèn)不觸發(fā)慢調(diào)用熔斷 -->
openedDuration="10000" <!-- 熔斷開啟狀態(tài)持續(xù)時(shí)間，單位 ms，默認(rèn) 5000ms -->
halfOpenPassRequestPercentage="30" <!-- 半閉合狀態(tài)，單位時(shí)間內(nèi)放行流量百分比，默認(rèn) 40-->
halfOpenedDuration="3000" <!-- 半閉合狀態(tài)持續(xù)時(shí)間設(shè)置，需要大于等于 rollingStatsTime ，默認(rèn)為 rollingStatsTime -->
<!-- failBackType="FAIL_BACK_EXCEPTION" failBack策略， 取值：FAIL_BACK_EXCEPTION拋出異常、FAIL_BACK_NULL返回null、FAIL_BACK_CUSTOM配置自定義策略，配合 failBackRef 屬性 -->
<!-- failBackRef="ref" 如果 failBackStrategy 配置為 FAIL_BACK_CUSTOM 則必填，用戶自定義的failback策略com.jd.jsf.gd.circuitbreaker.failback.FailBack<Invocation> 接口實(shí)現(xiàn)類 -->
/>
<jsf:consumerid="activityConfigService"interface="com.jd.ka.b2b2c.shop.sdk.service.ActivityConfigService"
alias="${consumer.alias.com.jd.ka.b2b2c.shop.sdk.service.ActivityConfigService}" timeout="2000"check="false"
serialization="hessian"loadbalance="shortestresponse"
connCircuitBreakerStrategy="demoCircuitBreakerStrategy">
<jsf:methodname="queryActivityConfig"timeout="10"retries="2"/>
</jsf:consumer>
這里來了一個(gè)小插曲，由于JSF本身的心跳機(jī)制，檢測故障后，自動(dòng)（30s檢測一次，三次均異常則摘除）摘除了對(duì)應(yīng)的機(jī)器，我們自身設(shè)置的熔斷機(jī)制并不明顯，因此重新設(shè)置故障（網(wǎng)絡(luò)延遲800-1500ms）進(jìn)行重新演練。
注入故障（服務(wù)熔斷）
服務(wù)熔斷小結(jié)
從可用率上看，確實(shí)在窗口內(nèi)會(huì)關(guān)閉對(duì)異常機(jī)器節(jié)點(diǎn)的訪問，不過由于并沒有實(shí)現(xiàn)failback策略以及熔斷開啟窗口時(shí)間較短，可用率還是會(huì)在窗口打開后，直接返回了調(diào)用失敗信息，因此影響了可用率。所以相比于熔斷后失敗，最好的方式是配合服務(wù)降級(jí)能力，通過調(diào)用預(yù)先設(shè)置好的服務(wù)降級(jí)邏輯，以降級(jí)邏輯的結(jié)果作為最終調(diào)用結(jié)果，以更優(yōu)雅的返回給服務(wù)調(diào)用方。
服務(wù)熔斷補(bǔ)充
- 集團(tuán)已搭建了統(tǒng)一的熔斷組件，并且在泰山上建立了對(duì)應(yīng)的平臺(tái)能力。如果團(tuán)隊(duì)需要引入熔斷能力，可以直接接入使用，避免重復(fù)建設(shè)。
一種機(jī)制可能會(huì)擊敗另一種機(jī)制。
其實(shí)為了增強(qiáng)系統(tǒng)的彈性和魯棒性，以應(yīng)對(duì)各種故障和不可預(yù)測的情況，在分布式系統(tǒng)中，通常會(huì)設(shè)計(jì)成能夠部分故障（partially fail），即使不能滿足全量客戶，但是仍然可以向某些客戶提供服務(wù)。但是熔斷旨在將部分故障轉(zhuǎn)化為完全故障，以此防止故障進(jìn)一步擴(kuò)散。因此服務(wù)熔斷和分布式系統(tǒng)的設(shè)計(jì)原則中存在一種相互制約的關(guān)系，所以，在使用前，要進(jìn)行仔細(xì)的分析和思考，以及后續(xù)的調(diào)優(yōu)。
結(jié)論
能力只是手段，穩(wěn)定性才是目的。
無論采用什么手段，進(jìn)行穩(wěn)定性建設(shè)，我們需要時(shí)刻思考的是如何在業(yè)務(wù)需求和穩(wěn)定性建設(shè)中尋找平衡，以建設(shè)支持業(yè)務(wù)長期增長的高可用架構(gòu)。
本次就寫到這，如有問題，歡迎交流。希望文章中的一些經(jīng)驗(yàn)，給大家?guī)硪恍┦斋@，或者說，大家不妨思考一下你們會(huì)采用何種技術(shù)方案和手段來解決類似問題。歡迎留言交流，也希望能和更多志同道合的伙伴溝通交流。
最后老樣子，歡迎大家一鍵三連點(diǎn)贊收藏+關(guān)注。
參考文檔
The power of two random choices ： https://brooker.co.za/blog/2012/01/17/two-random.html
負(fù)載均衡：https://cn.dubbo.apache.org/zh-cn/overview/core-features/load-balance/#shortestresponse
作者：京東零售 李孟冬文章來源：http://www.zghlxwxcb.cn/news/detail-496090.html
來源：京東云開發(fā)者社區(qū)文章來源地址http://www.zghlxwxcb.cn/news/detail-496090.html
到了這里，關(guān)于混沌演練狀態(tài)下，如何降低應(yīng)用的MTTR（平均恢復(fù)時(shí)間） | 京東云技術(shù)團(tuán)隊(duì)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
