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

弹性可伸缩海量工作流引擎建设实践 腾讯架构师/叶彬 目录 •背景 •工作流引擎技术选型 •高可用架构落地实践 •落地场景与取得效果 •下一步计划与思考 一、背景 什么是工作流 即工作流程的计算模型，为完成一个业务目标，所需要经历的一系列步骤，通常用流程图来表示 （业界通常用BPMN流程图来描述一个工作流） 示例：服务器硬件故障自动诊断流程，日志下载规则库加载策略匹配 日志下载 规则加载 规则匹配 开始 结束 非工作流模式下系统实现 非工作流模式下，原始需求：日志下载规则库加载规则匹配 classRulesLoadTask[voidhandle()[ doRulesLoad();rulesMatchTask.handle(); ] ] classRulesMatchTask[voidhandle()[ doRulesMatch(); ] ] classLogsLoadTask[voidhandle()[ doLogsLoad();rulesLoadTask.handle(); ] ] 新增需求：1）指定机型派单人工分析；2）命中指定规则派单至厂商分析 非工作流模式下的问题 耦合高、调整难、复用低 新增逻辑块1 classSupplyDiagnoseTask[voidhandle()[ doSupplierDiagnose(); classManualAnalyTask[voidhandle()[ doManualAnalysis(); ] ] ] ]新增逻辑块2 classLogsLoadTask[voidhandle()[ doLogsLoad();if(isSpecialServer)[manualAnalyTask.handle() ]else[rulesLoadTask.handle(); ] classRulesLoadTask[voidhandle()[ doRulesLoad();rulesMatchTask.handle(); ] ] classRulesMatchTask[voidhandle()[ doRulesMatch();if(isSpecialRule)[supplyDiagnoseTask.handle(); ] ] ] ] ] 新加业务场景，要改已有的代码。→这不符合开闭原则！ 为什么需要工作流 使用工作流模式的任务协作-分离任务实现和任务协作关系 日志下载规则加载规则匹配 开始结束 classLogsLoadTask[voidhandle()[ doLogsLoad();rulesLoadTask.handle(); ] ] classRulesLoadTask[voidhandle()[ doRulesLoad();rulesMatchTask.handle(); ] ] classRulesMatchTask[voidhandle()[ doRulesMatch(); ] ] 使用工作流模式，各任务只实现自身原子逻辑，协同关系使用流程图表示 为什么需要工作流 当新的逻辑需要复用已有任务节点时，只需调整流程图，无需修改已有代码 classManualAnalysisTask[voidhandle()[ doManualAnalysis(); ] ] classSupplierAnalysisTask[voidhandle()[ doSupplierAnalysis(); ] ] BPMN流程图 人工分析供应商诊断 是是 日志下载 否 指定机型? 规则加载规则匹配 否 指定规则？ 开始结束 classLogsLoadTask[voidhandle()[ doLogsLoad(); ] ] classRulesLoadTask[voidhandle()[ doRulesLoad(); ] ] classRulesMatchTask[voidhandle()[ doRulesMatch(); ] ] 什么是工作流引擎 将任务实现与任务协作关系分离之后，就诞生了专门维护任务协作关系的程序-工作流引擎 解释任务定义 控制状态流转 维护内部状态 监控/管理工作流执行 主要功能 所有涉及业务流转按流程完成的场景都可通过工作流引擎作为支撑 工作流引擎与微服务编排 微服务架构的核心是把复杂的业务系统拆分成高内聚的微服务，每个服务负责相对独立的逻辑。要实现业务价值，不是看单个服务的能力，而是要协调所有服务保证端到端业务流的成功 微服务编排是指将多个微服务组合成一个完整的业务流程或服务的过程，该模式下会有一个中控引擎： 按业务逻辑的蓝图，编排各微服务的调用关系 监控整个业务流的状态 提供机制处理单个服务的失败，保证整个业务流的成功 工作流引擎很适合作为中控引擎，来编排调度微服务 第一阶段：人力运维阶段 千级服务器、无引擎、人工驻场 第二阶段：状态机流转阶段 万级服务器、状态机流转、沉淀脚本工具 第三阶段：单体流程引擎阶段 十万级服务器、单体流程引擎、可调度原子操作 第四阶段：云原生流程引擎阶段百万级服务器、分布式流程引擎、毫秒级任务调度 腾讯服务器运营历程 二、工作流引擎技术选型 服务器运营领域场景需求 提到“流程引擎”，联想到的都是缓慢、低吞吐的使用场景，比如人工审批任务等，但服务器运营领域的大部分是程序化自动任务，吞吐高，任务流转快，传统流程引擎无法适应 工作流引擎调研 主流工作流引擎产品对比发现，zeebe支持高吞吐、低延时和横向扩容，能较好地适应微服务架构场景。它不依赖外部组件、设计之初就考虑了超大规模的微服务编排问题 zeebe工作流引擎顶层设计 zeebe架构主要包含4大组件：client,gateway,brokers以及exporters clients&jobworkers client-Javasdk client-gosdk … grpc gateway Distributegateway zeebecluster broker Replicate broker broker StreamingExporter DataLake&AuditLog elasticsearch … 新老引擎顶层架构对比 zeebe工作流核心特性 三、高可用架构落地实践 01基于单集群的工作流服务体系建设 组建高性能流程引擎集群 如何将开源组件落地到生产环境？--关键：量化理解组件能力 低延时查询接口、所见即所得的数据模型 问题：zeebe采用全新的事件模型(CQRS)，不提供查询API 易用 高可用 pub-sub模型，天然适合微服务编排 流量控制台，全方位可视化跟踪流程 对等网络集群，无单点瓶颈 数据副本机制，分区失败自主选主恢复 扩展基本能力、封装工作流服务 热数据 冷数据 高吞吐 多节点、多分区并行执行 异步请求处理模型，平滑应对流量峰值 结合业务使用场景，扩展新特性（基于实例的父子关系、基于jobworker的拦截器等），建设工作流服务体系 工作流服务体系快速接入 02从单集群演进到多集群，架构弹性可伸缩 多集群架构演进背景 分析 1、现网问题-任务未调度2、问题分析-任务激活链路梳理 解决 3、官方技术交流，推动解决版本升级 版本升级面临问题 1、数据存储如何兼容数据格式变化 2、与zeebe引擎的交互协议如何兼容新旧 问题 1、大版本未向下兼容：zeebe引擎1.x版本未向下兼容0.x版本，非简单原地升级版本 2、原生zeebeclient限制：不同业务微服务通过sdk仅能连接一个工作流引擎集群 1、不同微服务不可能同一时间点升级完毕 2、无法保证每个微服务在升级新版本的时候， 老版本中的实例全部已结束了 问题 解决思路 核心原则：升级过程中，需保证“老集群中存量运行中的实例”能正常走完余下流程，同时不影响新创建实例 解决思路 推导 摒弃当前的单点架构设计，设计多活模式。支持同一时间点， 同一个业务微服务可同时与新旧两个zeebe引擎交互工作 多集群架构设计，支持业务无缝升级 多集群实现难点 待升级集群 zeebesdk重耦合引擎，交互操作只能一对一 1、业务侵入大，难维护 2、api服务请求转发无法区分目标集群 新的问题 思路 加载多个sdk 重点问题攻克：集群解耦&流量精准路由 多集群架构重点问题攻克1-业务解耦zeebe集群 在业务与zeebe集群之间引入proxy，代理client与zeebe的job交互行为 后 job拉取行为简单且高频保持grpc不变 job操作行为复杂，相对低频改用http 前 改造 多集群架构重点问题攻克2-流量精准路由 建设pollservice，遍历后端所有集群应对activateJob请求 问题 completeJob等请求如何精准路由到目标集群？ 思路 唯一ID标识 ID冲突 实例id、任务id是唯一标识一个任务或者实例的key，由zeebe引擎自增生成，多集群情况下，存在ID冲突 思路 分析 修改ID解析逻辑，保证不同集群的实例/任务ID不重复 ID冲突问题解决 修改zeebe原生ID编码规则，新增clusterID解析逻辑 在api服务中，解析请求体中的实例/任务id获取集群id，对该请求精确转发至对应的集群 前 流量路由前后对比 后 多集群弹性可伸缩架构落地 03秒级自动容灾，提升整体高可用 全链路异地容灾 如果工作流服务体系没有完善的全链路容灾机制，海量服务器运营在故障时很可能会进入灾难性的死循环 全链路容灾 得益于多集群架构落地，实现全链路异地双活部署 双热集群秒级自愈，工作流服务实现业务零感知高可用 双热集群部署模式，集群故障时，秒级自动切换，业务零感知 四、落地场景与取得效果 峰值10W+QPS，支撑服务器数亿级自动化作业 腾讯内部集群规模最大的工作流服务，应用于海量服务器数亿级自动化作业场景 支撑流程类型数 数百 支撑作业类型 数千 已完成流程实例量 数千万 已完成服务器作业量 数亿 毫秒级任务调度，满足业务SLA 多层级流程实例嵌套，流程灵活可复用 服务器运营流程存在多层嵌套金字塔关系，对于这类多层嵌套的复杂流程，流程引擎建设基于实例维度的父子关系，提供了无层级上限限制的多层嵌套流程调度能力 全链路可视化控制台，提升开发运维效率 在服务器运营流程中，因硬件、机房环境等问题会导致流程无法自动完成，需要人工介入处理，为支持流程中的人工干预，提供服务器全链路可视化控制台，提供流程运营操作，方便运维人员随时处理，大大提升了运维效率 首创多集群架构，弹性可伸缩 弹性扩缩容完美支持，目前服务已容器化，一键部署，秒级生效，快速响应容灾、扩容等场景 五、下一步计划与思考 多集群管理，提升集群利用率 运行中实例跨子集群断点续跑能力建设，支持长尾流程集群迁移 工作流与LLM 期待与大家一起探讨交流