Gobrs-Async 动静配置化工作编排框架

作者介绍

  • dromara 开源组织成员,
  • dromara/Gobrs-Async 作者
  • 目前在某头部电商平台负责研发高并发电商平台外围架构。
  • 率领团队攻克多个技术难题,落地高并发编排框架和各类缓存技术组件。

对于Gobrs--Async

Gobrs-Async 是一款功能强大、配置灵便、带有全链路异样回调、内存优化、异样状态治理于一身的高性能异步编排框架。为企业提供在简单利用场景下动静工作编排的能力。针对于简单场景下,异步线程复杂性、工作依赖性、异样状态难控制性; Gobrs-Async 为此而生。

我的项目背景

简单的多线程调用

在开发简单中台业务过程中,难免会遇到调用各种中台业务数据, 而且会呈现简单的中台数据依赖关系,在这种状况下。代码的复杂程度就会减少。 如下图所示:

多线程工作治理

传统的FutureCompleteableFuture肯定水平上能够实现工作编排,并能够把后果传递到下一个工作。如CompletableFuture有then办法,然而却无奈做到对每一个执行单元的回调。譬如A执行结束胜利了,前面是B,我心愿A在执行完后就有个回调后果,不便我监控以后的执行情况,或者打个日志什么的。失败了,我也能够记录个异样信息什么的。

此时,CompleteableFuture就无能为力了。

传统开发模式

伪代码
  // 并行处理工作 Product 、 Item 的工作    @Resource    List<ParaExector> paraExectors;    // 依赖于Product 和 Item的 工作    @Resource    List<SerExector> serExectors;    public void testFuture(HttpServletRequest httpServletRequest) {        DataContext dataContext = new DataContext();        dataContext.setHttpServletRequest(httpServletRequest);        List<Future> list = new ArrayList<>();        for (AsyncTask asyncTask : paraExectors) {            Future<?> submit = gobrsThreadPoolExecutor.submit(() -> {                asyncTask.task(dataContext, null);            });            list.add(submit);        }        for (Future future : list) {            try {                future.get();            } catch (InterruptedException e) {                e.printStackTrace();            } catch (ExecutionException e) {                e.printStackTrace();            }        }        List<Future> ser = new ArrayList<>();        for (AsyncTask asyncTask : serExectors) {            Future<?> submit = gobrsThreadPoolExecutor.submit(() -> {                asyncTask.task(dataContext, null);            });            ser.add(submit);        }        for (Future future : ser) {            try {                future.get();            } catch (InterruptedException e) {                e.printStackTrace();            } catch (ExecutionException e) {                e.printStackTrace();            }        }    }

存在问题

以上示例中,Product 数据是通过RPC 形式获取, Item是通过HTTP 获取,大家都晓得, RPC性能要高于HTTP性能。 然而通过Future 的形式, get会阻塞期待 Item 数据返回后才会往下执行。 这样的话,图书音像、装修数据、限购数据等都要期待Item数据返回,然而这些中台并不依赖Item返回的数据, 所以会产生等待时间影响零碎整体 QPS

Gobrs-Async 解决并发场景难题

  • 简单多线程场景开发设计老本大
  • 多线程开发治理老本高
  • 传统多线程回调、监控能力缺失
  • 团队配合无对立开发标准

外围能力

架构设计

Gobrs-Async在设计时,就充分考虑了开发者的应用习惯, 没有依赖任何中间件。 对并发框架做了良好的封装。次要应用
CountDownLatchReentrantLockvolatile 等一系列并发技术开发设计。

<br/>

外围类

友情链接

更多对于 疾速接入性能压测 的报告请拜访官网查看

官网地址

Gitee

GitHub

沟通

对于这个我的项目,是否有什么不一样认识,欢送在 Issue 一起沟通交流;
欢送增加作者微信进交换群:Gang-sz

此文章版权归属dromara开源组织所有(https://dromara.org/)