需求比較簡單，提供一個異步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
歡迎關注我的微信公眾號：老虎的小窩