GitHub - Memorydoc/gobrs-async: Gobrs-Async (异步任务编排框架) 是一款功能强大、配置灵活、带有全链路异常回调、内存优化、异常状态管理于一身的高性能异步编排框架。为企业提供在复杂应用场景下动态任务编排的能力。针对于复杂场景下，异步线程复杂性、任务依赖性、异常状态难控制性； Gobrs-Async 为此而生。

资源索引

Gobrs-Async 介绍

Gobrs-Async 是一款功能强大、配置灵活、带有全链路异常回调、内存优化、异常状态管理于一身的高性能多线程并发编程和动态编排框架。为企业提供在复杂应用场景下动态任务编排的能力。针对于复杂场景下，异步线程复杂性、任务依赖性、异常状态难控制性； Gobrs-Async 为此而生。

解决什么问题

在开发复杂中台业务过程中，难免会遇到调用各种中台业务数据，而且会出现复杂的中台数据依赖关系，在这种情况下。代码的复杂程度就会增加。如下图所示：

快速上手

克隆 Gobrs-Async 源代码

启动 Gobrs-Async-Example 模块下 GobrsAsyncExampleApplication 应用类

通过接口修改线程池中的配置。HTTP GET 路径：http://localhost:8888/gobrs/testGobrs，查看Idea 控制台打印结果如下：

EService Begin
AService Begin
AService Finish
BService Begin
BService Finish
FService Begin
EService Finish
CService Begin
CService Finish
FService Finish
GService Begin
GService Finish
HService Begin
HService Finish
2022-11-27 19:08:51.080  INFO 61949 --- [nio-8888-exec-1] com.gobrs.async.core.TaskLoader          : 【ProcessTrace】Total cost: 2536ms | traceId = 11702850586978176 | 【task】AService cost :302ms【state】：success; ->【task】BService cost :0ms【state】：success; ->【task】EService cost :602ms【state】：success; ->【task】CService cost :305ms【state】：success; ->【task】FService cost :2006ms【state】：success; ->【task】GService cost :105ms【state】：success; ->【task】HService cost :102ms【state】：success;
2551

执行过程

从日志中可以看出整个流程的执行过程

【ProcessTrace】Total cost: 2536ms | traceId = 11702850586978176 | 【task】AService cost :302ms【state】：success; ->【task】BService cost :0ms【state】：success; ->【task】EService cost :602ms【state】：success; ->【task】CService cost :305ms【state】：success; ->【task】FService cost :2006ms【state】：success; ->【task】GService cost :105ms【state】：success; ->【task】HService cost :102ms【state】：success;

Total cost: 任务流程总耗时
traceId: 任务流程链路id
cost: 单个任务执行时间

配置文件

server:
  port: 8888 # 端口: 8888
gobrs:
  async:
    config:
      rules:
        # 规则 是数组类型的 多组规则
        - name: "general"
          content: "AService->BService->FService->GService->HService;EService->CService;AService"
          task-interrupt: false # 局部异常是否打断主流程 默认false
          transaction: false

关闭Gobrs-Async

server:
  port: 8888 # 端口: 8080
gobrs:
async:
  enable: false # 关闭编排引擎
  rules:
    # 支持多命名空间
    - name: "ruleName" # 规则名称
      content: "AService->BService,CService,FService; BService->FService,GService;"
    - name: "azh"
      content: "AService->BService,CService,FService; BService->FService,GService;"
  task-interrupt: false #局部异常是否打断主流程

完整配置示例

gobrs:
  async:
    config:
      rules:
        # 规则 是数组类型的 多组规则
        - name: "general"
          content: "AService->BService->FService->GService->HService;EService->CService;AService"
          task-interrupt: true # 局部异常是否打断主流程 默认false
          transaction: true
        - name: "anyConditionGeneral"
          content: "AServiceCondition,BServiceCondition,CServiceCondition->DServiceCondition"
          logConfig:
            costLogabled: false # 开启任务耗时打印 log日志级别需要为 error 默认true
            errLogabled: true # 开启任务异常打印 默认true
        #  AServiceCondition 、BServiceCondition、CServiceCondition任务谁返回true 谁有资格继续往下执行
        - name: "anyConditionRule"
          content: "AServiceCondition,BServiceCondition,CServiceCondition->DServiceCondition:anyCondition"

        - name: "anyConditionRuleAppend"
          content: "AServiceCondition,BServiceCondition,CServiceCondition->DServiceCondition:anyCondition->EServiceCondition"

        # 官方场景一 https://async.sizegang.cn/pages/2f844b/#%E5%9C%BA%E6%99%AF%E4%B8%80
        - name: "caseOne"
          content: "caseOneTaskA->caseOneTaskB,caseOneTaskC,caseOneTaskD"

        # 官方场景二 https://async.sizegang.cn/pages/2f844b/#%E5%9C%BA%E6%99%AF%E4%BA%8C
        - name: "caseTwo"
          content: "caseTwoTaskA->caseTwoTaskB->caseTwoTaskC,caseTwoTaskD"
        # 官方场景三 https://async.sizegang.cn/pages/2f844b/#%E5%9C%BA%E6%99%AF%E4%B8%89
        - name: "caseThree"
          content: "caseThreeTaskA->caseThreeTaskB,caseThreeTaskC,caseFourTaskD->caseThreeTaskG;
                    caseThreeTaskA->caseThreeTaskE,caseThreeTaskF->caseThreeTaskG;"
        # 官方场景四 https://async.sizegang.cn/pages/2f844b/#%E5%9C%BA%E6%99%AF%E5%9B%9B
        - name: "caseFour"
          content: "caseFourTaskA->caseFourTaskB->caseFourTaskC,caseFourTaskD,caseFourTaskE;
                    caseFourTaskA->caseFourTaskH->caseFourTaskI,caseFourTaskJ,caseFourTaskK;"
          logConfig:
            costLogabled: false # 关闭耗时任务打印
        # 官方场景五 https://async.sizegang.cn/pages/2f844b/#%E5%9C%BA%E6%99%AF%E4%BA%94
        - name: "caseFive"
          content: "caseFourTaskA,caseFourTaskB,caseFourTaskC->caseFourTaskD:any:exclusive" # any 任意一个任务（A、B、C）执行完成后 则执行D任务
          # exclusive 避免任务执行浪费 所以 D执行完成之后 会主动 中断 未完成的任务
