不作需求複印機——批量操做流程設計

    相信每一個技術人員都不會甘心作「需求複印機」。
    不作需求複印機，有兩種簡單的方式。一種是在代碼/模塊/系統的結構上下功夫，例如前面幾篇設計方案（審批、分發等）。另外一種則是直接對業務流程開刀，例如這篇文章要舉的例子。

背景

    你們必定都遇到過「批處理」這類需求。此次的背景就是一個批處理需求。按產品提出的需求，系統流程是這樣的： 
    若是將這個流程直接「複印」到系統、代碼中，顯而易見會有性能風險。

思路

    這個需求的業務邏輯並不複雜，設計的關注點在於「性能」。性能風險的根源，看起來在於「一次提交N條數據」，實際上在於「同步請求」。由於同步請求會阻塞線程、佔用資源，所以它對性能要求比較高。若是不是同步請求，而是異步響應，響應慢點兒其實也無所謂，性能風險天然消弭於無形。所以，個人方案就是用異步回調的方式來完成這個批處理請求。
    最簡單的異步回調流程，就以下圖所示。客戶端向服務端批量地提交請求；服務端將異步任務提交給調度器後，馬上向客戶端返回；而後異步任務再逐個地回調客戶端接口，以告知真正的處理結果。
     

    這個簡單流程已經足以說明異步回調的思路，其中的問題也顯而易見。例如，這個方案中沒有對異步任務作持久化、判重、重試、限流的處理。這可能致使任務丟失、調度錯誤等問題，也可能致使客戶端被回調請求壓死。
    所以，這個簡單的異步回調流程中被加入了MQ，即利用消息服務來作異步任務的調度器，並藉以解決持久化、重試、限流等問題。以下圖所示：
    
    

類圖與代碼

    這個方案的設計關鍵點並非類結構，而是業務流程。所以，與其它方案的類圖、哪怕只是與上面的流程圖相比，此次的類圖都樸素得多。因此，此次我就偷懶不上類圖和代碼了。

後記

    這個方案其實並不出彩，它的起源只是我不想把產品需求「複印」到代碼中而已。可是本質上，它也是一種技術驅動的思路：改變「怎麼作」。儘管這個方案還沒能進一步地改變「作什麼」，可是，改變已從這裏開始。