基于任务的系统架构

    任务是指实现单一功能的单元。对于"单一功能"的认定没有通用标准，单元的颗粒可大可小；能够是一个算法的实现、一个公共方法或者一个事务等。

    通常的系统采用基于任务的架构，主要针对两个问题：1，并发执行的须要；2，定时执行；对于以上两种场景的分析这里再也不赘述。我从解耦的角度再深挖一下这种架构模式的优势和适用场景。提到解耦，经历过度布式系统设计、开发的同仁都有体会；它是系统容量、性能、可扩展性、可维护性提高的重要基础。实现解耦的主要途径是分布式系统间的接口调用、引入消息中间件、利用DB持久化等方式；这是较大颗粒度的解耦，因为接口调用、消息、持久化等方式都是物理层面的解耦，因此从软件实现看：解耦地生硬。

    我想更加精细的解耦-采起任务模式的系统架构，将任务间数据的传递采用分布式系统间接口调用、消息、持久化等；而任务间数据的传递经过任务执行引擎对任务屏蔽。同步方法调用以下图左侧所示，（分布式系统间的同步）接口调用也于此相似；过渡到任务模式的系统架构时，调用关系发生了变化：方法间再也不直接调用，而经过任务执行引擎（配合事件或者工做流）组装了方法调用；任务的运行时能够利用多线程得到更好的执行效率，也能够利用执行引擎得到对稀缺资源的软同步控制。

    基于任务的系统架构更容易实现分布式横向扩展，与面向接口相比，它是面向（任务执行所需的）数据的，不存在接口变更的重构问题，且将数据处理算法封装在一个独立执行的单元中。任务的执行有两种策略：1，由前一个任务执行完后，启动下一个任务；2，由守护线程根据经过状态机建立执行任务；这两种方案我比较倾向后者；本质上差很少，可是后者对于测试有更好的效果。

    基于任务的系统在TDD、BDD、DDD都有比较好的使用效果；通常意义的TDD是面向API或者接口的，这里的TDD是面向任务的，明确了每一个任务执行以前、执行以后数据的状态机；从而为业务级别的复用奠基了基础；在BDD的实践中，任务模式也能够得到很好的测试效果，由于BDD就是经过比对数据的值校验测试结果的。以上两类测试中，都不用启动任务引擎，经过任务间的方法调用，就能够实现测试过程。DDD是从业务级别的封装，也就是大粒度的任务或者任务组合。

    有利就有弊，与单一应用相比，这样的系统架构比较复杂；与（接口调用式的）分布式系统相比，这样的系统架构也没法利用语言的静态检查。比任务架构更复杂的是基于事件的Actor架构，后者更加精致，并发性能更好。

    该系统架构的关键在于控制任务的颗粒度。