更新時間:2023-09-26 來源:黑馬程序員 瀏覽量:
微服務一旦拆分,必然涉及到服務之間的相互調(diào)用,調(diào)用者發(fā)起請求后需要等待服務提供者執(zhí)行業(yè)務返回結(jié)果后,繼續(xù)執(zhí)行后面的業(yè)務。調(diào)用者在調(diào)用過程中處于阻塞狀態(tài),因此我們成這種調(diào)用方式為同步調(diào)用,也可以叫同步通訊。但在很多場景下,我們可能需要采用異步通訊的方式,我們來看看什么是同步通訊和異步通訊。
同步通訊:就如同打視頻電話,雙方的交互都是實時的。因此同一時刻你只能跟一個人打視頻電話。
異步通訊:就如同發(fā)微信聊天,雙方的交互不是實時的,你不需要立刻給對方回應。因此你可以多線操作,同時跟多人聊天。
兩種方式各有優(yōu)劣,打電話可以立即得到響應,但是你卻不能跟多個人同時通話。發(fā)微信可以同時與多個人收發(fā)微信,但是往往響應會有延遲。
所以,如果我們的業(yè)務需要實時得到服務提供方的響應,則應該選擇同步通訊(同步調(diào)用)。而如果我們追求更高的效率,并且不需要實時響應,則應該選擇異步通訊(異步調(diào)用)。
第一,拓展性差 我們目前的業(yè)務相對簡單,但是隨著業(yè)務規(guī)模擴大,產(chǎn)品的功能也在不斷完善。 在大多數(shù)電商業(yè)務中,用戶支付成功后都會以短信或者其它方式通知用戶,告知支付成功。假如后期產(chǎn)品經(jīng)理提出這樣新的需求,你怎么辦?是不是要在上述業(yè)務中再加入通知用戶的業(yè)務? 某些電商項目中,還會有積分或金幣的概念。假如產(chǎn)品經(jīng)理提出需求,用戶支付成功后,給用戶以積分獎勵或者返還金幣,你怎么辦?是不是要在上述業(yè)務中再加入積分業(yè)務、返還金幣業(yè)務? 。。。 最終你的支付業(yè)務會越來越臃腫:
也就是說每次有新的需求,現(xiàn)有支付邏輯都要跟著變化,代碼經(jīng)常變動,不符合開閉原則,拓展性不好。
第二,性能下降 由于我們采用了同步調(diào)用,調(diào)用者需要等待服務提供者執(zhí)行完返回結(jié)果后,才能繼續(xù)向下執(zhí)行,也就是說每次遠程調(diào)用,調(diào)用者都是阻塞等待狀態(tài)。最終整個業(yè)務的響應時長就是每次遠程調(diào)用的執(zhí)行時長之和,假如每個微服務的執(zhí)行時長都是50ms,則最終整個業(yè)務的耗時可能高達300ms,性能太差了。
第三,級聯(lián)失敗 由于我們是基于OpenFeign調(diào)用交易服務、通知服務。當交易服務、通知服務出現(xiàn)故障時,整個事務都會回滾,交易失敗。 這其實就是同步調(diào)用的級聯(lián)失敗問題。
而要解決這些問題,我們就必須用異步調(diào)用的方式來代替同步調(diào)用。
異步調(diào)用方式其實就是基于消息通知的方式,一般包含三個角色:
消息發(fā)送者:投遞消息的人,就是原來的調(diào)用方
消息Broker:管理、暫存、轉(zhuǎn)發(fā)消息,你可以把它理解成微信服務器
消息接收者:接收和處理消息的人,就是原來的服務提供方
在異步調(diào)用中,發(fā)送者不再直接同步調(diào)用接收者的業(yè)務接口,而是發(fā)送一條消息投遞給消息Broker。然后接收者根據(jù)自己的需求從消息Broker那里訂閱消息。每當發(fā)送方發(fā)送消息后,接受者都能獲取消息并處理。 這樣,發(fā)送消息的人和接收消息的人就完全解耦了。
還是以余額支付業(yè)務為例:
假如產(chǎn)品經(jīng)理提出了新的需求,比如要在支付成功后更新用戶積分。支付代碼完全不用變更,而僅僅是讓積分服務也訂閱消息即可:
另外,不管是交易服務、通知服務,還是積分服務,他們的業(yè)務與支付關(guān)聯(lián)度低?,F(xiàn)在采用了異步調(diào)用,解除了耦合,他們即便執(zhí)行過程中出現(xiàn)了故障,也不會影響到支付服務。
綜上,異步調(diào)用的優(yōu)勢包括:
耦合度更低
性能更好
業(yè)務拓展性強
故障隔離,避免級聯(lián)失敗
當然,異步通信也并非完美無缺,它存在下列缺點:
完全依賴于Broker的可靠性、安全性和性能
架構(gòu)復雜,后期維護和調(diào)試麻煩