带着upp闯关----性能考验

upp，企业级统一流程平台，核心功能是完成企业运营业务的流转工作。所以,upp是需要基于状态控制的，计算业务状态需要业务数据/审批记录/流程实例状态/人员等信息，在这基础之上构建出特定人员对特定业务单据的操作能力对象，如：审批/会签、取回、撤回重选流程、移交、加签、手动提交等功能。

upp的本质是业务编排，所以天生就是多状态/多事务并行事项推进。在本次梳理之前，团队都指责性能太慢，其实，做个流程平台的都知道，我们只能尽可能的让它快，但怎么也不可能快过单一业务增/删/改/查，当我们发布测试数据量时，还再纠结百万级就就出现了性能问题事项。

运行的业务如果能到100w个审批事项，那这样的企业应该时超大型企业了。我们不是oa，我们是提供合同/案件/法务/风险/合规的企业级管理软件，按照v2版本的设计，基于这百万级的数据计算状态，我们面临的可能是运行时构造出的乙级数据高频查询处理。

1.发布的分析图纸：

1.1高频使用状态机执行逻辑：

 

业务状态机极端情况下需要几十个步骤进行相关计算，最终形成特定业务下的能力操作模型，前端ui基于能力模型开放操作界面。

1.2流程发起梳理

流程发起的整个体系时非常长的，也许一条流程存在多个节点，但基于特定的业务环境，系统自动串行运行了多个节点，或者流程发起就终审了，这让流程发起时工作事项不仅仅时流程发起，需要完成整后续环节探测与自动办理功能，这些过程中需要状态机的计算结果的支撑，所以流程发起涉及了流程数据初步化/实时状态计算/业务连续办理等环节。所以，整体体系能快只能看运气......

1.3流程预设置分析

当我们在发起业务流程或流程运行途中，需要对流程进行预设设置，预设值的核心是明确所有的流转环节，并确认每个自己可控制的环节中执行人员的信息，在大多数据情况下，我们的流程能做到自动命中单一执行者。这个过程需要我们根据当前的业务数据,对流程运行路径进行分析，形成一个串行的任务办理过程，这个过程涉及了大量的内循环过程，同时也涉及了大量的组织机构数据调用，当前我们面对的组织规模在6~7百家分子公司，4到5万员工。在这个数据量下，如果没有处理好，进行了多次/高频计算后，人为构造的数据量将是超大规模的，我们在流程审批过程中，对组织结构提供了7个维度的数据支撑。

流程预设值来自老牌的OA系统，他们由于业务办理环境的人员开放性较强，让执行者在全集团选人，为了加快业务推进速度提供的统一人员选择方案，对于我们这种业务经过高度抽象的流程平台，需要手动选人的节点非常之少，如果能解决性能问题，未尝不是一个监测方向.

1.4其他流程

整个体系是一个完善的，相互牵制的链式调用环节，所以，不能单独出来说快慢，而是需要系统第梳理。

2.我们的改造方案：

基于以上的分析，代码原则上没有太大的问题，但环节过多，如果各自为阵，将无法有太大的突破。

性能改造是让程序运行变快，而在v2版本中由于业务功能是拼凑方案，忽略了上下文运行环境，在单独功能来看，他们的数据抽取是必须的，但在特定的环节中，很多数据在上层次已经获取过，所以，我们的v3版本的改造计划就是共用数据采集成果，让特定的功能优先使用外围传入的数据，如果没有传入数据，继续沿用当前的数据采集方案.

所以，本次调整在工作流引擎中引入了v3版本，并对flowable的变量采用了来自内存中的赋值方案，重整体情况来看，本次改造是凑效的。我们将继续跟进产品在生成环境中的运行情况........