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

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

trang chủ - Wiki
Copyright © 2011-2024 iteam. Current version is 2.132.1. UTC+08:00, 2024-09-22 13:38
浙ICP备14020137号-1 $bản đồ khách truy cập$