server:
  port: 9999 # 端口: 8080

配置文件位置

如果开发者配置较多与 springboot 配置文件放在一起有点冗余的话，可以在 resources/config 目录下创建以下配置文件都是支持的。

gobrs.yaml
gobrs.yml
gobrs.properties

规则组成

规则名称 name

规则对象又两部分组成：

规则名称
规则内容

规则名称(name) 约定规则的唯一标识符：在任务触发器开发触发任务的时候需要传递。

规则内容 content

规则内容(content) 则是规则引擎解析的核心内容，根据任务执行流程不同，任务规则配置也会不同，但是不会很复杂，详细配置流程分为一下几种场景。

日志配置 logConfig

costLogabled 流程日志打印包括耗时时间，调用链路等
errLogabled 任务执行异常日志打印

:::tip 小提示我们先说几种场景，看完之后配置规则你自己就有感觉了

注: 下方配置中的 A、B、C 是指动态任务在Spring中的Bean名称，可以使用 @Task("xxx") 定义 ruleName1 代表规则名称， :::

异常捕获

在流程配置task-interrupt时，有些开发者不希望任务执行的异常被gobrs-async包装。而是想亲自进行异常捕获，根据异常类型进行不同业务处理。此时可以配置异常抛出配置: catchable

    - name: "stopAsyncRule"
      content: "stopAsyncTaskA,stopAsyncTaskB,stopAsyncTaskC;stopAsyncTaskD->stopAsyncTaskE->stopAsyncTaskF"
      catchable: true

规则示例

场景一

如图1-1

说明任务A 执行完了之后，继续执行 B、C、D

配置

gobrs:
async:
  rules:
    - name: "ruleName1"
      content: "A->B,C,D"

场景二

如图1-2

说明任务A 执行完了之后执行B 然后再执行 C、D

配置

gobrs:
async:
  rules:
    - name: "ruleName1"
      content: "A->B->C,D"

场景三

如图1-3

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

配置

gobrs:
async:
  rules:
    - name: "ruleName1"
      content: "A->B->C->D->G;A->E->F->G"

场景四

如图1-4

说明这种任务流程 Gobrs-Async 也能轻松支持

配置

gobrs:
async:
  rules:
    - name: "ruleName1"
      content: "A->B->C,D,E;A->H->I,J,K"

场景五

如图1-5

示例一

说明 A、B、C 执行完之后再执行D

配置

gobrs:
async:
  rules:
    - name: "ruleName1"
      content: "A,B,C->D"

示例二

说明 A、B、C 任务任意一个执行完成，则立即执行任务D（谁最快执行谁执行，类似于任务流程竞争关系）此时可以使用配置关键字 :any

配置

gobrs:
async:
  ## :any 是关键字 表示任意 依赖的任务执行完成立即执行自己
  rules:
    - name: "ruleName1"
      content: "A,B,C->D:any"

示例三

说明 A、B、C 任务任意一个执行完成，则立即执行任务D（谁最快执行谁执行，类似于任务流程竞争关系）与示例不同的是，如果 D拿到执行权后，会将自身所依赖的未完成的任务强制中断执行（避免浪费资源，业务运行等）此时可以使用配置关键字 :exclusive

配置

gobrs:
async:
  ## :exclusive 是关键字
  rules:
    - name: "ruleName1"
      content: "A,B,C->D:any:exclusive"

示例四

同示例二有点类似，在示例二的场景下，无法根据某一个任务的执行成功或者失败进行后续任务的处理，示例二完全根据线程调度执行的随机顺序进行执行，即谁先执行完谁有资格继续往下执行，所以如果想执行结果的条件即： task 方法返回 true 则立即执行，返回false则不执行的判断条件进行控制。那么就有以下的实现方式。

第一步任务编写

（如果不清楚如何开发一个动态任务，请阅读下一章节：动态任务）

    @Override
    public Boolean task(Object o, TaskSupport support) {
        try {
            System.out.println("AServiceCondition Begin");
            Thread.sleep(300);
            for (int i1 = 0; i1 < i; i1++) {
                i1 += i1;
            }
            System.out.println("AServiceCondition Finish");
        } catch (InterruptedException e) {
           // log 打印
           //e.printStackTrace();
           // 返回false 则没有资格执行子任务的逻辑
           return false;
         
        }
        // 返回true 进行执行子任务的逻辑
        return true;
    }

第二步任务配置

gobrs:
async:
  ## :any 是关键字 表示任意 依赖的任务执行完成立即执行自己
  rules:
    - name: "ruleName1"
      content: "A,B,C->D:anyCondition"

注意

示例三需要和示例二配合生效，因为这两种示例是结合的一种场景。

规则总结

规则配置跟流程图几乎非常相近。

在任务分叉时使用 , 区分不同任务。
在任务流程发起时用-> 区分任务流。
每个任务流结束后用; 进行结束配置。

:::tip 如果你不习惯使用以上配置符号，想自定义在配置符号，在 Gobrs-Async 中也是支持配置的，可以根据用户使用喜欢进行灵活配置只需要在application.yml 中配置即可 :::

如何开发一个异步任务

::: warning 小提示看到这里，小伙伴们是不是已经迫不及待的想真正的体验一下 Gobrs-Async 是怎样开发一个异步任务的。那么下面由我带领大家来感受一下一个完整的 AsyncTask 需要怎么开发。 :::

普通任务

创建 Bean 继承 AsyncTask
标记 @Task 注解

任务标识

