多线程管理一款功能强大、配置灵活、高性能异步编排框架( 二 ) _框架

说明任务A 执行完了之后执行B、E 然后按照顺序 B的流程走C、D、G 。E的流程走F、G

还有更多场景，如果你想详细理解任务编排的概念，请仔细阅读文档，或者通过资源索引导航到官网了解全貌！

业界对比
在开源平台找了挺多任务异步编排框架，发现都不是很理想，唯一一款现阶段比较好用的异步编排框架就数asyncTool比较好用。但是在使用时发现，API不是很好用。而且需要频繁的创建 WorkerWrApper 对象用起来有点不爽。对于业务比较复杂的场景，在开发时需要写较多的 WorkerWrapper 代码，而且框架不能对全局异常进行拦截。只能通过任务的 result 方法捕捉单任务的异常。不能在任意任务出现异常后停止全局的异步任务。同时无法在发生全局异常的时候进行异常拦截。如果需要实现在发生需停止全局任务流的时候，发送报警邮件的功能。asyncTool就显得力不从心了。
asyncTool 本身已经功能很强大了，本人与asyncTool 作者都是在京东担任研发工作。涉及到的场景大同小异。会有很多业务场景，很复杂的中台接口调用关系。所以针对当前业务场景。需要探索更多的技术领域。本身技术是应该服务于业务，落地业务场景。
想给项目起一个简单易记的名字，类似于 Eureka、Nacos、redis；经过再三考虑后，决定命名：Gobrs-Async
功能
asyncTool
Gobrs-Async
sirector
多任务处理
单任务异常回调
全局异常中断
可配置任务流
自定义异常拦截器
内存优化
可选的任务执行
它解决了什么问题
在请求调用各大中台数据时，难免会出现多个中台数据互相依赖的情况，现实开发中会遇到如下场景。
并行常见的场景 1 客户端请求服务端接口，该接口需要调用其他N个微服务的接口
譬如请求我的购物车，那么就需要去调用用户的rpc、商品详情的rpc、库存rpc、优惠券等等好多个服务。同时，这些服务还有相互依赖关系，譬如必须先拿到商品id后，才能去库存rpc服务请求库存信息。最终全部获取完毕后，或超时了，就汇总结果，返回给客户端。
2 并行执行N个任务，后续根据这1-N个任务的执行结果来决定是否继续执行下一个任务
如用户可以通过邮箱、手机号、用户名登录，登录接口只有一个，那么当用户发起登录请求后，我们需要并行根据邮箱、手机号、用户名来同时查数据库，只要有一个成功了，都算成功，就可以继续执行下一步。而不是先试邮箱能否成功、再试手机号……
再如某接口限制了每个批次的传参数量，每次最多查询10个商品的信息，我有45个商品需要查询，就可以分5堆并行去查询，后续就是统计这5堆的查询结果。就看你是否强制要求全部查成功，还是不管有几堆查成功都给客户做返回
再如某个接口，有5个前置任务需要处理。其中有3个是必须要执行完毕才能执行后续的，另外2个是非强制的，只要这3个执行完就可以进行下一步，到时另外2个如果成功了就有值，如果还没执行完，就是默认值。
3 需要进行线程隔离的多批次任务。
如多组任务，各组任务之间彼此不相关，每组都需要一个独立的线程池，每组都是独立的一套执行单元的组合。有点类似于hystrix的线程池隔离策略。
4 单机工作流任务编排。
5 其他有顺序编排的需求。
它有什么特性
Gobrs-Async 在开发时考虑了众多使用者的开发喜欢，对异常处理的使用场景。并被运用到电商生产环境中，在京东经历这严酷的高并发考验。同时框架中极简灵活的配置、全局自定义可中断全流程异常、内存优化、灵活的接入方式、提供SpringBoot Start 接入方式。更加考虑使用者的开发习惯。仅需要注入GobrsTask的Spring Bean 即可实现全流程接入。
Gobrs-Async 项目目录及其精简