建站
咨詢
售后
建站咨詢
新聞中心
一個架構常識：當調用方需要關心執(zhí)行結果，通常使用RPC調用。
成都創(chuàng)新互聯(lián)長期為上1000+客戶提供的網(wǎng)站建設服務，團隊從業(yè)經(jīng)驗10年，關注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為丹棱企業(yè)提供專業(yè)的網(wǎng)站制作、做網(wǎng)站，丹棱網(wǎng)站改版等技術服務。擁有10年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。
- ret = PassportService::userAuth(name, pass);
- switch(ret){
- case(YES) : return YesHTML();
- case(NO) : return NoHTML();
- case(JUMP) : return 304HTML():
- default : return 500HTML();
- }
上一篇《服務化，耦合卻更加嚴重》提到，執(zhí)行結果的處理和業(yè)務強相關，則switch case應該放在上游業(yè)務方，而不應該放到底層通用服務。
登錄頁面調用passport服務，會根據(jù)passport服務的返回結果，區(qū)別執(zhí)行登錄成功，登錄失敗，執(zhí)行錯誤。調用方關注執(zhí)行結果時，不宜使用MQ通訊。
使用MQ通訊，調用方不能直接告之用戶登錄成功又或失敗，阻塞住等待MQ通知回調不但使得編碼復雜，還會引入消息丟失的風險，中間多加入一層，多此一舉，基本沒有人這么玩。
但如果調用方不關心執(zhí)行結果，卻仍然使用RPC調用，會引發(fā)上下游極大的耦合與瓶頸。
場景還原
有一個通用的上游服務，例如“帖子發(fā)布”服務，負責公司通用的帖子發(fā)布業(yè)務。有一些個性化的業(yè)務關心“用戶發(fā)布帖子”這個事件，例如：
- 用戶發(fā)布帖子后，大數(shù)據(jù)部門要更新用戶的畫像
- 用戶發(fā)布帖子后，信息質量部門要異步檢查帖子是否合規(guī)
- 招聘業(yè)務最近在做用戶促活，如果用戶發(fā)布的是招聘帖子，要增加積分
- …
個性化下游關注這個事件，但下游對事件的執(zhí)行結果，“帖子發(fā)布”服務卻并不關心，如果“帖子發(fā)布”服務通過RPC的方式去通知下游，就會有很大的問題。
耦合為何存在?
帖子發(fā)布服務，這本來應該是一個非常基礎的服務，上游upper通過RPC調用將事件同步給事件關注業(yè)務方biz1/biz2/biz3：
- 一旦有新的業(yè)務需求要關注這個事件，修改代碼的是通用上游upper，此時通用服務的owner就在心里罵娘了“為何有需求的是你，修改代碼的卻是我”
- 一旦業(yè)務側出問題，會影響上游通用基礎服務，此時通用服務的owner又在心里罵娘了“我ca，穩(wěn)定性的KPI，全被兄弟部門毀了”
- 一旦業(yè)務側接口升級，上游基礎服務需要配合升級，此時通用服務的owner可能又會抱怨“為何被動升級的人總是我”
架構不合理，簡直痛不欲生。
如何解耦呢?
如果事件發(fā)出方不關心訂閱方的執(zhí)行結果，不能用RPC，應該用MQ。
MQ能夠做到上下游物理上和邏輯上都解耦：
- 物理上解耦，增加MQ之后，上游互不知道彼此的存在，不會建立物理連接了，大家都只與MQ建立物理連接
- 邏輯上解耦，事件發(fā)布方甚至不用知道哪些下游訂閱了這個消息，新增消息的訂閱方只需要連接MQ就行了，不需要上游關注
MQ是一個非常常見的物理上解耦、邏輯上也解耦的利器。
- 關注下游執(zhí)行執(zhí)行結果，用RPC;
- 不關注下游執(zhí)行結果，用MQ，不用RPC;
這只是一個很小的優(yōu)化點，但對于通知解耦卻是非常有效。
【本文為專欄作者“58沈劍”原創(chuàng)稿件，轉載請聯(lián)系原作者】
網(wǎng)站欄目：MQ—互聯(lián)網(wǎng)架構解耦神器
本文網(wǎng)址：http://www.dlmjj.cn/article/djsjopd.html
