不作需求复印机——批量操做流程设计

    相信每一个技术人员都不会甘心作“需求复印机”。
    不作需求复印机，有两种简单的方式。一种是在代码/模块/系统的结构上下功夫，例如前面几篇设计方案（审批、分发等）。另外一种则是直接对业务流程开刀，例如这篇文章要举的例子。

背景

    你们必定都遇到过“批处理”这类需求。此次的背景就是一个批处理需求。按产品提出的需求，系统流程是这样的： 
    若是将这个流程直接“复印”到系统、代码中，显而易见会有性能风险。

思路

    这个需求的业务逻辑并不复杂，设计的关注点在于“性能”。性能风险的根源，看起来在于“一次提交N条数据”，实际上在于“同步请求”。由于同步请求会阻塞线程、占用资源，所以它对性能要求比较高。若是不是同步请求，而是异步响应，响应慢点儿其实也无所谓，性能风险天然消弭于无形。所以，个人方案就是用异步回调的方式来完成这个批处理请求。
    最简单的异步回调流程，就以下图所示。客户端向服务端批量地提交请求；服务端将异步任务提交给调度器后，马上向客户端返回；而后异步任务再逐个地回调客户端接口，以告知真正的处理结果。
     

    这个简单流程已经足以说明异步回调的思路，其中的问题也显而易见。例如，这个方案中没有对异步任务作持久化、判重、重试、限流的处理。这可能致使任务丢失、调度错误等问题，也可能致使客户端被回调请求压死。
    所以，这个简单的异步回调流程中被加入了MQ，即利用消息服务来作异步任务的调度器，并借以解决持久化、重试、限流等问题。以下图所示：
    
    

类图与代码

    这个方案的设计关键点并非类结构，而是业务流程。所以，与其它方案的类图、哪怕只是与上面的流程图相比，此次的类图都朴素得多。因此，此次我就偷懒不上类图和代码了。

后记

    这个方案其实并不出彩，它的起源只是我不想把产品需求“复印”到代码中而已。可是本质上，它也是一种技术驱动的思路：改变“怎么作”。尽管这个方案还没能进一步地改变“作什么”，可是，改变已从这里开始。