如果你想对任务进行全局拦截此时就需要对每一个任务加一个特殊的标识，这样在做全局拦截的时候，就可以区分不同的任务，从而执行不同的逻辑。或者进行不同的日志打印 MQ、链路监控等等。那么 Gobrs-Async 为你提供了支持。只需要在任务 Bean 中加上注解，则会告知框架此任务的名称即全局任务拦截，其中注解中的 name 值对应的就是全局拦截器中参数中的 taskName

@Task(name = "itemTask")

这里 AsyncTask<T, V> 是一个泛型接口

T 代表任务的参数类型
V 代表任务的返回类型

如下：

/**
 * @program: gobrs-async
 * @ClassName TaskBean
 * @description: 异步任务 任务参数 Object类型 ; 任务返回 Object类型
 **/
@Task
public class BService extends AsyncTask<Object, Object> {

    @Override
    public void prepare(Object o) {
        // 任务开始之前的操作 即task 之前
    }

    @Override
    public Object task(Object o, TaskSupport support) {
        String result = getResult(support, AService.class);
        System.out.println("拿到的结果" + result);
        System.out.println("执行BService");
        return null;
    }

    // 什么条件下触发 task执行
    @Override
    public boolean nessary(Object o, TaskSupport support) {
        return true;
    }

    // task执行成功回调用
    @Override
    public void onSuccess(TaskSupport support) {

    }
    
    // task 执行失败 回调
    @Override
    public void onFail(TaskSupport support) {

    }
}

核心任务执行

核心任务为使用者最为关注的功能方法，需要开发RPC、HTTP、IO 等消耗系统资源的业务逻辑。

@Override
public Object task(Object o, TaskSupport support) {
    // todo 业务逻辑
    return null;
}

获取依赖的任务结果

Gobrs-Async 提供了 getResult 方法，无需用户关注如何获取到的依赖结果，只需要按照使用方式便可轻松获取所需结果值

@Override
public Object task(Object o, TaskSupport support) {
    // 拿到 AService (任务bean) 返回的结果， 结果类型为String类型
    String result = getResult(support, AService.class, String.class);
    
    return null;
}

getResult 有三个参数

TaskSupport ： Gobrs-Async 所需要的核心参数，通过 task 方法中的参数透穿即可
Class: 所依赖的 Bean的 Java 类型
Class: 返回结果的类型

任务是否执行

Gobrs-Async 会根据 nessary 的返回结果，判断当前task 是否需要执行如果返回true 则需要被执行，否则返之。

例如：当参数为 cancel 时，任务不执行。

@Override
public boolean nessary(String params, TaskSupport support) {
     // 假如参数是cancel 则不执行当前任务
    if("cancel".equals(params)){
        return false;
    }
    return true;
}

任务成功回调

如果你想在任务执行完成后做一些额外的操作。例如打印日志、发送邮件、发送MQ、记录信息等。 Gobrs-Async 同样也为你考虑到了。通过实现 callback 方法。会让你轻松的拿到任务的执行结果。

@Override
public void onSuccess(TaskSupport support) {
    // todo 任务成功逻辑
}

任务失败回调

在任务异常时发送告警信息

@Override
public void onFail(TaskSupport support) {
    // todo  任务执行失败回调逻辑
}

重试任务

执行中的任务会出现异常的情况，如果使用者有对任务失败重试的需求，Gobrs-Async 也为你提供了支持,只需要在需要开启重试的任务 bean 中使用 @Task(retryCount = 10) 注解，框架则自动会为你开启重试模式。 retryCount 所跟的数字为 重试次数

@Component
@Task(retryCount = 10)
public class BService extends AsyncTask<Object, Object>  {
// ...
}

单测用例

单测地址

运行结果

2022-12-09 19:36:35.444  INFO 99720 --- [pool-2-thread-1] c.g.a.test.task.retry.CaseRetryTaskA     : caseRetryTaskA 使用线程---pool-2-thread-1
CaseRetryTaskA Begin
CaseRetryTaskA End
2022-12-09 19:36:35.458  INFO 99720 --- [pool-2-thread-1] c.g.a.test.task.retry.CaseRetryTaskC     : caseRetryTaskC 使用线程---pool-2-thread-1
2022-12-09 19:36:35.458  INFO 99720 --- [pool-2-thread-2] c.g.a.test.task.retry.CaseRetryTaskB     : caseRetryTaskB 使用线程---pool-2-thread-2
CaseRetryTaskC Begin
CaseRetryTaskB Begin
CaseRetryTaskC Finish
CaseRetryTaskB Begin
CaseRetryTaskB Begin
CaseRetryTaskB Begin
CaseRetryTaskB Begin
2022-12-09 19:36:35.475 ERROR 99720 --- [pool-2-thread-2] com.gobrs.async.core.task.AsyncTask      : [traceId:11770907551682560] caseRetryTaskB 任务执行失败

java.lang.ArithmeticException: / by zero
	at com.gobrs.async.test.task.retry.CaseRetryTaskB.task(CaseRetryTaskB.java:27) ~[classes/:na]
	at com.gobrs.async.core.task.AsyncTask.taskAdapter(AsyncTask.java:124) ~[classes/:na]
	at com.gobrs.async.core.TaskActuator.call(TaskActuator.java:145) ~[classes/:na]
	at com.alibaba.ttl.TtlCallable.call(TtlCallable.java:58) [transmittable-thread-local-2.11.2.jar:na]
	at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266) [na:1.8.0_251]
	at java.util.concurrent.FutureTask.run(FutureTask.java) [na:1.8.0_251]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_251]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_251]
	at java.lang.Thread.run(Thread.java:748) [na:1.8.0_251]

2022-12-09 19:36:35.476 ERROR 99720 --- [pool-2-thread-2] c.g.a.test.inteceptor.GobrsInterceptor   : Execute global interceptor  error

事务任务

使用者可能有这种事务需求的业务，比如 A -> B -> C 的场景，如果C执行失败了，则通知 A和B 任务进行业务回滚。则这种方式 Gobrs-Async 也是支持的事务任务也需要继承 AsyncTask, 唯一的区别就是以下三个步骤。

