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