摘要：典型場(chǎng)景二上游不關(guān)心執(zhí)行結(jié)果上游需要關(guān)注執(zhí)行結(jié)果時(shí)要用調(diào)用，上游不關(guān)注執(zhí)行結(jié)果時(shí)，就可以使用了。

什么是任務(wù)依賴(lài)，舉個(gè)栗子，互聯(lián)網(wǎng)公司經(jīng)常在凌晨進(jìn)行一些數(shù)據(jù)統(tǒng)計(jì)任務(wù)，這些任務(wù)之間有一定的依賴(lài)關(guān)系，比如：

1）task3需要使用task2的輸出作為輸入

2）task2需要使用task1的輸出作為輸入

這樣的話(huà)，tast1, task2, task3之間就有任務(wù)依賴(lài)關(guān)系，必須task1先執(zhí)行，再task2執(zhí)行，載task3執(zhí)行。

對(duì)于這類(lèi)需求，常見(jiàn)的實(shí)現(xiàn)方式是，使用cron人工排執(zhí)行時(shí)間表：

1）task1，0:00執(zhí)行，經(jīng)驗(yàn)執(zhí)行時(shí)間為50分鐘

2）task2，1:00執(zhí)行（為task1預(yù)留10分鐘buffer），經(jīng)驗(yàn)執(zhí)行時(shí)間也是50分鐘

3）task3，2:00執(zhí)行（為task2預(yù)留10分鐘buffer）

這種方法的壞處是：

1）如果有一個(gè)任務(wù)執(zhí)行時(shí)間超過(guò)了預(yù)留buffer的時(shí)間，將會(huì)得到錯(cuò)誤的結(jié)果，因?yàn)楹笾萌蝿?wù)不清楚前置任務(wù)是否執(zhí)行成功，此時(shí)要手動(dòng)重跑任務(wù)，還有可能要調(diào)整排班表

2）總?cè)蝿?wù)的執(zhí)行時(shí)間很長(zhǎng)，總是要預(yù)留很多buffer，如果前置任務(wù)提前完成，后置任務(wù)不會(huì)提前開(kāi)始

3）如果一個(gè)任務(wù)被多個(gè)任務(wù)依賴(lài)，這個(gè)任務(wù)將會(huì)稱(chēng)為關(guān)鍵路徑，排班表很難體現(xiàn)依賴(lài)關(guān)系，容易出錯(cuò)

4）如果有一個(gè)任務(wù)的執(zhí)行時(shí)間要調(diào)整，將會(huì)有多個(gè)任務(wù)的執(zhí)行時(shí)間要調(diào)整

無(wú)論如何，采用“cron排班表”的方法，各任務(wù)耦合，誰(shuí)用過(guò)誰(shuí)痛誰(shuí)知道（采用此法的請(qǐng)?jiān)u論留言）

優(yōu)化方案是，采用MQ解耦：

1）task1準(zhǔn)時(shí)開(kāi)始，結(jié)束后發(fā)一個(gè)“task1 done”的消息

2）task2訂閱“task1 done”的消息，收到消息后第一時(shí)間啟動(dòng)執(zhí)行，結(jié)束后發(fā)一個(gè)“task2 done”的消息

3）task3同理

采用MQ的優(yōu)點(diǎn)是：

1）不需要預(yù)留buffer，上游任務(wù)執(zhí)行完，下游任務(wù)總會(huì)在第一時(shí)間被執(zhí)行

2）依賴(lài)多個(gè)任務(wù)，被多個(gè)任務(wù)依賴(lài)都很好處理，只需要訂閱相關(guān)消息即可

3）有任務(wù)執(zhí)行時(shí)間變化，下游任務(wù)都不需要調(diào)整執(zhí)行時(shí)間

需要特別說(shuō)明的是，MQ只用來(lái)傳遞上游任務(wù)執(zhí)行完成的消息，并不用于傳遞真正的輸入輸出數(shù)據(jù)。

上游需要關(guān)注執(zhí)行結(jié)果時(shí)要用“調(diào)用”，上游不關(guān)注執(zhí)行結(jié)果時(shí)，就可以使用MQ了。