只需要在application.yml中配置

application.yml 配置

gobrs:
  async:
    config:
      rules:
        # 规则 是数组类型的 多组规则
        - name: "general"
          content: "AService->BService->FService->GService->HService;EService->CService;AService"
          transaction: true

注解声明

在你需要进行事务的任务上进行回滚注解， Gobrs-Async 会找到 AService 任务链之前的所有任务回调rollback 方法

@Task(callback = true)
public class AService extend AsyncTask<Object,Object>{
 // ...
}

重写默认rollback方法

//  事务回滚 具体回滚业务需要自己实现 该方法是一个默认方法 需要自己手动重写
@Override
public void rollback(DataContext dataContext) {
    //super.rollback(dataContext);
    //todo rollback business
}

注

注意 @Task(callback = true) 需要注解在可能触发异常的任务上官网示例

超时任务

何超时任务？ 顾名思义其实就是单一任务可以通过设置超时时间决定改任务是否继续执行。配置方式很简单。如下操作：

注解配置 使用 @Task注解中的 timeoutInMilliseconds 属性进行配置。

timeoutInMilliseconds 固定使用毫秒数

package com.gobrs.async.test.task.timeout;
import com.gobrs.async.core.TaskSupport;
import com.gobrs.async.core.anno.Task;
import com.gobrs.async.core.task.AsyncTask;
import lombok.SneakyThrows;
import lombok.extern.slf4j.Slf4j;

/**
 * The type A service.
 * @program: gobrs -async-starter
 * @description:
 * @author: sizegang
 */
@Slf4j
@Task(timeoutInMilliseconds = 300)
public class CaseTimeoutTaskA extends AsyncTask {

    /**
     * The .
     */
    int i = 10000;

    @Override
    public void prepare(Object o) {
        log.info(this.getName() + " 使用线程---" + Thread.currentThread().getName());
    }

    @SneakyThrows
    @Override
    public String task(Object o, TaskSupport support) {
        System.out.println("CaseTimeoutTaskA Begin");
        Thread.sleep(400);
        for (int i1 = 0; i1 < i; i1++) {
            i1 += i1;
        }
        System.out.println("CaseTimeoutTaskA Finish");
        return "result";
    }

    @Override
    public boolean necessary(Object o, TaskSupport support) {
        return true;
    }

    @Override
    public void onSuccess(TaskSupport support) {
    }
}

超时监听线程池配置

所谓的监听线程池配置即：监听任务超时的线程池的核心线程数，关于为什么要配置该参数。请查看下方的原理分析。

gobrs:
  async:
    config:
      rules:
        - name: "chain1"
          content: "taskA->taskB->taskC"
      timeout-core-size: 200 # 核心线程数量

如果不配置则取默认值，默认值计算方式如下：

    public static Integer calculateCoreNum() {
        int cpuCoreNum = Runtime.getRuntime().availableProcessors();
        return new BigDecimal(cpuCoreNum).divide(new BigDecimal("0.2")).intValue();
    }

单例测试

运行代码

运行结果

2022-12-09 16:51:41.031  INFO 37083 --- [pool-2-thread-1] c.g.a.t.task.timeout.CaseTimeoutTaskA    : caseTimeoutTaskA 使用线程---pool-2-thread-1
CaseTimeoutTaskA Begin
2022-12-09 16:51:41.355 ERROR 37083 --- [   GobrsTimer-1] com.gobrs.async.core.timer.GobrsTimer    : 

com.gobrs.async.core.common.exception.TimeoutException: task caseTimeoutTaskA TimeoutException
	at com.gobrs.async.core.TaskLoader$1.tick(TaskLoader.java:394) ~[classes/:na]
	at com.gobrs.async.core.timer.GobrsTimer.lambda$addTimerListener$0(GobrsTimer.java:80) ~[classes/:na]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[na:1.8.0_251]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) ~[na:1.8.0_251]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) ~[na:1.8.0_251]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) ~[na:1.8.0_251]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[na:1.8.0_251]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[na:1.8.0_251]
	at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_251]

2022-12-09 16:51:41.375  INFO 37083 --- [pool-2-thread-2] c.g.a.t.task.timeout.CaseTimeoutTaskB    : caseTimeoutTaskB 使用线程---pool-2-thread-2
CaseTimeoutTaskB Begin
CaseTimeoutTaskB Finish
2022-12-09 16:51:41.377  INFO 37083 --- [pool-2-thread-2] c.g.a.t.task.timeout.CaseTimeoutTaskC    : caseTimeoutTaskC 使用线程---pool-2-thread-2
CaseTimeoutTaskC Begin
CaseTimeoutTaskC Finish
2022-12-09 16:51:43.426  INFO 37083 --- [           main] com.gobrs.async.core.TaskLoader          : 【ProcessTrace】Total cost: 2413ms【task】caseTimeoutTaskA cost :312ms【state】：fail【errMsg】: sleep interrupted; ->【task】caseTimeoutTaskB cost :0ms【state】：success; ->【task】caseTimeoutTaskC cost :2011ms【state】：success;

特别说明

超时任务不支持线程复用，因为需要通过控制线程超时来进行逻辑判断，如果支持线程复用，可能会出现中断正在复用线程的任务执行。
熔断降级原理借鉴Hystrix 方式处理，如果对Hystrix不熟悉可以借鉴 Hystrix 熔断降级原理解析
因线程调度的原因，超时时间可能存在10ms内的误差，可忽略！

线程复用

试想下方任务流程中，在理想情况下最少用几个线程即可完成流程的执行？ taskA->taskB,TaskC->taskD->taskE,taskF 是6个线程还是5、4、3、2 你可能已经想到了答案是 2个线程(main线程除外)即可完成该复杂的多线程流程。为什么呢？因为在并发执行时， TaskB、TaskC 又或者是 TaskE、TaskF 都只有两个并发的任务同时存在，所以决定使用线程数量个数的根本条件是有多少个并发任务同时执行 那么看下gobrs-async 此时有多少个线程在执行

