如何設計一個異步Web服務——接口部分

需求比較簡單，提供一個異步Web服務供使用者調用。好比說，某應用程序須要批量地給圖片加lomo效果。因爲加lomo效果這個操做很是消耗CPU資源，因此咱們須要把這個加lomo效果的程序邏輯放到一臺單獨的服務器上去運行，以避免影響應用自己所在服務器的性能。

 

這篇先講講服務的接口部分，側重於理清應用和服務之間的調用關係，有時間的話，後面再寫一篇關於服務內部任務分派資源調度的隨筆。

根據這個需求，咱們能夠很快設計出一套流程：

 

Application經過向service的addTask接口post任務相關的信息建立一個任務，同時，service將此任務的任務id，即taskId返回給Application，以便Application接下來能夠用這個taskId經過getStatus接口查詢此任務的進行狀態。

 

問題一：

Application做爲一個獨立的應用，他確定須要有本身的任務管理邏輯。也就是說，Application在向Service發出建立任務的請求前，確定須要先往本身的DB中寫入一條對應這個任務的相關數據，以便後續跟蹤每一個任務的狀態和數據。那麼application在收到response時，如何將這個response的taskId和本身以前寫入DB的那條數據對應起來呢？

 

若是是上面的那種接口設計，應該是沒法實現這個要求的。因此咱們須要給addTask接口加一個用來標記任務惟一性的參數customId。以下圖：

 

問題二：

根據上面的設計，Application在建立task以後，會不斷調用Service的getStatus接口，來獲取該任務的最新狀態，好比任務是在等待中、進行時仍是已完成。可是，這顯然不是一個很是高效的方式。若是任務進行的時間比較長，Application則會在這段時間內屢次調用getStatus接口以及時獲取任務狀態信息。這樣作不但加劇了Application的負擔，更加劇了Service的負擔。因此，咱們能夠把這個地方的依賴關係反過來，讓Service主動將任務的狀態信息通知給Application。相應的，Service和Application的接口也要作相應變化：

 

如上圖，咱們將原來由Application調用Service的getStatus接口的過程，改成了Service調用Application的setStatus接口。這樣就實現了，一旦task狀態發生變化，Service都能實時通知Application，從而減小了兩個服務間無用的請求。

 

問題三：

假如，Application調用Service的addTask接口後，服務器由於種種緣由沒法響應外部請求了。那麼接下來，當task結束之後，Service就無法將這個重要的狀態信息反饋給Application了。並且，因爲Service不可能永遠不停地嘗試去調用Application的setStatus接口，直到成功。那麼，當Application從新啓動之後如何獲取以前那個任務的狀態就成了一個問題。因此，基於這樣的緣由，以前的getStatus接口其實仍是有存在的必要的。

 

有了getStatus這個接口之後，如若Application在調用addTask之後出現當機等現象而錯過了Service推送的task完成的消息。那麼Application在從新啓動之後，還能夠本身經過Service的getStatus接口獲取這個任務的最新狀態。

 

至此，API部分設計完畢。

---

 

關於接口的部分，目前我所能想到的問題大概就這麼多，不知道有沒有什麼遺漏或不妥。但願你們不吝賜教，在下感激萬分。

下篇：《如何設計一個異步Web服務——任務調度》

 

如需轉載，請註明轉自：http://www.cnblogs.com/silenttiger/p/4076333.html

 

歡迎關注個人微信公衆號：老虎的小窩