关于任务管理器:复杂任务中流程的解耦设计

53次阅读

共计 3352 个字符,预计需要花费 9 分钟才能阅读完成。

做事不能急,得一步异步的来;

一、业务场景

在零碎开发的过程中,必然存在耗时极高的动作,是基于申请响应模式无奈解决的问题,通常会采纳解耦的思维,并基于异步或者事件驱动的形式去调度整个流程的残缺执行;

文件工作 :在零碎解析大文件数据时,在获取工作之后,会异步解决后续文件读写流程;

两头表 :执行简单场景的数据分析时,收集完待剖析的对象之后,会并发执行各个维度的采集动作,并顺次将数据写入长期的两头表中,不便数据查问动作;

在上述场景中,基于单次申请响应无奈执行整个过程,必须对流程分段分步和异步推动,在流程中依据场景去判断,是异步有序驱动,还是异步并发解决,并基于各个节点的执行状态判断动作是否胜利。

二、工作治理

简单工作的执行周期绝对偏长,要确保稳固的执行则须要对工作做精密的设计和治理,通常会基于如下几个因素去形容工作:

  • 场景:定义工作的主题场景,便于将多种工作做对立治理和调度,例如:文件、数据、报表等;
  • 打算:对工作做好步骤的拆分,并制订和推动相应的执行打算,例如:有序调度、并发执行等;
  • 状态:针对工作和节点的执行打算,都要提供细节的状态定义,例如:开始 / 完结,进行中 / 已实现,胜利 / 失败等;

设计正当的工作构造,以便更高效的治理流程,依据主题场景做工作分类,增加相应的执行打算,依据状态跟踪工作执行过程,并对失败动作进行捕获和重试;

三、设计思路

1、同步申请响应

服务之间的通信模式个别分为:同步和异步两种;同步是指在申请端收回动作之后,会始终期待响应端实现,或者响应超时导致熔断,即在一次申请调用中耦合所有的解决流程;

服务中大部分的申请都是同步响应模式,能够进步零碎的响应速度;然而在分布式中,首先要管制超时熔断的工夫,防止在流量高峰期申请沉积,拖垮整个服务;另外对于被大量调用的公共服务,要进步并发的撑持能力,升高对申请链路的性能影响。

2、异步解耦模式

异步模式的最大长处就是实现申请和响应的齐全解耦,工作只须要触发一次开始动作,后续的流程就会逐渐的推动直到完结;各个服务节点解决逻辑不会受到整个申请链路的耗时限度;

实现异步有多种形式,例如:申请回调、公布订阅、Broker 代理等;在之前异步章节中有详细描述,这里不再赘述;异步打消了服务节点之间的依赖关系,然而也同样进步了流程的复杂性;

3、事件驱动设计

事件驱动是一个形象的概念,即通过事件的形式实现多个服务间的协同,驱动整个流程的解决逻辑;在业务层面是一种设计思维,在技术层面通常采纳公布订阅的形式,同样也能够打消服务间的强依赖关系;

事件和异步在模式上很相似,事件驱动在设计上更加精密,例如在订单场景中:将订单的状态变动作为一个事件,服务间通过消息传递的形式,顺次解决库存服务、物流服务等;因为事件携带了肯定的业务信息和状态,流程解耦更加彻底的同时复杂度也会更高。

四、实际总结

1、结构设计

在结构设计中围绕工作、节点、数据三个外围因素,以确保对工作的执行过程有残缺的跟踪和治理,要实现对工作的节点及相干的操作,具备执行重试或者间接勾销撤回的管制;

状态治理是一项很简单的工作,要掂量工作中各个状态标识是否正当,就要实时监控状态的变动,并且基于各种极其状况去验证流程,例如:重试设计、工作勾销、工作暂停。

2、高并发治理

工作型的场景加上简单的治理流程,执行工夫天然也很长,如果场景中波及到大文件的解析、或者数据调度,天然会引入工作宰割与并发执行的机制;

比拟罕用的思路:依据任务调度的集群数,对数据外围编号进行哈希计算,能够采纳取模和分段两种算法,而后基于多线程的形式并发解决各自服务内的分管工作。

3、治理模型

不论是观察者模式,或者公布订阅模型,又或者说事件驱动设计,都能够了解为生产 / 生产的关系模型,围绕生产、存储、生产三个节点做治理;

  • 生产端:负责创立具体的音讯主体,在总线模式中,通常将音讯进行入库存储,而后再执行队列推送,并跟踪该过程的状态变动,保障库和队列的一致性;
  • 音讯体:形容动作的公布方和生产方,要害的状态信息变动,惟一标识和创立工夫及版本,其余则依据场景须要定义即可;
  • 生产端:在生产时要关注的外围问题即失败重试,要防止重试机制引起数据不统一的问题,能够对生产进行加锁或者音讯状态校验,以实现幂等的成果;
  • 存储端:通常采纳数据库和消息中间件双存储的模式,并且须要保障二者动作的同时胜利或者失败,程序为先入库再执行队列推送;

整个模型在设计思路上比拟正当,然而架构的复杂性也变的很高,比方数据一致性问题、状态机制、事务、幂等性、流程中断等;整个链路须要具体的追踪记录并且可视化治理,开发弥补动作的接口,用来及时解决可能呈现的突发问题。

4、组件案例

Spring 框架自身就极具复杂度,这里单看事件模型的设计,蕴含三个外围角色:事件、公布、监听;与观察者设计模式在理念上雷同;

事件 :ApplicationEvent 根底抽象类继承自 JDK 中 EventObject 类,具体事件要继承该类;source 事件源,timestamp 产生的零碎工夫;

public class OrderState {
    // 根底因素
    private Integer eventId ;
    private String version ;
    private Long createTime ;

    // 音讯定位
    private String source ;
    private String target ;

    // 状态变动
    private Integer orderId ;
    private Integer stateFrom ;
    private Integer stateTo ;
}
public class OrderStateEvent extends ApplicationEvent {public OrderStateEvent (OrderState orderState){super(orderState);
    }
}

发布者 :Spring 定义的顶级接口 ApplicationEventPublisher,提供事件公布的能力;

@Service
public class EventService implements ApplicationContextAware, ApplicationEventPublisherAware {
    private ApplicationEventPublisher applicationEventPublisher;
    
    public void changeState (Integer orderId,Integer stateFrom,Integer stateTo){OrderState orderState = new OrderState() ;
        OrderStateEvent orderStateEvent = new OrderStateEvent(orderState) ;
        logger.info(Thread.currentThread().getName()+";"+orderStateEvent);
        applicationEventPublisher.publishEvent(orderStateEvent);
    }
}

监听者 :实现 JDK 中顶级接口 EventListener,Spring 扩大了多种事件监听器,以实现各种场景的需要,例如:有序无序、同步异步等;

@Component
public class OrderStateListener implements ApplicationListener<OrderStateEvent> {private static final Logger logger = LoggerFactory.getLogger(OrderStateListener.class) ;

    @Async
    @Override
    public void onApplicationEvent(OrderStateEvent orderStateEvent) {logger.info(Thread.currentThread().getName()+";"+orderStateEvent);
    }
}

五、参考源码

 利用仓库:https://gitee.com/cicadasmile/middle-ware-parent

编程文档:https://gitee.com/cicadasmile/butte-java-note

正文完
 0