测试用例

地址

运行结果

主线程使用main
使用main
TaskA
2022-12-11 13:58:22.581  INFO 8039 --- [           main] com.gobrs.async.core.task.AsyncTask      : <11780902254572224> [taskA] execution
使用main
TaskC
使用pool-2-thread-1
TaskB
2022-12-11 13:58:22.694  INFO 8039 --- [           main] com.gobrs.async.core.task.AsyncTask      : <11780902254572224> [TaskC] execution
2022-12-11 13:58:22.694  INFO 8039 --- [pool-2-thread-1] com.gobrs.async.core.task.AsyncTask      : <11780902254572224> [taskB] execution
使用pool-2-thread-1
TaskD
2022-12-11 13:58:22.804  INFO 8039 --- [pool-2-thread-1] com.gobrs.async.core.task.AsyncTask      : <11780902254572224> [taskD] execution
使用pool-2-thread-1
使用pool-2-thread-2
TaskE
2022-12-11 13:58:22.909  INFO 8039 --- [pool-2-thread-2] com.gobrs.async.core.task.AsyncTask      : <11780902254572224> [taskE] execution
TaskF
2022-12-11 13:58:22.910  INFO 8039 --- [pool-2-thread-1] com.gobrs.async.core.task.AsyncTask      : <11780902254572224> [taskF] execution
2022-12-11 13:58:22.913  INFO 8039 --- [           main] com.gobrs.async.core.TaskLoader          : 【ProcessTrace】Total cost: 440ms | traceId = 11780902254572224 | 【task】taskA cost :103ms【state】：success; ->【task】taskB cost :103ms【state】：success; ->【task】TaskC cost :103ms【state】：success; ->【task】taskD cost :106ms【state】：success; ->【task】taskE cost :101ms【state】：success; ->【task】taskF cost :101ms【state】：success; 
耗时462

说明

通过日志可以看到 TaskC使用了 TaskA的线程执行任务，因TaskB 和 TaskC是并行的，所以此时需要开辟新线程执行TaskB，等到TaskB执行完成后， TaskD继续使用 TaskB的线程 pool-2-thread-1 执行任务，此时TaskC执行完成后发现其子任务已经被 TaskB释放后的线程拿到执行权，则不需要使用自身线程执行任务。同理任务流程继续往下执行。整个流程中一共使用 3个线程（包含main线程）。

小编对比业界多种多线程并发框架，目前只有gobrs-Async 具备线程复用的能力。具体测试用例在下方性能测试章节展示。

日志体系

使用 log.error(getFormattedTraceId(), exception); 打印的日志会自动带上 traceId， getFormattedTraceId 是 AsyncTask 提供的通用方法。

@Slf4j
@Task(failSubExec = true)
public class BService extends AsyncTask {

    int i = 10000;
    @Override
    public void prepare(Object o) {
        log.info(this.getName() + " 使用线程---" + Thread.currentThread().getName());
    }

    @Override
    public Object task(Object o, TaskSupport support) {
        System.out.println("BService Begin");
        for (int i1 = 0; i1 < i; i1++) {
            i1 += i1;
        }
        try {
            System.out.println(1 / 0);
        } catch (Exception exception) {
            log.error(getFormattedTraceId(), exception);
        }

        System.out.println("BService Finish");
        return null;
    }
}

开启全局日志打印

costLogabled：打印任务流程的全链路执行过程
errLogabled：开启任务异常打印默认true

gobrs:
  async:
    config:
      rules:
        - name: "optionalRule"
          content: "caseOptionalTaskA->caseOptionalTaskB->caseOptionalTaskC,caseOptionalTaskD->caseOptionalTaskE->caseOptionalTaskF"
          task-interrupt: false # 局部异常是否打断主流程 默认false
          transaction: false
          logConfig:
            costLogabled: true # 开启任务耗时打印 log日志级别需要为 error 默认true
            errLogabled: true # 开启任务异常打印 默认true

打印效果

CaseOptionalTaskA 任务执行
CaseOptionalTaskA 任务执行完成
2022-12-11 15:47:32.511  INFO 13458 --- [o-8888-exec-152] com.gobrs.async.core.task.AsyncTask      :  <11781331511388032> [caseOptionalTaskA] execution
CaseOptionalTaskB 任务执行
CaseOptionalTaskB 任务执行完成
2022-12-11 15:47:32.613  INFO 13458 --- [o-8888-exec-152] com.gobrs.async.core.task.AsyncTask      :  <11781331511388032> [caseOptionalTaskB] execution
CaseOptionalTaskD 任务执行
CaseOptionalTaskD任务执行完成
2022-12-11 15:47:32.718  INFO 13458 --- [o-8888-exec-152] com.gobrs.async.core.task.AsyncTask      :  <11781331511388032> [caseOptionalTaskD] execution
2022-12-11 15:47:32.718  INFO 13458 --- [o-8888-exec-152] com.gobrs.async.core.TaskLoader          : 【ProcessTrace】Total cost: 311ms | traceId = 11781331511388032 | 【task】caseOptionalTaskA cost :102ms【state】：success; ->【task】caseOptionalTaskB cost :102ms【state】：success; ->【task】caseOptionalTaskD cost :105ms【state】：success; 
cost 311

第三方日志框架集成

这里选择Tlog 日志框架，使用方法这里就不做赘述了。感兴趣的小伙伴可以到官网查看

集成使用

/**
 * 启动类
 */
@SpringBootApplication
/**
 * 使用gobrs-async-test 模块创建的任务 为了方便不重复创建任务了
 */
@ComponentScan(value = {"com.gobrs.async"})
public class GobrsAsyncExampleApplication {

    /**
     * Tlog 日志打印框架 官网: https://tlog.yomahub.com/
     */
    static {
        AspectLogEnhance.enhance();
    }

