爬虫组件分析

目录
- 概述
- - 需求：
- 设计思路
- 实现思路分析
- - 1.flowable
  - 2.数据表的命名规则
  - 3.ACT_RU_*
  - 4.ACT_ID_*
  - 5.ACT_HI_*
  - 数据表的介绍
参考资料和推荐阅读

Survive by day and develop by night.
talk for import biz , show your perfect code,full busy，skip hardness,make a better result,wait for change,challenge Survive.
happy for hardess to solve denpendies.

Flowable引擎：
流程引擎 (流程部署、待办查询、历史任务、身份认证、流程展示) *
CMMN引擎(支持异步服务、手动激活规则、自动完成、用户事件监听器)
DMN引擎(决策引擎, 如排他网关设置条件可以进行识别并决定走向)
IDM身份识别引擎 (自带一套身份认证体系)
表单引擎 (自带一套组件编辑器,可在界面画表单,实现流程流转)
*内容引擎 (在mybatis上封装获取表元数据、流程模型等)

自定义sql

如果你的业务对于flowable的api接口还不满足，那么你可以写一些自定义的sql。如下代码示例：

//查询待办信息
public List<Task> QueryTask(String businessType, List<String> businessIds) {
	if(StringUtils.isEmpty(businessType) || ListUtil.isEmpty(businessIds)) {
		logger.warn("QueryTaskRecord请求参数为空. businessType:"+businessType+" businessIds:"+businessIds);
		return new ArrayList<>();
	}

	StringBuffer businessIdsSb = new StringBuffer();
	for(int i = 0;i < businessIds.size(); i++) {
		String businessId = businessIds.get(i);
		if (i == businessIds.size() - 1) {
			businessIdsSb.append("'" + businessId + "'");
		} else {
			businessIdsSb.append("'" + businessId + "',");
		}

	}

	StringBuffer sb = new StringBuffer();
	sb.append("SELECT RES.*FROM ACT_RU_TASK RES " +
		"LEFT JOIN ACT_RU_VARIABLE VAR ON RES.`PROC_INST_ID_` = VAR.`PROC_INST_ID_`" +
		"WHERE RES.`PROC_INST_ID_` IN (" +
			"SELECT `PROC_INST_ID_` FROM ACT_RU_VARIABLE " +
			"WHERE `PROC_INST_ID_` IN (" +
				"SELECT `PROC_INST_ID_` FROM ACT_RU_VARIABLE " +
				"WHERE `NAME_` = 'business_id' AND `TEXT_` IN (" + businessIdsSb.toString() + ")" +
			") AND `NAME_` = 'business_type' AND `TEXT_` = '" + businessType + "'" +
		") group by VAR.`PROC_INST_ID_`" +
		"order by RES.`CREATE_TIME_` desc");
	//通过传入自定义sql，返回的结果必须是ACT_RU_TASK的结果集，因为Task对应的表是ACT_RU_TASK，传入
	List<Task> tasks = taskService.createNativeTaskQuery().sql(sb.toString()).parameter("business_type", businessType).list();
	return tasks;
}

当然你也可以使用mybatis等orm框架去实现自定义sql，但是使用TaskService和HistoryService服务提供自定义sql的api是有一定区别。这点需要注意，flowable框架的自定义sql的api在执行方法的时候有事务的隔离性，它允许节点执行跳转到下一个节点操作的时候查询待办可以到下一节点的待办信息，而使用orm框架则无法做到在同一方法里执行

在这里插入图片描述
节点跳转再去查询下一节点的待办信息，因为此时的下一节点的数据还没存入到db中所以查询不到。

从架构图中可以看出，Flowable对于数据的处理是冷热分离的，热数据存在ACT_RU_系列表中，历史冷数据存在ACT_HI_系列表中，定义相关的存在ACT_RE_系列表中，而对于在途和定义相关的数据，有一层缓存，他缓存的具体实现比较复杂，这里不多赘述。

对于协议到运行态的转化，有专门一层Converter来实现，也就是说，如果你想自己定义一些协议外的东西，就需要关心这个部分。

Flowable在最新的版本中，对于历史归档和异步任务做了新的优化，具体的看下面。

新的异步执行器（ASYNC EXECUTOR）

在这里插入图片描述

在工作流中，异步执行大概分为两类，timer和message，类似于定时事件就是timer，而异步的服务任务则为message，如上图所示，“Task A”附着的边界定时事件，在时间触发之后，会执行“Escalate”任务，而“Async Service Task”在“Task A”流转之后，会启用一个异步任务去调用其服务。

在这里插入图片描述

对于一种全是异步服务任务的极端情况，如上图所示，他常常出现于服务编排之类的场景之中，我们经常性的需要同时处理一系列的任务，这时候异步调度的作用就非常重要。

为了提高性能，Flowable也采用了冷热数据分离的思想，他把数据分为了4类，异步Job，定时器Timer，挂起任务，死信队列。通过测试发现，数据库是异步任务性能低下的主要瓶颈，特别是多实例竞争Job会存在潜在的问题。在分表的时候同时加上了一个全局锁，保证了同一个实例只能由一个实例去获取并锁定job（job表中有字段会被update，内容为抢占到的实例代号），这样反而能提升不少性能。为了保证各个实例不被饿死，还调整了一系列参数。

Flowable提供了一个更加优化的冷热数据分离方案，在数据敏感性比较高的领域，我们一般会把引擎的历史记录级别调到最高（包括流程流转历史、变量变动历史、签收人变动历史等等），这些历史记录在以前是在同一个上下文中执行的，虽然在最开始设计的时候，在途数据和历史数据就冷热分离了，但从权衡在途和历史的重要性的角度来讲，历史其实不是最重要的，所以Flowable提供一系列的方法使历史记录这个行为异步化，与之对应的方法可以是jms，MQ或Spring Boot listener application。这个改动可以提升在途流程效率20%-96%。