叶彬：弹性可伸缩海量工作流引擎建设实践

弹性可伸缩海量工作流引擎建设实践腾讯 架构师 / 叶彬目录• 背景• 工作流引擎技术选型• 高可用架构落地实践• 落地场景与取得效果• 下一步计划与思考一、背景什么是工作流即工作流程的计算模型，为完成一个业务目标，所需要经历的一系列步骤，通常用流程图来表示日志下载规则加载规则匹配开始结束（业界通常用BPMN流程图来描述一个工作流）示例：服务器硬件故障自动诊断流程，日志下载 → 规则库加载 → 策略匹配非工作流模式下系统实现class LogsLoadTask {void handle( ) {doLogsLoad( );rulesLoadTask.handle( ); }}非工作流模式下，原始需求：日志下载 → 规则库加载 → 规则匹配class RulesLoadTask {void handle( ) {doRulesLoad( );rulesMatchTask.handle( ); }}class RulesMatchTask {void handle( ) {doRulesMatch( );}}新增需求：1）指定机型派单人工分析；2）命中指定规则派单至厂商分析非工作流模式下的问题class LogsLoadTask {void handle( ) {doLogsLoad( );if(isSpecialServer){manualAnalyTask.handle()}else{rulesLoadTask.handle( );} }}class RulesLoadTask {void handle( ) {doRulesLoad( );rulesMatchTask.handle( ); }}class RulesMatchTask {void handle( ) {doRulesMatch( );if(isSpecialRule){supplyDiagnoseTask.handle();}}}class ManualAnalyTask {void handle( ) {doManualAnalysis( );}}class SupplyDiagnoseTask {void handle( ) {doSupplierDiagnose( );}}耦合高、调整难、复用低新增逻辑块1新增逻辑块2新加业务场景，要改已有的代码。 → 这不符合开闭原则！为什么需要工作流class LogsLoadTask {void handle( ) {doLogsLoad( );rulesLoadTask.handle( );}}使用工作流模式的任务协作 - 分离任务实现和任务协作关系class RulesLoadTask {void handle( ) {doRulesLoad( );rulesMatchTask.handle( );}}class RulesMatchTask {void handle( ) {doRulesMatch( );}}日志下载规则加载规则匹配开始结束使用工作流模式，各任务只实现自身原子逻辑，协同关系使用流程图表示为什么需要工作流class LogsLoadTask {void handle( ) {doLogsLoad( );}}class RulesLoadTask {void handle( ) {doRulesLoad( );}}class RulesMatchTask {void handle( ) {doRulesMatch( );}}日志下载规则加载规则匹配开始结束人工分析供应商诊断指定机型?指定规则？是是否否class ManualAnalysisTask {void handle( ) {doManualAnalysis( );}}class SupplierAnalysisTask {void handle( ) {doSupplierAnalysis( );}}当新的逻辑需要复用已有任务节点时，只需调整流程图，无需修改已有代码BPMN流程图什么是工作流引擎将任务实现与任务协作关系分离之后，就诞生了专门维护任务协作关系的程序 - 工作流引擎◆解释任务定义◆控制状态流转◆维护内部状态◆监控/管理工作流执行所有涉及业务流转按流程完成的场景都可通过工作流引擎作为支撑主要功能工作流引擎与微服务编排微服务架构的核心是把复杂的业务系统拆分成高内聚的微服务，每个服务负责相对独立的逻辑。要实现业务价值，不是看单个服务的能力，而是要协调所有服务保证端到端业务流的成功微服务编排是指将多个微服务组合成一个完整的业务流程或服务的过程，该模式下会有一个中控引擎：◆ 按业务逻辑的蓝图，编排各微服务的调用关系◆ 监控整个业务流的状态◆ 提供机制处理单个服务的失败，保证整个业务流的成功工作流引擎很适合作为中控引擎，来编排调度微服务腾讯服务器运营历程千级服务器、无引擎、人工驻场十万级服务器、单体流程引擎、可调度原子操作万级服务器、状态机流转、沉淀脚本工具百万级服务器、分布式流程引擎、毫秒级任务调度第一阶段：人力运维阶段第二阶段：状态机流转阶段第四阶段：云原生流程引擎阶段第三阶段：单体流程引擎阶段二、工作流引擎技术选型服务器运营领域场景需求提到 “流程引擎”，联想到的都是缓慢、低吞吐的使用场景，比如人工审批任务等，但服务器运营领域的大部分是程序化自动任务，吞吐高，任务流转快，传统流程引擎无法适应工作流引擎调研主流工作流引擎产品对比发现，zeebe支持高吞吐、低延时和横向扩容，能较好地适应微服务架构场景。它不依赖外部组件、设计之初就考虑了超大规模的微服务编排问题zeebe工作流引擎顶层设计clients & job workersclient -Java sdkclient -go sdk…gatewaygatewaybrokerbrokerbrokerReplicateDistributezeebe clustergrpcData Lake & Audit Logelasticsearch…Streaming Exporterzeebe架构主要包含4大组件：client, gateway, brokers 以及 exporterszeebe工作流核心特性新老引擎顶层架构对比三、高可用架构落地实践01 基于单集群的工作流服务体系建设组建高性能流程引擎集群如何将开源组件落地到生产环境？ -- 关键：量化理解组件能力低延时查询接口、所见即所得的数据模型问题：zeebe采用全新的事件模型(CQRS)，不提供查询API扩展基本能力、封装工作流服务高吞吐高可用易用◼ 多节点、多分区并行执行◼ 异步请求处理模型，平滑应对流量峰值◼ 对等网络集群，无单点瓶颈◼ 数据副本机制，分区失败自主选主恢复◼ pub-sub模型，天然适合微服务编排◼ 流量控制台，全方位可视化跟踪流程结合业务使用场景，扩展新特性（基于实例的父子关系、基于jobworker的拦截器等），建设工作流服务体系热数据冷数据工作流服务体系快速接入02 从单集群演进到多集群，架构弹性可伸缩多集群架构演进背景分析解决1、现网问题 - 任务未调度2、问题分析 - 任务激活链路梳理3、官方技术交流，推动解决 →版本升级版本升级面临问题1、大版本未向下