    /**
     * The entry point of application.
     *
     * @param args the input arguments
     */
    public static void main(String[] args) {
        SpringApplication.run(GobrsAsyncExampleApplication.class, args);
    }
}

规则热更新

在Gobrs-Async中默认规则只会加载一次，可能有朋友可能会有规则动态变化的需求，使用程序动态修改规则配置。而不需要重新启动程序。那么对于这种需求 Gobrs-Async 同样支持。

Gobrs-Async 默认使用CopyOnWrite 机制更新的规则配置，并发度更高。同时维护了线程安全机制。

// 规则热加载器
@Resource
private RuleThermalLoad ruleThermalLoad;

// 热更新规则任务 无需启动程序， 只需要将规则交给 规则热加载器 即可完成接入
public void updateRule(Rule rule) {
    // 单任务修改
    Rule r = new Rule();
    r.setName("ruleName");
    r.setContent("AService->CService->EService->GService; BService->DService->FService->HService;");
    ruleThermalLoad.load(rule);
    
    // 批量修改 
    List<Rule> updateRules = new ArrayList<Rule>();
    updateRules.add(r);
    // updateRules.add(...);
    ruleThermalLoad.load(updateRules);
}

验证

如果日志打印如下提示，说明配置热更新成功

com.gobrs.async.engine.RuleThermalLoad   : rule test update success

中断状态码

在流程中如果你想在某种业务场景下手动关闭任务流程执行。并在任务触发器执行完成之后，根据AsyncResult 的结果，判断不同的业务逻辑 Gobrs-Async 也为你提供了途径。用户只需要在异步任务的 task方法中手动跳用 stopAsync 透传TaskSupport 无需关注内部实现，即可轻松完成关闭主流程。

stopAsync 方法有两个参数说明如下：

TaskSupport: Gobrs-Async 使用参数，透传即可。
expCode : 中断状态码，可自定义枚举

    @Override
    public Map task(DataContext dataContext, TaskSupport support) {
        try {
            // todo 执行任务
        } catch (Exception e) {
             // todo  根据不同的异常 处理返回不同的 中断码
            if (e instanceof RedirectSimpleException) {
                // 中断任务流程
                stopAsync(support, PRODUCT_NOT_FOUND);
                return null;
            }
            stopAsync(support, SYSTEM_DEMOTION);
        }
        return null;
    }

任务触发器执行完成执行完成之后，会获取 AsyncResult 任务流程执行结果。根据不同的中断码，执行不同的业务逻辑。

Map<String, Object> params  = new HashMap();
// 任务流程名称 , 任务流程传入参数, 任务流程超时时间 
AsyncResult asyncResult = gobrsAsync.go("ruleName", () -> params, timeOut);

if(asyncResult.getExpCode().equals(100)){
    // 业务一
}else if(asyncResult.getExpCode().equals(200)){
    // 业务二
}

任务异常是否中断子任务流程

在执行 A->B->C 过程中，如果A 执行异常，Gobrs-Async 默认不会继续执行 B、C任务了，但是如果使用者有特殊需求，想要继续执行 B、C任务，这种情况Gobrs-Async 也提供支持, 只需要在 Task注解中声明 failSubExec 即可继续执行任务流程。默认 failSubExec=false

@Service
@Task(failSubExec = true) 
public class BService extends AsyncTask<Object, Object>  {
// ...
}

状态任务流程

何为状态任务流程？ 其实很好理解，比如说有 A、B、C、D 四个任务。D任务的执行依赖A、B、C三个任务，但是A B C 的执行状态有不好确定（运行时状态）如果想根据任务返回值的状态决定流程如何执行怎么办呢？比如说A B C三个任务中根据不通的业务逻辑会返回不通的任务状态。遇到这种情况可以使用Gobrs-Async 为你提供的动态状态能力选择任务执行。比如： A 业务返回true 则就执行D任务，无需关心B、C任务的执行过程。

与开发一个普通任务不通的是，返回结果需要是 AnyConditionResult 类型。

package com.gobrs.async.test.task.condition;

import com.gobrs.async.core.TaskSupport;
import com.gobrs.async.core.anno.Task;
import com.gobrs.async.core.common.domain.AnyConditionResult;
import com.gobrs.async.core.task.AsyncTask;
import org.springframework.stereotype.Component;

/**
 * The type A service.
 *
 * @program: gobrs -async-starter
 * @ClassName AService
 * @description: 任务依赖类型
 * AServiceCondition,BServiceCondition,CServiceCondition->DServiceCondition:anyCondition
 * <p>
 * 简化配置
 * <p>
 * A,B,C->D:anyCondition
 * <p>
 * D根据 A,B,C 返回的任务结果中的 AnyCondition 的state状态 进行判断是否继续执行 子任务。
 * @author: sizegang
 * @create: 2022 -03-20
 */
@Task(failSubExec = true)
public class AServiceCondition extends AsyncTask {
    /**
     * The .
     */
    int sums = 10000;
    @Override
    public AnyConditionResult<String> task(Object o, TaskSupport support) {
        AnyConditionResult.Builder<String> builder = AnyConditionResult.builder();
        try {
            System.out.println("AServiceCondition Begin");
            Thread.sleep(300);
            for (int i1 = 0; i1 < sums; i1++) {
                i1 += i1;
            }
            System.out.println("AServiceCondition Finish");
        } catch (InterruptedException e) {
            e.printStackTrace();
            //  异常返回false
           return builder.setState(false).build();
        }
        return builder.setState(true).build();
    }
}

AnyConditionResult.Builder<String> builder = AnyConditionResult.builder(); 构造函数默认创建一个 true的状态。

单测用例

单测地址

运行结果

