不做需求復印機——批量操作流程設計
相信每個技術人員都不會甘心做“需求復印機”。
不做需求復印機，有兩種簡單的方式。一種是在代碼/模塊/系統的結構上下功夫，例如前面幾篇設計方案（審批、分發等）。另一種則是直接對業務流程開刀，例如這篇文章要舉的例子。
背景
大家一定都遇到過“批處理”這類需求。這次的背景就是一個批處理需求。按產品提出的需求，系統流程是這樣的： 
思路
這個需求的業務邏輯並不復雜，設計的關註點在於“性能”。性能風險的根源，看起來在於“一次提交N條數據”，實際上在於“同步請求”。因為同步請求會阻塞線程、占用資源，因此它對性能要求比較高。如果不是同步請求，而是異步響應，響應慢點兒其實也無所謂，性能風險自然消弭於無形。因此，我的方案就是用異步回調的方式來完成這個批處理請求。
最簡單的異步回調流程，就如下圖所示。客戶端向服務端批量地提交請求；服務端將異步任務提交給調度器後，立刻向客戶端返回；然後異步任務再逐個地回調客戶端接口，以告知真正的處理結果。
這個簡單流程已經足以說明異步回調的思路，其中的問題也顯而易見。例如，這個方案中沒有對異步任務做持久化、判重、重試、限流的處理。這可能導致任務丟失、調度錯誤等問題，也可能導致客戶端被回調請求壓死。
因此，這個簡單的異步回調流程中被加入了MQ，即利用消息服務來做異步任務的調度器，並借以解決持久化、重試、限流等問題。如下圖所示：
類圖與代碼
這個方案的設計關鍵點並不是類結構，而是業務流程。因此，與其它方案的類圖、哪怕只是與上面的流程圖相比，這次的類圖都樸素得多。所以，這次我就偷懶不上類圖和代碼了。
後記
這個方案其實並不出彩，它的起源只是我不想把產品需求“復印”到代碼中而已。但是本質上，它也是一種技術驅動的思路：改變“怎麽做”。盡管這個方案還沒能進一步地改變“做什麽”，但是，改變已從這裏開始。
本文出自 “編程的摩羯男” 博客，請務必保留此出處http://winters1224.blog.51cto.com/3021203/1959648
不做需求復印機——批量操作流程設計