事物中調(diào)用RPC
RPC的設(shè)計(jì)和使用核心是design for failure揍愁，從這個(gè)角度介紹一下事物中調(diào)用RPC,談?wù)勎易约旱睦斫狻?/p>
1.場(chǎng)景
一個(gè)事物中可能包含N個(gè)RPC調(diào)用，可能因?yàn)楦鞣N原因杀饵，RPC會(huì)調(diào)用失敗莽囤，而事物又不能一直等待，因此需要做系統(tǒng)上的涉及保證系統(tǒng)能正常使用凹髓。
2.服務(wù)使用方策略
2.1.超時(shí)重試
因?yàn)镽PC請(qǐng)求肯定都是會(huì)設(shè)置超時(shí)的烁登，如果不設(shè)置可能造成鏈路阻塞，但是超時(shí)的原因多種多樣蔚舀，有些可能僅僅因?yàn)榫W(wǎng)絡(luò)抖動(dòng)饵沧。
因此重試是必不可少的，對(duì)于不同的服務(wù)可以采取不同的超時(shí)策略赌躺。
-
不進(jìn)行重試的
業(yè)務(wù)邏輯錯(cuò)
下游系統(tǒng)掛掉
-
進(jìn)行重試的
- 網(wǎng)絡(luò)抖動(dòng)
狼牺。。礼患。
可以通過(guò)業(yè)務(wù)異常進(jìn)行區(qū)分判斷
-
對(duì)實(shí)時(shí)性有要求的
- 請(qǐng)求重要度低的
對(duì)于這樣的超時(shí)可以直接執(zhí)行failfast是钥，或者降級(jí)返回mock數(shù)據(jù)。
- 請(qǐng)求重要的
基本上是需要根據(jù)異常情況進(jìn)行是否重試缅叠，或者事物補(bǔ)償/人工處理悄泥，通常來(lái)說(shuō)對(duì)實(shí)時(shí)性有要求的重試會(huì)在固定時(shí)間間隔發(fā)起。
- 對(duì)實(shí)時(shí)性要求低的
這樣的重試可以采用指數(shù)退避的方式,即第一次等N 第二次等2N...這樣的方式肤粱，不會(huì)對(duì)下游造成太大壓力
2.1.1.如何重試
重試是Design for failure的重要部分
常用的方式有:
failover
failfast(不重試)
failBack
2.2.冪等設(shè)計(jì)
2.2.1.是不是需要冪等
首先要明確的是不是所有請(qǐng)求都需要做冪等操作的弹囚，因?yàn)閮绲仁切枰鷥r(jià)的(通常都依賴存儲(chǔ)層唯一鍵，和全局唯一id).類似Restful接口中DELETE GET HEAD等都不需要增加冪等操作领曼，同樣RPC也一樣鸥鹉，對(duì)數(shù)據(jù)狀態(tài)不影響的請(qǐng)求不應(yīng)該過(guò)多的增加冪等蛮穿。
2.2.2.如何保證冪等
通常來(lái)說(shuō)RPC需要帶一個(gè)全局id(可以考慮snowflake),在接收方將id保存到數(shù)據(jù)庫(kù)中，如果id沖突說(shuō)明已經(jīng)有此id毁渗，即消息是重復(fù)的践磅。
2.3.對(duì)某些服務(wù)進(jìn)行服務(wù)降級(jí)
降級(jí)是針對(duì)相對(duì)不重要的服務(wù)的，如果是重要服務(wù)是不能進(jìn)行降級(jí)的灸异。降級(jí)是從整體負(fù)載考慮的府适，因此就需要為服務(wù)定優(yōu)先級(jí)，確定優(yōu)先級(jí)之后才能合理的進(jìn)行降級(jí)分配绎狭。
2.3.1.對(duì)非核心鏈路服務(wù)降級(jí)
降級(jí)一般有兩種方式细溅，自動(dòng)方式和手動(dòng)方式，這邊主要聊一下自動(dòng)方式儡嘶。
2.3.1.1.自動(dòng)降級(jí)
通常來(lái)說(shuō)自動(dòng)降級(jí)需要失敗記錄的配合：
超時(shí)降級(jí)
失敗次數(shù)降級(jí)
故障降級(jí)
限流降級(jí)
等等喇聊。。蹦狂。
2.3.1.2.降級(jí)方式
一般來(lái)說(shuō)的降級(jí)方式是進(jìn)行mock返回
force:return策略:直接返回mock數(shù)據(jù)
fail:return策略：調(diào)用后觸發(fā)重試上限之后返回mock數(shù)據(jù)誓篱。
2.3.對(duì)不重要的服務(wù)進(jìn)行熔斷
降級(jí)是從整體資源分配的考慮上來(lái)考慮的，大多數(shù)是因?yàn)闉榱藨?yīng)對(duì)即將到來(lái)的大流量或者彈性的hold住大流量凯楔。而系統(tǒng)往往還會(huì)遇到下游系統(tǒng)故障導(dǎo)致無(wú)法正確返回的問(wèn)題窜骄。這樣就需要增加熔斷機(jī)制，來(lái)保證不會(huì)造成壓力傳遞摆屯，導(dǎo)致雪崩邻遏。
2.3.1.熔斷怎么做
斷路器狀態(tài)有以下幾個(gè)
關(guān)閉狀態(tài)
打開(kāi)狀態(tài)
半開(kāi)狀態(tài)
2.4.事物回滾(補(bǔ)償機(jī)制)
這一步通常是最后才考慮的，因?yàn)殡S著鏈路的深入虐骑，事物補(bǔ)償?shù)拇鷥r(jià)變得很大准验，不過(guò)如果必須走到這一步也只能做，同樣也有不同策略：
因?yàn)檠a(bǔ)償通常都是有狀態(tài)有上下文的廷没，因此需要保存上個(gè)狀態(tài)的數(shù)據(jù)糊饱，可以通過(guò)以下兩種模式保存
2.4.1.本機(jī)保存
直接本機(jī)保存補(bǔ)償數(shù)據(jù)
優(yōu)點(diǎn)：方便，快速
缺點(diǎn)：會(huì)涉及宕機(jī)丟數(shù)據(jù)颠黎，集群處理時(shí)數(shù)據(jù)混亂
2.4.2.持久化保存
持久化保存也是通常的使用方案另锋，（這里不糾結(jié)是使用mysql還是redis，存儲(chǔ)層的高可用不在這邊討論）
優(yōu)點(diǎn)：全局共享狭归，不會(huì)丟數(shù)據(jù)
缺點(diǎn)：可能影響性能夭坪，對(duì)存儲(chǔ)帶來(lái)壓力
2.5.人工處理
如果補(bǔ)償失敗，則會(huì)觸發(fā)人工處理过椎，因?yàn)檠a(bǔ)償失敗意味著這個(gè)事物進(jìn)退兩難了台舱，至少這個(gè)請(qǐng)求已經(jīng)脫離系統(tǒng)控制。這時(shí)候就需要適合的監(jiān)控報(bào)警方式。
至于如何進(jìn)行人工處理不在本文討論內(nèi)容竞惋，各自系統(tǒng)都需要自己解決。無(wú)外乎數(shù)據(jù)修修補(bǔ)補(bǔ)灰嫉，bug修復(fù)拆宛。
3.服務(wù)提供方策略
3.1.服務(wù)限流
光是調(diào)用方做處理實(shí)際上是不夠的，還需要服務(wù)自身盡量保證自己不會(huì)被壓力壓垮讼撒，因此需要用限流的方式拒絕一些流量浑厚，來(lái)保證自己服務(wù)不會(huì)被打掛.
3.1.1.常見(jiàn)的限流策略
漏斗桶
令牌桶