2022-12-09 17:48:44.676  INFO 58639 --- [           main] com.gobrs.async.core.GobrsPrint          : Gobrs-Async Load Successful
CServiceCondition Begin
BServiceCondition Begin
AServiceCondition Begin
BServiceCondition Finish
AServiceCondition Finish
DServiceCondition Begin
DServiceCondition Finish
2022-12-09 17:48:45.435  INFO 58639 --- [pool-1-thread-1] com.gobrs.async.core.TaskLoader          : 【ProcessTrace】Total cost: 334ms | traceId = 11770483512420224 | 【task】BServiceCondition cost :3ms【state】：success; ->【task】AServiceCondition cost :305ms【state】：success; ->【task】DServiceCondition:anyCondition cost :0ms【state】：success; 
377
【gobrs-async】 testCondition 执行完成

可配置的全局异常拦截器

如果你想在任务流程执行过程中，某一任务执行异常，想让整个任务流程停止下来。并且可自定拦截这个异常，可在发生异常时执行报警或者打印异常等业务。

开启全局异常拦截

配置application.yml

gobrs:
  async:
    config:
      rules:
        # 规则 是数组类型的 多组规则
        - name: "general"
          content: "AService->BService->FService->GService->HService;EService->CService;AService"
          task-interrupt: true # 局部异常是否打断主流程 默认 false

异常拦截器

实现 AsyncExceptionInterceptor 接口，开发一个自定义的异常处理拦截器

/**
 * @program: gobrs-async
 * @ClassName GobrsExceptionInter
 * @description: 主流程中断异常自定义处理
 * @author: sizegang
 * @create: 2022-02-19 22:55
     * @Version 1.0
 **/
@Component
public class GobrsExceptionInter implements AsyncTaskExceptionInterceptor {

    @Override
    public CompletionException exception(Throwable throwable, Boolean state) {
        System.out.println("自定义全局异常 exceptor Interceptor 触发");
        return new CompletionException(throwable);
    }
}

默认情况

默认 Gobrs-Async 对全局拦截器开关是关闭的，如果流程中某一任务异常，只会停止所依赖该异常任务的任务停止，并调用callback 通知下游任务

可配置的全局任务拦截器

有些小伙伴可能不满足与单任务的拦截，希望有一个统一拦截的入口，而不是对每一个任务做单独的处理。那么 Gobrs-Async 也为您提供了支持。

前置全局任务流程拦截器

实现 AsyncTaskPreInterceptor 接口，开发一个自定义的任务流程前置全局拦截器。

/**
 * @program: m-detail
 * @ClassName AsyncTaskPreInterceptor
 * @description:
 * @author: sizegang
 * @create: 2022-03-24
 **/
@Component
public class TaskPreInterceptor implements AsyncTaskPreInterceptor<DataContext> {
    
     /**
     * 
     * @param params 参数
     * @param taskName 任务名称
     */
    @Override
    public void preProcess(DataContext params, String taskName) {

    }
}

后置全局任务流程拦截器

实现 TaskPostInterceptor 接口，开发一个自定义的任务流程前置全局拦截器

/**
 * @program: m-detail
 * @ClassName AsyncTaskPreInterceptor
 * @description:
 * @author: sizegang
 * @create: 2022-03-24
 **/
@Component
public class TaskPostInterceptor implements AsyncTaskPostInterceptor {
    /**
     *
     * @param result 任务结果
     * @param taskName 任务名称
     */
    @Override
    public void postProcess(Object result, String taskName) {

    }
}

自定义固定线程池

Gobrs-Async 默认使用的是 Executors.newCachedThreadPool() 的线程池，如果你想自定义线程池。满足自己的线程池需求。只需要 GobrsAsyncThreadPoolFactory 对象，如下：

@Configuration
public class ThreadPoolConfig {

    @Autowired
    private GobrsAsyncThreadPoolFactory factory;
    
    @PostConstruct
    public void gobrsThreadPoolExecutor(){
        ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(300, 500, 30, TimeUnit.SECONDS,
                new LinkedBlockingQueue());
        factory.setThreadPoolExecutor(threadPoolExecutor);
    }

实时更新线程池

开发者可能有这种苦恼，线程池在运行时是在项目初始化的时候从application.yml中加载的，一旦程序运行起来之后，就无法修改使用的线程池了。如果自己公司有分布式配置中心，可以实时更新程序内存的应用的话，那么gobrs也为你提供了入口。

在我们公司是有自己的热更新组件的，所有可以如下使用：

配置中心的线程池配置

{
corePoolSize: 210,
maxPoolSize: 600,
keepAliveTime: 30,
capacity: 10000,
threadNamePrefix: "m-detail"
rejectedExecutionHandler： "CallerRunsPolicy"
}

@Slf4j
@Configuration
public class ThreadPoolConfig {

    @Autowired
    private GobrsAsyncThreadPoolFactory factory;

    @Resource
    private DUCCConfigService duccConfigService;

    @PostConstruct
    public void gobrsThreadPoolExecutor() {
        // 从配置中心拿到 线程池配置规则 DuccConstant.GOBRS_ASYNC_THREAD_POOL 为线程池配置在配置中心的key
        String config = duccConfigService.getString(DuccConstant.GOBRS_ASYNC_THREAD_POOL);
        ThreadPool threadPool = JSONObject.parseObject(config, ThreadPool.class);
         
        // 通过gobrs-async 提供的构造器进行构造线程池
        ThreadPoolExecutor executor = ThreadPoolBuilder.buildByThreadPool(threadPool);
        factory.setThreadPoolExecutor(executor);
        listenerDucc();
    }
    
