2018-5-8 博博
下圖所示線上故障,你的產(chǎn)品線是否曾經(jīng)中招或者正在中招?同樣的問題總是在不同產(chǎn)品線甚至相同產(chǎn)品線不同系統(tǒng)重復(fù)上演,這些故障有個(gè)共同特點(diǎn),就是線下常規(guī)測(cè)試很難發(fā)現(xiàn),即便線上驗(yàn)證也不易暴露。但是總是在“無變更安全日”悄然爆發(fā),嚴(yán)重影響系統(tǒng)穩(wěn)定性指標(biāo)。
面對(duì)這些看似并無規(guī)律的故障,Case by case的分析無疑是低效而且不系統(tǒng)的,無法全面掃除穩(wěn)定性測(cè)試盲區(qū),也無法阻止悲劇在其他產(chǎn)品線再一次發(fā)生。為此筆者把問題聚類,根據(jù)問題特點(diǎn)尋求通用測(cè)試手段,并在產(chǎn)品線各個(gè)系統(tǒng)落地驗(yàn)證,效果顯著,現(xiàn)把個(gè)人經(jīng)驗(yàn)融合前輩經(jīng)驗(yàn)產(chǎn)出,供大家參考,有則改之,無則加勉。
首先,為了讓大家更好了解這些故障對(duì)業(yè)務(wù)系統(tǒng)穩(wěn)定性的影響程度,需了解下何為穩(wěn)定性,衡量指標(biāo)就是系統(tǒng)可用性= MTBF / (MTBF + MTTR) , 其中MTBF, Mean Time Between Failure, 是平均無故障時(shí)間, 而MTTR, Mean Time To Repair,是平均修復(fù)時(shí)間,參考下表更加直觀。
從如上數(shù)字看,5個(gè)9的故障時(shí)間月故障時(shí)間只有25s,3個(gè)9的可用性月故障時(shí)間也只有40多分鐘,回想我們平時(shí)處理過的線上問題,開發(fā)和測(cè)試質(zhì)量把控不過關(guān),然后再把期望寄托在半人肉處理故障的運(yùn)維團(tuán)隊(duì),顯然無法達(dá)到線上產(chǎn)品穩(wěn)定性要求。
為了保障系統(tǒng)穩(wěn)定性,提前消除風(fēng)險(xiǎn)勢(shì)在必行。產(chǎn)品質(zhì)量風(fēng)險(xiǎn)類型很多,產(chǎn)品研發(fā)流程的各個(gè)階段都可能引入和存在風(fēng)險(xiǎn),每個(gè)階段的風(fēng)險(xiǎn)的類型和發(fā)現(xiàn)手段都不盡相同,為此產(chǎn)出如下風(fēng)險(xiǎn)模型。按照風(fēng)險(xiǎn)發(fā)生的階段及原因,風(fēng)險(xiǎn)類型可分為:架構(gòu)設(shè)計(jì)風(fēng)險(xiǎn)、編碼風(fēng)險(xiǎn)、安全風(fēng)險(xiǎn)、流程規(guī)范風(fēng)險(xiǎn)、運(yùn)維風(fēng)險(xiǎn)和監(jiān)控風(fēng)險(xiǎn)。
本文主要講解架構(gòu)設(shè)計(jì)風(fēng)險(xiǎn),接下來介紹的每個(gè)風(fēng)險(xiǎn)都會(huì)說明風(fēng)險(xiǎn)定義,影響,以及通過什么技術(shù)手段來進(jìn)行風(fēng)險(xiǎn)識(shí)別,最后總結(jié)風(fēng)險(xiǎn)消除方案。另外每個(gè)風(fēng)險(xiǎn)都會(huì)有具體的例子來講解,這些例子都是發(fā)生在百度內(nèi)部的真實(shí)故事。
架構(gòu)設(shè)計(jì)風(fēng)險(xiǎn)是QA最容易忽略的,該類風(fēng)險(xiǎn)出現(xiàn)在研發(fā)階段的早期,我們都知道缺陷越早的暴露后期研發(fā)的維護(hù)成本越低,而且一旦架構(gòu)設(shè)計(jì)上出現(xiàn)了問題,影響面是涉及整個(gè)模塊甚至系統(tǒng)的,修復(fù)代價(jià)必然非常高,因此對(duì)于架構(gòu)設(shè)計(jì)的風(fēng)險(xiǎn)更要提前了解和避免。
根據(jù)既往經(jīng)驗(yàn),架構(gòu)設(shè)計(jì)風(fēng)險(xiǎn)大概可以分為以下幾個(gè)維度:交互、依賴、耦合。
交互類常見風(fēng)險(xiǎn):重復(fù)交互、高頻交互、冗余/無用交互、接口不可重用、超時(shí)重試設(shè)置不合理、IP直連、跨機(jī)房等。
依賴類常見風(fēng)險(xiǎn):不合理強(qiáng)弱依賴、無效依賴、忽略第三方依賴、緩存依賴失效等。
耦合類常見風(fēng)險(xiǎn):架構(gòu)耦合不合理、緩存耦合不合理等。
2、風(fēng)險(xiǎn)影響
重復(fù)交互增加接口耗時(shí),降低接口性能,當(dāng)重復(fù)的是跨機(jī)房交互會(huì)使得性能急劇下降影響系統(tǒng)穩(wěn)定性,增加對(duì)下游服務(wù)的壓力(模塊壓力增加一倍,下游服務(wù)壓力增加幾倍)。
3、風(fēng)險(xiǎn)識(shí)別
如果兩個(gè)交互具有完全相同的請(qǐng)求服務(wù)對(duì)象(尤其是mysql、redis、memcache這類數(shù)據(jù)存儲(chǔ)服務(wù))、請(qǐng)求數(shù)據(jù)、返回?cái)?shù)據(jù),那么這兩個(gè)交互就判定為重復(fù)交互;對(duì)于獲取不到交互數(shù)據(jù)時(shí)也可以通過數(shù)據(jù)包size進(jìn)行初判。這里可以借助開源trace系統(tǒng),采集業(yè)務(wù)測(cè)試時(shí)的調(diào)用鏈信息,根據(jù)上面的判斷規(guī)則進(jìn)行風(fēng)險(xiǎn)自動(dòng)識(shí)別。
4、風(fēng)險(xiǎn)消除
在對(duì)實(shí)時(shí)性要求可控的前提下,將第一次查詢信息緩存下來。
真實(shí)案例一:系統(tǒng)間重復(fù)交互。11次重復(fù)請(qǐng)求session,對(duì)于前端一次請(qǐng)求就要對(duì)session模塊產(chǎn)生幾十倍的流量沖擊,所有這些交互都是完全重復(fù)的,極大的降低的了接口性能和session的負(fù)載能力。
真實(shí)案例二:mysql/redis重復(fù)交互。mysql/redis作為系統(tǒng)中性能瓶頸,這樣的重復(fù)請(qǐng)求無疑加速了其性能瓶頸的到達(dá)。
1、風(fēng)險(xiǎn)定義
一次用戶發(fā)起的請(qǐng)求,如果在模塊之間的交互次數(shù)完全依賴于后端返回的數(shù)據(jù)條數(shù),會(huì)給下游造成極大壓力的同時(shí),也降低了系統(tǒng)的穩(wěn)定性。相同業(yè)務(wù)請(qǐng)求的模塊交互次數(shù)多少不一,原因通常是代碼中循環(huán)操作內(nèi)部存在網(wǎng)絡(luò)交互,總交互次數(shù)受到循環(huán)迭代的次數(shù)影響。這樣的情況在模塊上線初期,可能因?yàn)閿?shù)據(jù)量比較小、pv比較小很容易被人忽視,當(dāng)某天上線一些大數(shù)據(jù)、大客戶,將會(huì)給予致命一擊。
2、風(fēng)險(xiǎn)影響
循環(huán)請(qǐng)求次數(shù)過多會(huì)導(dǎo)致下游壓力倍增(前端pv增加一倍,后端pv增加幾十倍),接口性能不穩(wěn)定,降低系統(tǒng)處理能力。系統(tǒng)穩(wěn)定性完全依賴于數(shù)據(jù)的代碼邏輯非常脆弱,當(dāng)遇到某一個(gè)大數(shù)據(jù)時(shí)將會(huì)出現(xiàn)模塊假死、系統(tǒng)雪崩、功能失敗。
3、風(fēng)險(xiǎn)識(shí)別
基于上游傳來的數(shù)據(jù)或某個(gè)子請(qǐng)求返回的數(shù)據(jù)量(通常是一個(gè)數(shù)組),針對(duì)每個(gè)數(shù)組元素進(jìn)行網(wǎng)絡(luò)請(qǐng)求,遍歷并沒有錯(cuò),但是要對(duì)這個(gè)遍歷的數(shù)組元素個(gè)數(shù)有限制,否則循環(huán)遍歷的次數(shù)就完全依賴于數(shù)據(jù)。這里也可以借助開源trace系統(tǒng),采集業(yè)務(wù)測(cè)試時(shí)的調(diào)用鏈信息,根據(jù)上面的判斷規(guī)則進(jìn)行風(fēng)險(xiǎn)自動(dòng)識(shí)別。
4、風(fēng)險(xiǎn)消除
數(shù)據(jù)量要可控,結(jié)合產(chǎn)品業(yè)務(wù)需求,比如請(qǐng)求返回結(jié)果要有上限;批量請(qǐng)求替代逐個(gè)請(qǐng)求。
真實(shí)案例:查詢某商戶物料詳情,當(dāng)該商戶擁有大量物料,就出現(xiàn)了如下場(chǎng)景,用戶的一次查詢就造成服務(wù)與db之間156次交互,那該接口的性能就可想而知了,平均耗時(shí)都在3s+,用戶體驗(yàn)極差。
1、風(fēng)險(xiǎn)定義
交互依賴的數(shù)據(jù)已出現(xiàn)異常,還繼續(xù)執(zhí)行后續(xù)交互,使得后續(xù)的交互是沒有任何意義的冗余交互。這些依賴的數(shù)據(jù),可能是上游傳遞而來,也可能是與下游模塊請(qǐng)求得來。
2、風(fēng)險(xiǎn)影響
冗余交互會(huì)占用系統(tǒng)資源,降低接口性能,從而影響系統(tǒng)穩(wěn)定性和性能。
3、風(fēng)險(xiǎn)識(shí)別
如果交互A依賴數(shù)據(jù)B(比如交互A的請(qǐng)求數(shù)據(jù)中需要傳入B),在B異常(比如數(shù)據(jù)為空、null、false等)情況下,還是發(fā)生了交互A,那么就認(rèn)為A是冗余交互;如果操作A依賴于操作B的成功執(zhí)行,當(dāng)B異常時(shí),還是發(fā)生了操作A,那么A也認(rèn)為是冗余交互??梢越柚_源trace系統(tǒng),采集業(yè)務(wù)測(cè)試時(shí)的調(diào)用鏈信息,根據(jù)上面的判斷規(guī)則進(jìn)行風(fēng)險(xiǎn)自動(dòng)識(shí)別。
4、風(fēng)險(xiǎn)消除
代碼中增加異常邏輯判斷:當(dāng)交互依賴的數(shù)據(jù)異常時(shí)不進(jìn)行該交互。
真實(shí)案例:如下調(diào)用鏈正常場(chǎng)景是先查詢團(tuán)單list,然后用團(tuán)單list去查詢每個(gè)團(tuán)單的優(yōu)惠。但是當(dāng)查詢團(tuán)單列表為空時(shí),就沒有必要再調(diào)用marketing查詢團(tuán)單的優(yōu)惠信息了,應(yīng)該立即返回錯(cuò)誤碼。這里增加無效交互無疑降低了接口性能。
1、風(fēng)險(xiǎn)定義
相同請(qǐng)求發(fā)給模塊再次處理,不能保證結(jié)果一致,符合預(yù)期。
2、風(fēng)險(xiǎn)識(shí)別
相同請(qǐng)求,模塊返回結(jié)果不一致亦或重復(fù)寫操作產(chǎn)生臟數(shù)據(jù)。這里可以利用錄制工具,重放請(qǐng)求,驗(yàn)證結(jié)果正確性。
3、風(fēng)險(xiǎn)消除
對(duì)于防重入可總結(jié)三點(diǎn),前端加入防重復(fù)點(diǎn)擊設(shè)置,接口層加入鎖機(jī)制,db層需要加入唯一鍵設(shè)置。
真實(shí)案例
在商家會(huì)員卡充值購買的流程中,nmq故障情況下,購買結(jié)果頁顯示充值失敗,但是卡中余額卻一直在直線增加,原因是充值接口沒有做到可重入,這個(gè)case幸好在線下及時(shí)發(fā)現(xiàn),否則后果不堪設(shè)想。
商家會(huì)員卡涉及到的購買流程如右下圖所示:
用戶提交訂單并且錢包處理完成后,錢包回調(diào)交易模塊的payresult接口,交易模塊驗(yàn)證通過之后,會(huì)調(diào)用商家會(huì)員卡的rechargemoney接口給商家會(huì)員卡充值。為了提高充值接口的可用性,與交易模塊有個(gè)約定了一個(gè)機(jī)制:若調(diào)用rechargemoney返回的errno不為0 ,則投入nmq重試三分鐘,三分鐘之內(nèi)的重試均沒有成功,才觸發(fā)自動(dòng)退款。商家會(huì)員卡模塊的充值接口rechargemoney的流程圖如下圖所示:
在rechargemoney接口處理過程中,有一個(gè)防頻繁重入的判定redis鎖過程,expireTime設(shè)置時(shí)間為10s,10s內(nèi)會(huì)攔截過來的重復(fù)請(qǐng)求,直接返回。
上述過程可以看到,前端是有無限重試策略的,因此可以認(rèn)為前端無防重入,那么看接口層鎖機(jī)制,重試時(shí)間3min明顯大于鎖有效時(shí)間10s,因此相同請(qǐng)求10s后鎖機(jī)制也失效,再看db層,插入order_id和其他營銷信息,數(shù)據(jù)庫中并沒有設(shè)置order_id為唯一鍵,因此該接口徹底失守,沒有做到可重入,相同訂單可以重復(fù)插入成功,從而導(dǎo)致業(yè)務(wù)表現(xiàn)為同一訂單多次重復(fù)充值。
對(duì)于該案例,改進(jìn)方案是首先將鎖有效時(shí)間設(shè)置大于一切來源的重試時(shí)間,其次在db充值記錄表中將orderid設(shè)置為主鍵,雙重保護(hù)該接口做到可重入。
1、風(fēng)險(xiǎn)定義
顧名思義,就是超時(shí)并沒有根據(jù)系統(tǒng)真實(shí)表現(xiàn)科學(xué)的設(shè)置。
2、風(fēng)險(xiǎn)影響
就像下圖化學(xué)反應(yīng)一樣,不合理的超時(shí)實(shí)際設(shè)置并不會(huì)產(chǎn)生真正影響,但是遇到網(wǎng)絡(luò)故障,依賴超時(shí)時(shí),后果不堪設(shè)想。
模塊交互必設(shè)超時(shí),這是基本要求,但是超時(shí)設(shè)置過長、過短可能會(huì)適得其反。不合理超時(shí)設(shè)置主要表現(xiàn)為①交互超時(shí)時(shí)間設(shè)置過長,比如5s甚至10s的超時(shí)②下游超時(shí)時(shí)間大于上游超時(shí)時(shí)間。
交互超時(shí)重試時(shí)間過長,在下游偶爾出現(xiàn)網(wǎng)絡(luò)抖動(dòng)時(shí)連接被hang住,接口耗時(shí)增加,并且降級(jí)模塊處理能力。下游超時(shí)>上游超時(shí),上游超時(shí)后斷開連接引發(fā)重試,下游還在繼續(xù)上次運(yùn)算(此時(shí)已經(jīng)沒有意義),下游負(fù)載增加N倍(取決于重試次數(shù)設(shè)置和發(fā)生重試的層數(shù)),使得系統(tǒng)性能急劇下降甚至雪崩。
3、風(fēng)險(xiǎn)識(shí)別
①超時(shí)時(shí)間設(shè)置過長(比如數(shù)據(jù)庫connect超時(shí)1s,模塊讀寫超時(shí)5s)
②下游超時(shí)時(shí)間大于上游超時(shí)時(shí)間。
4、風(fēng)險(xiǎn)消除
從系統(tǒng)整體考慮,并且結(jié)合重試和本模塊計(jì)算時(shí)間的影響。下游超時(shí)<上游超時(shí);超時(shí)時(shí)間不宜過長,根據(jù)下游接口性能設(shè)置;對(duì)于弱依賴的服務(wù)交互,超時(shí)時(shí)間更不能過長,以免弱依賴阻塞主流程。
真實(shí)案例:如下圖,該接口調(diào)用redis超時(shí)時(shí)間超過2s,然而Redis性能極好,單線程阻塞性server,這種長耗時(shí)會(huì)阻塞其他請(qǐng)求,很容易引起系統(tǒng)雪崩,應(yīng)該把redis連接超時(shí)時(shí)間修改適當(dāng)小。
1、風(fēng)險(xiǎn)定義
顧名思義,就是重試并沒有根據(jù)系統(tǒng)真實(shí)表現(xiàn)科學(xué)的設(shè)置。
2、風(fēng)險(xiǎn)影響
任何網(wǎng)絡(luò)交互都可能失敗,為了保證最終交互成功,通常交互失敗/超時(shí)、數(shù)據(jù)錯(cuò)誤后再次與該模塊交互,即發(fā)生了重試。重試的次數(shù)設(shè)置不當(dāng),輕者交互成功率不達(dá)標(biāo),業(yè)務(wù)失敗率增高,嚴(yán)重者引發(fā)系統(tǒng)雪崩。
3、風(fēng)險(xiǎn)識(shí)別
查看框架配置文件中重試次數(shù)配置,是否簡單粗暴的經(jīng)驗(yàn)值設(shè)定重試次數(shù),比如一律重試3次,查看代碼中邏輯控制的重試限制(這種很隱蔽)。
4、風(fēng)險(xiǎn)消除
相對(duì)于固定的重試序列,隨機(jī)重試序列也可能給系統(tǒng)帶來風(fēng)險(xiǎn),例如可能會(huì)降低下游模塊的cache命中率,降低系統(tǒng)性能,甚至引起雪崩。
評(píng)估重試機(jī)制:
1) 真的需要在每一層都努力重試嗎?
2) 真的需要這么多次重試嗎?
3) 真的需要在連接,寫,讀這三者失敗后都重試嗎?
按照業(yè)務(wù)需求和模塊性能設(shè)置重試次數(shù)
弱依賴不用重試也可以
下游模塊性能好,基本不會(huì)超時(shí),也可以不重試
大部分情況下,重試次數(shù)為1已經(jīng)足夠
真實(shí)案例
如圖為某產(chǎn)品線的架構(gòu),整個(gè)系統(tǒng)中,上游模塊對(duì)下游模塊所有的交互,重試次數(shù)都是設(shè)成3次,交互失敗包括連接失敗,寫失敗,讀失敗這三種情形。如果是寫和讀失敗,那么要關(guān)閉當(dāng)前連接,再重新發(fā)起連接。
如果一臺(tái)bs假死,到該bs的請(qǐng)求會(huì)超時(shí)。(注意區(qū)分模塊假死和真死,假死情況下,模塊端口打開,能夠接收上游連接,但是由于各種原因(如連接隊(duì)列滿,工作線程耗盡,陷入死循環(huán)等),不會(huì)返回任何應(yīng)答,上游模塊必須等待超時(shí)才知道失敗,連接超時(shí),寫超時(shí)和讀超時(shí)都有可能。而在真死情況下,模塊端口關(guān)閉,或者干脆程序退出,上游模塊連接它會(huì)很快得到失敗返回碼,這個(gè)返回碼由下游模塊的操作系統(tǒng)協(xié)議棧返回的,如ECONNREFUSED錯(cuò)誤碼代表端口不存在,連接被拒絕。)
那么as有1/3的概率需要重試,as重試的過程中,ui可能早就認(rèn)為as已經(jīng)超時(shí)了,所以u(píng)i也開始重試,ui重試的過程中,webserver可能認(rèn)為ui已經(jīng)超時(shí)了,所以webserver也開始重試……就這樣,整個(gè)系統(tǒng)的負(fù)載急劇增加,到達(dá)bs的qps會(huì)是平時(shí)的27倍,直到系統(tǒng)崩潰為止。
1、風(fēng)險(xiǎn)定義
A,B兩個(gè)系統(tǒng)交互,B系統(tǒng)分布式部署,A-B連接是通過配置B系統(tǒng)所有IP方式。
2、風(fēng)險(xiǎn)影響
當(dāng)B系統(tǒng)分布式服務(wù)中某一臺(tái)掛掉時(shí),不能做到failover,導(dǎo)致故障影響擴(kuò)大。
3、風(fēng)險(xiǎn)消除
通過bns或者組的方式進(jìn)行連接。
真實(shí)案例
某產(chǎn)品線依賴服務(wù)redis調(diào)用均采用ip列表的方式,如果redis proxy出現(xiàn)單機(jī)故障,需要人工介入進(jìn)行切流量止損。單機(jī)發(fā)單重啟修復(fù)周期有時(shí)會(huì)達(dá)小時(shí)級(jí)別,因此線上服務(wù)在故障期間會(huì)長時(shí)間處于切流量狀態(tài),高峰期單機(jī)房容量會(huì)存在風(fēng)險(xiǎn)。如同時(shí)有其他機(jī)房服務(wù)異常,則無法執(zhí)行既定預(yù)案止損。并且如想下掉故障proxy,只能采用發(fā)上線單修改線上配置的方式。止損操作復(fù)雜,周期長,效率低下,具體case如下:
(1)用戶中心redisproxy單機(jī)故障,人工切流量止損,恢復(fù)服務(wù)花費(fèi)2小時(shí),期間線上處于切流量狀態(tài)。
(2)商品中心redis proxy單機(jī)故障,會(huì)存在扣除庫存失敗的風(fēng)險(xiǎn)。恢復(fù)服務(wù)花費(fèi)半小時(shí),后續(xù)又再次發(fā)生宕機(jī),發(fā)單下掉故障proxy。
如上對(duì)應(yīng)前面講的故障時(shí)間,該服務(wù)sla月可用性已不足3個(gè)9。
1、風(fēng)險(xiǎn)定義
交互的兩個(gè)模塊分別部署在不同機(jī)房。
2、風(fēng)險(xiǎn)影響
跨機(jī)房交互由于存在網(wǎng)絡(luò)延時(shí),嚴(yán)重影響接口性能、請(qǐng)求成功率,極大的降低了系統(tǒng)穩(wěn)定性。
3、風(fēng)險(xiǎn)識(shí)別
①配置錯(cuò)誤(ODP框架)ral-service中配置的服務(wù)后端IP的Tag不能為空(在ral中,會(huì)將Tag為空的也認(rèn)為是本機(jī)房)②上游傳入idc錯(cuò)誤,Idc是完全匹配,nj和nj02就不相同,因此如果上游傳入nj02,當(dāng)前模塊的idc是nj,就會(huì)找不到對(duì)應(yīng)的Tag而只能使用default。
4、風(fēng)險(xiǎn)消除
主要關(guān)注配置是否合理,由于線上配置很難在線下驗(yàn)證正確性,肉眼排查難免遺漏,因此可通過線上機(jī)房流量切換演練驗(yàn)證。
1、風(fēng)險(xiǎn)定義
所謂強(qiáng)依賴就是,請(qǐng)求鏈路中某個(gè)服務(wù)失敗/結(jié)果異常/無結(jié)果后,核心邏輯必失敗,否則就認(rèn)為是弱依賴。不合理的強(qiáng)弱依賴有兩類,本應(yīng)該是弱依賴的設(shè)置為強(qiáng)依賴,本應(yīng)該是強(qiáng)依賴的設(shè)置為弱依賴。
2、風(fēng)險(xiǎn)影響
系統(tǒng)穩(wěn)定性取決于調(diào)用鏈中所有依賴穩(wěn)定性最差的依賴,如果將穩(wěn)定性較差的服務(wù)作為強(qiáng)依賴將嚴(yán)重影響穩(wěn)定性
3、風(fēng)險(xiǎn)識(shí)別
強(qiáng)弱依賴的合理性是需要結(jié)合業(yè)務(wù)判斷的,如果業(yè)務(wù)返回結(jié)果不可或缺該依賴,那么就該設(shè)置強(qiáng)依賴;如何判斷該依賴是否為強(qiáng)依賴可以通過故障模擬驗(yàn)證,如果模擬該依賴異常時(shí)導(dǎo)致調(diào)用異常,則判斷其為強(qiáng)依賴。
4、風(fēng)險(xiǎn)消除
①調(diào)整不合理的強(qiáng)弱依賴關(guān)系,將業(yè)務(wù)非強(qiáng)依賴服務(wù)降級(jí);②通過系統(tǒng)優(yōu)化及運(yùn)維優(yōu)化等手段提高強(qiáng)依賴的穩(wěn)定性。③對(duì)強(qiáng)依賴結(jié)果進(jìn)行全面校驗(yàn),保證強(qiáng)依賴故障能夠及時(shí)被發(fā)現(xiàn)。
真實(shí)案例
用戶下單請(qǐng)求到trade模塊,是通過消息隊(duì)列nmq保證下單后的商戶通知功能,通知商戶是借助公共服務(wù)云推送,這里云推送被實(shí)現(xiàn)成了強(qiáng)依賴,也就是當(dāng)云推送如果失敗,返回給本次請(qǐng)求失敗。
某次下單高峰期時(shí),云推送出現(xiàn)故障,無法給ios用戶推送消息,nmq收到請(qǐng)求失敗后,會(huì)持續(xù)不斷的重發(fā),nmq的通道堵塞之后也影響了trade模塊向nmq的請(qǐng)求故障不斷往上層蔓延,最后用戶無法下單。
對(duì)于如上案例,工程師最后去掉對(duì)云推送強(qiáng)依賴代碼,服務(wù)才慢慢恢復(fù),但已造成非常大的損失。
1、風(fēng)險(xiǎn)定義
服務(wù)啟動(dòng)流程中與該依賴建立了連接,但是整個(gè)邏輯處理過程中無需依賴該服務(wù),無任何業(yè)務(wù)關(guān)聯(lián)性。
2、風(fēng)險(xiǎn)影響
其實(shí)該風(fēng)險(xiǎn)是不合理依賴的一個(gè)特例,無業(yè)務(wù)關(guān)聯(lián)性的依賴應(yīng)該及時(shí)去除,否則會(huì)影響整體服務(wù)穩(wěn)定性。
3、風(fēng)險(xiǎn)識(shí)別
與依賴服務(wù)只有一次鏈接交互,無其他交互,就可以初步判斷該依賴為無效依賴,為了準(zhǔn)確評(píng)估可再結(jié)合代碼排查。
真實(shí)案例
某產(chǎn)品線由于配置管理較亂,有個(gè)服務(wù)每次啟動(dòng)都會(huì)判斷多個(gè)與業(yè)務(wù)完全不依賴的服務(wù)啟動(dòng)情況,這幾個(gè)依賴服務(wù)處于無人維護(hù)狀態(tài),非常不穩(wěn)定,從而導(dǎo)致該服務(wù)啟動(dòng)失敗率非常高。
1、風(fēng)險(xiǎn)定義
請(qǐng)求的完成,需要依賴產(chǎn)品外的其他服務(wù),都稱之為第三方(tp)依賴,按照公司又分為公司外第三方,比如糯米酒店依賴攜程服務(wù);公司內(nèi)第三方,比如passport相對(duì)于手百。
2、風(fēng)險(xiǎn)影響
第三方服務(wù)的性能,正確性,穩(wěn)定性直接影響自身服務(wù),尤其是第三方強(qiáng)依賴,當(dāng)?shù)谌揭蕾嚦霈F(xiàn)異常,很可能導(dǎo)致自身產(chǎn)品受到損失;公司外第三方依賴有些是小型公司,技術(shù)和運(yùn)維能力有限,其服務(wù)的性能,正確性、穩(wěn)定性不是很高。
3、風(fēng)險(xiǎn)識(shí)別
第三方依賴的可靠性是不可控的也是我們系統(tǒng)建設(shè)中不可避免的,那么只能盡量降低第三方依賴不穩(wěn)定對(duì)自身的影響。
4、風(fēng)險(xiǎn)消除:
盡量避免第三方強(qiáng)依賴;
超時(shí)設(shè)置,重試設(shè)置結(jié)合第三方容量,平均響應(yīng)時(shí)間,部署情況;
增加第三方依賴掛掉,假死,接口變更的校驗(yàn)及容錯(cuò)降級(jí)處理,從架構(gòu)和云微商做到各個(gè)TP方與自身業(yè)務(wù)的解耦;
運(yùn)維上,提高第三方依賴可靠性,使用內(nèi)網(wǎng)bns,vip請(qǐng)求,且避免跨機(jī)房交互。
真實(shí)案例
某產(chǎn)品線依賴A,B,C三個(gè)tp方數(shù)據(jù)進(jìn)行匯總展示,每次都需要調(diào)用三方都有結(jié)果時(shí)再進(jìn)行聚合,否則認(rèn)為整個(gè)流程失敗,而三個(gè)tp方穩(wěn)定性不盡相同,其中B是個(gè)小公司,經(jīng)常出現(xiàn)故障,導(dǎo)致自身服務(wù)經(jīng)常故障。
對(duì)此工程師對(duì)各個(gè)TP方加上了全面校驗(yàn),當(dāng)驗(yàn)證故障后自動(dòng)調(diào)用降級(jí)操作,去掉該tp依賴。從此服務(wù)穩(wěn)定性大大提升。
1、風(fēng)險(xiǎn)定義
前端請(qǐng)求一個(gè)肯定不存在的key,導(dǎo)致每次請(qǐng)求都會(huì)請(qǐng)求后端原始數(shù)據(jù),使得緩存被“穿透”,當(dāng)該類請(qǐng)求高并發(fā)時(shí),那么后端壓力凸顯。
2、風(fēng)險(xiǎn)影響
緩存穿透后,每個(gè)請(qǐng)求都會(huì)到達(dá)后端服務(wù),對(duì)后端服務(wù)壓力突增;當(dāng)緩存穿透的并發(fā)較高(尤其是惡意攻擊),后端服務(wù)很可能被壓垮,導(dǎo)致整個(gè)系統(tǒng)癱瘓。
3、風(fēng)險(xiǎn)原因
一種可能是對(duì)于主從分離系統(tǒng),緩存失效時(shí)間小于主從延遲時(shí)間,尤其是跨機(jī)房的主從分離,主從延遲在某些時(shí)候會(huì)達(dá)到數(shù)秒甚至數(shù)十秒,這是如果緩存時(shí)間設(shè)置過小,就會(huì)導(dǎo)致所有緩存讀寫記過均為失效結(jié)果,進(jìn)而請(qǐng)求后端服務(wù)獲取新的數(shù)據(jù)。另一種可能是查詢結(jié)果為空的情況。
4、風(fēng)險(xiǎn)消除
對(duì)于查詢結(jié)果為空的情況也進(jìn)行緩存,緩存時(shí)間設(shè)置短一點(diǎn),或者該key對(duì)應(yīng)的數(shù)據(jù)insert了之后清理緩存;
對(duì)于一定不存在的key進(jìn)行過濾,把這些key放到一個(gè)大的bitmap上;
設(shè)計(jì)的時(shí)候考慮,當(dāng)緩存失效時(shí),系統(tǒng)服務(wù)的情況及應(yīng)對(duì)措施。
1、風(fēng)險(xiǎn)定義
大量緩存同時(shí)過期失效,前端請(qǐng)求同時(shí)到達(dá)后端服務(wù)。
2、風(fēng)險(xiǎn)影響
當(dāng)并發(fā)量足夠大(比如秒殺,搶購),后端服務(wù)很可能被壓垮,導(dǎo)致整個(gè)系統(tǒng)雪崩。
3、風(fēng)險(xiǎn)識(shí)別
緩存設(shè)置時(shí)間相同,失效周期也相同,導(dǎo)致多個(gè)緩存同時(shí)失效。
4、風(fēng)險(xiǎn)消除
不同的key,設(shè)置不同的過期時(shí)間,讓緩存失效的時(shí)間點(diǎn)盡量散列均勻;
在緩存試下后,通過加鎖或者隊(duì)列來控制讀數(shù)據(jù)庫讀寫緩存的線程數(shù)量(比如對(duì)某個(gè)key只允許一個(gè)線程查詢和寫緩存,其他線程等待);
做二級(jí)緩存,A為原始緩存,A2位拷貝緩存,A1失效時(shí),可以訪問A2,A1緩存失效設(shè)置為較短,A2設(shè)置為長期。
真實(shí)案例
某產(chǎn)品線監(jiān)控發(fā)現(xiàn)機(jī)器A機(jī)器的8688端口掛掉了,經(jīng)追查發(fā)現(xiàn)一個(gè)廣告配置下發(fā)的接口(/api/v1/ipid)掛掉了,據(jù)統(tǒng)計(jì),前一天23點(diǎn)到當(dāng)日9點(diǎn)之間,該接口被訪問了400萬+次,正常來講,這種廣告配置下發(fā)的接口一天最多幾百個(gè)請(qǐng)求量。
經(jīng)查,客戶端有一個(gè)零點(diǎn)定時(shí)觸發(fā)策略,零點(diǎn)會(huì)同時(shí)啟動(dòng)很多服務(wù),平時(shí)并發(fā)請(qǐng)求會(huì)命中緩存,不會(huì)造成太大壓力,可是當(dāng)時(shí)正趕上緩存時(shí)間到期,大量請(qǐng)求將服務(wù)接口壓死,端口掛掉。
對(duì)此臨時(shí)方案是在接入層nginx配置文件中加入了流量控制機(jī)制,用lua腳本來將零點(diǎn)的請(qǐng)求屏蔽掉,長期方案是避免這種緩存集體失效的情況。
1、風(fēng)險(xiǎn)定義
系統(tǒng)架構(gòu)和設(shè)計(jì)上存在著耦合,包括模塊耦合、接口耦合、消息隊(duì)列耦合。具體體現(xiàn)在,主次不分的功能在一個(gè)模塊或者接口中實(shí)現(xiàn),nmq中不同重要性的命令耦合在同一個(gè)module中。
2、風(fēng)險(xiǎn)影響
整個(gè)系統(tǒng)穩(wěn)定性<最不穩(wěn)定的功能穩(wěn)定性,不重要的功能可能拖垮重要功能
3、風(fēng)險(xiǎn)消除
整體思路就是,重要與不重要拆分,實(shí)時(shí)與非實(shí)時(shí)拆分,在線與離線拆分,根本上解決就是架構(gòu)解耦,但是系統(tǒng)發(fā)展到一定階段再拆分代碼成本很高,這里可以通過運(yùn)維方法控制解耦,具體見如下案例。
真實(shí)案例
某產(chǎn)品線的一級(jí)服務(wù)和二級(jí)服務(wù)共同依賴一個(gè)基礎(chǔ)服務(wù),由于二級(jí)服務(wù)的一個(gè)bug拖垮基礎(chǔ)服務(wù),從而導(dǎo)致一級(jí)服務(wù)不可用,對(duì)此解決方案是通過運(yùn)維將不同上游流量分開。
思想同2.1.14這里不再贅述。
本文給出了常見的15種架構(gòu)設(shè)計(jì)風(fēng)險(xiǎn),希望大家能夠在實(shí)際工作中參考審視自己系統(tǒng)是否也存在同樣的風(fēng)險(xiǎn),盡早消除,提高穩(wěn)定性!
藍(lán)藍(lán)設(shè)計(jì)的小編 http://www.teruid.com