舉個(gè)栗子，58同城的很多下游需要關(guān)注“用戶(hù)發(fā)布帖子”這個(gè)事件，比如招聘用戶(hù)發(fā)布帖子后，招聘業(yè)務(wù)要獎(jiǎng)勵(lì)58豆，房產(chǎn)用戶(hù)發(fā)布帖子后，房產(chǎn)業(yè)務(wù)要送2個(gè)置頂，二手用戶(hù)發(fā)布帖子后，二手業(yè)務(wù)要修改用戶(hù)統(tǒng)計(jì)數(shù)據(jù)。

對(duì)于這類(lèi)需求，常見(jiàn)的實(shí)現(xiàn)方式是，使用調(diào)用關(guān)系：

帖子發(fā)布服務(wù)執(zhí)行完成之后，調(diào)用下游招聘業(yè)務(wù)、房產(chǎn)業(yè)務(wù)、二手業(yè)務(wù)，來(lái)完成消息的通知，但事實(shí)上，這個(gè)通知是否正常正確的執(zhí)行，帖子發(fā)布服務(wù)根本不關(guān)注。

這種方法的壞處是：

1）帖子發(fā)布流程的執(zhí)行時(shí)間增加了

2）下游服務(wù)當(dāng)機(jī)，可能導(dǎo)致帖子發(fā)布服務(wù)受影響，上下游邏輯+物理依賴(lài)嚴(yán)重

3）每當(dāng)增加一個(gè)需要知道“帖子發(fā)布成功”信息的下游，修改代碼的是帖子發(fā)布服務(wù)，這一點(diǎn)是最?lèi)盒牡?，屬于架?gòu)設(shè)計(jì)中典型的依賴(lài)倒轉(zhuǎn)

優(yōu)化方案是，采用MQ解耦：

1）帖子發(fā)布成功后，向MQ發(fā)一個(gè)消息

2）哪個(gè)下游關(guān)注“帖子發(fā)布成功”的消息，主動(dòng)去MQ訂閱

采用MQ的優(yōu)點(diǎn)是：

1）上游執(zhí)行時(shí)間短

2）上下游邏輯+物理解耦，除了與MQ有物理連接，模塊之間都不相互依賴(lài)

3）新增一個(gè)下游消息關(guān)注方，上游不需要修改任何代碼

有時(shí)候上游需要關(guān)注執(zhí)行結(jié)果，但執(zhí)行結(jié)果時(shí)間很長(zhǎng)（典型的是調(diào)用離線(xiàn)處理，或者跨公網(wǎng)調(diào)用），也經(jīng)常使用回調(diào)網(wǎng)關(guān)+MQ來(lái)解耦。

舉個(gè)栗子，微信支付，跨公網(wǎng)調(diào)用微信的接口，執(zhí)行時(shí)間會(huì)比較長(zhǎng)，但調(diào)用方又非常關(guān)注執(zhí)行結(jié)果，此時(shí)一般怎么玩呢？

一般采用“回調(diào)網(wǎng)關(guān)+MQ”方案來(lái)解耦：

1）調(diào)用方直接跨公網(wǎng)調(diào)用微信接口

2）微信返回調(diào)用成功，此時(shí)并不代表返回成功

3）微信執(zhí)行完成后，回調(diào)統(tǒng)一網(wǎng)關(guān)

4）網(wǎng)關(guān)將返回結(jié)果通知MQ

5）請(qǐng)求方收到結(jié)果通知

這里需要注意的是，不應(yīng)該由回調(diào)網(wǎng)關(guān)來(lái)調(diào)用上游來(lái)通知結(jié)果，如果是這樣的話(huà)，每次新增調(diào)用方，回調(diào)網(wǎng)關(guān)都需要修改代碼，仍然會(huì)反向依賴(lài)，使用回調(diào)網(wǎng)關(guān)+MQ的方案，新增任何對(duì)微信支付的調(diào)用，都不需要修改代碼啦。