    // 监听配置中心 线程池改动
    private void listenerDucc() {
        duccConfigService.addListener(new DuccListener(DuccConstant.GOBRS_ASYNC_THREAD_POOL, property -> {
            log.warn("监听到DUCC配置GobrsAsync 线程池配置变更，property：{}", JSON.toJSONString(property.getValue()));
            ThreadPool threadPool = JSONObject.parseObject(property.getValue().toString(), ThreadPool.class);
            ThreadPoolExecutor executor = ThreadPoolBuilder.buildByThreadPool(threadPool);
            factory.setThreadPoolExecutor(executor);
            // 线程池更新成功
            log.warn("GobrsAsync thread pool update success");
        }));
    }

}

可选的执行流程

任务配置

- name: "optionalRule"
  content: "caseOptionalTaskA->caseOptionalTaskB->caseOptionalTaskC,caseOptionalTaskD->caseOptionalTaskE->caseOptionalTaskF"

如果开发者在调用时只希望执行 caseOptionalTaskD , 则在任务链中只需要执行caseOptionalTaskA、caseOptionalTaskB、caseOptionalTaskD 三个任务即可即可。其他任务不需要执行，提供了随机选择流程中任务执行的能力。

调用方式

gobrsAsync.go方法的第三个参数 Set<String> 需要传递要执行的任务 bean 名称。

    @Test
    public void testOptional() {
        Map<Class, Object> params = new HashMap<>();
        Set<String> options = new HashSet<>();
        options.add("caseOptionalTaskD"); # options中添加要执行的任务 bean 名称
        AsyncResult asyncResult = gobrsAsync.go("optionalRule", () -> params, options, 300000);
    }

测试用例

源码地址

运行结果

CaseOptionalTaskA 任务执行
CaseOptionalTaskA 任务执行完成
2022-12-11 15:47:32.511  INFO 13458 --- [o-8888-exec-152] com.gobrs.async.core.task.AsyncTask      : <0><11781331511388032> <11781331511388032> [caseOptionalTaskA] execution
CaseOptionalTaskB 任务执行
CaseOptionalTaskB 任务执行完成
2022-12-11 15:47:32.613  INFO 13458 --- [o-8888-exec-152] com.gobrs.async.core.task.AsyncTask      : <0><11781331511388032> <11781331511388032> [caseOptionalTaskB] execution
CaseOptionalTaskD 任务执行
CaseOptionalTaskD任务执行完成
2022-12-11 15:47:32.718  INFO 13458 --- [o-8888-exec-152] com.gobrs.async.core.task.AsyncTask      : <0><11781331511388032> <11781331511388032> [caseOptionalTaskD] execution
2022-12-11 15:47:32.718  INFO 13458 --- [o-8888-exec-152] com.gobrs.async.core.TaskLoader          : <0><11781331511388032> 【ProcessTrace】Total cost: 311ms | traceId = 11781331511388032 | 【task】caseOptionalTaskA cost :102ms【state】：success; ->【task】caseOptionalTaskB cost :102ms【state】：success; ->【task】caseOptionalTaskD cost :105ms【state】：success; 
cost 311

适应场景

在做 ISV (京东商城ISV组件化建设) 建设时，楼层中的多个组件可能存在着任务流程的编排，所需要的上游数据数量多少不一，所以此时就需要进行编排流程中的任务选择执行处理了。如下对每个组件进行编排数据编排处理。

插件

监控系列

skywalking 适配器

skywalking 是全链路监控平台，因为skywalking 不兼容多线程traceId，所以gobrs-async 提供skywalking插件

使用方式

pom.xml 依赖引入

<dependency>
    <groupId>io.github.memorydoc</groupId>
    <artifactId>gobrs-async-skywalking-plugin</artifactId>
    <version>1.2.9-RELEASE</version>
</dependency>

只需引入依赖即可完成与skywalking完美适配。是不是感觉很神奇！

日志系列

全链路traceId

各位开发同学已经都知道，全链路traceId是打印在日志里的方便链路追踪的序列号。有了它你可以轻松追踪线上问题，简单好用。

使用方式

pom.xml 依赖引入

<dependency>
    <groupId>io.github.memorydoc</groupId>
    <artifactId>gobrs-async-trace-plugin</artifactId>
    <version>1.2.9-RELEASE</version>
</dependency>

只需引入依赖即可完成与skywalking完美适配。是不是感觉很神奇！

静态注入

需要在SpringBoot启动类中编写

static {
    GobrsLogger.logger();
}

说明

Gobrs-Async日志插件封装了 Tlog 如有使用问题请访问Tlog官网。

加群沟通

对于这个项目，是否有什么不一样看法，欢迎在 Issue 一起沟通交流；群二维码七天会失效，可以添加作者微信进交流群

Name		Name	Last commit message	Last commit date
Latest commit History 379 Commits
doc		doc
gobrs-async-common		gobrs-async-common
gobrs-async-core		gobrs-async-core
gobrs-async-example		gobrs-async-example
gobrs-async-plugin		gobrs-async-plugin
gobrs-async-spi		gobrs-async-spi
gobrs-async-starter		gobrs-async-starter
gobrs-async-test		gobrs-async-test
LICENSE		LICENSE
README.md		README.md
pom.xml		pom.xml

License

Memorydoc/gobrs-async

Folders and files

Latest commit

History

Repository files navigation

资源索引

Gobrs-Async 介绍

解决什么问题

最新版本

快速上手

执行过程

配置文件

关闭Gobrs-Async

完整配置示例

配置文件位置

规则组成

规则名称 name

规则内容 content

日志配置 logConfig

异常捕获

规则示例

场景一

场景二

场景三

场景四

场景五

示例一

示例二

示例三

示例四

第一步 任务编写

第二步 任务配置

注意

规则总结

如何开发一个异步任务

普通任务

任务标识

核心任务执行

获取依赖的任务结果

任务是否执行

任务成功回调

任务失败回调

重试任务

单测用例

运行结果

事务任务

application.yml 配置

注解声明

重写默认rollback方法

注

超时任务

超时监听线程池配置

单例测试

运行结果

特别说明

线程复用

测试用例

运行结果

说明

日志体系

开启全局日志打印

打印效果

第三方日志框架集成

集成使用

更多细节

规则热更新

验证

中断状态码

任务异常是否中断子任务流程

状态任务流程

单测用例

运行结果

可配置的全局异常拦截器

开启全局异常拦截

异常拦截器

默认情况

可配置的全局任务拦截器

前置全局任务流程拦截器

后置全局任务流程拦截器

第一步任务编写

第二步任务配置

Packages