背景
ClickHouse是一个开源的OLAP引擎,不仅被全球开发者广泛使用,在字节各个应用场景中也可以看到它的身影。基于高性能、分布式特点,ClickHouse可以满足大规模数据的分析和查询需求,因此字节研发团队以开源ClickHouse为基础,推出火山引擎云原生数据仓库ByteHouse。
在日常工作中,研发人员经常会遇到业务链路过长,导致流程稳定性和数据一致性难保障的问题,这在分布式、跨服务的场景中更为明显。本篇文章提出针对这一问题的解决思路:在火山引擎ByteHouse中构建轻量级流程引擎,来解决数据一致性问题。
使用轻量级流程引擎可以帮我们使用统一的标准来解决复杂业务链路的编排问题,不仅提高业务代码的可读性和复用性,还能更专注业务核心逻辑的开发,让整体流程更加标准化、规范化。
总结来说,使用流程引擎有以下优势:
轻量级,接入方便,内存操作,性能有保障
易维护,流程配置与业务分离,支持热更新
易扩展,丰富的执行策略及算子支持
大体思路

上图为ByteHouse企业版管理平台功能架构图。从该功能架构图可以看出,ByteHouse核心能力都是依赖ClickHouse集群,对于集群节点多、数据计算量大的业务场景,容易出现节点状态不一致的问题,因此保证ClickHouse集群间的状态一致性是我们的核心诉求。

为了保证数据一致性,ByteHouse提供了以下能力:
event engine: 事件处理中心
workflow engine:轻量级流程引擎
对账系统
保障数据一致性最简单的方式是通过状态机来监听流程执行过程:
首先,将所有的任务请求下发到event engine,由event engine将任务分发对应的handler执行,统一管理所有下发任务的生命周期,并提供异步重试、回滚补偿等功能。流量汇总到event engine以后,会让服务后续的业务扩展更加便捷。
其次,对于比较复杂的任务请求,我们可以下发到workflow engine执行,由workflow生成实例,并编排任务队列,管理流程执行实例的生命周期,统一失败回滚,失败重试。
最后,对于服务不可用等特殊场景产生的脏数据,由对账服务兜底。

架构设计
在流程监控的架构设计中,主要包含以下:
流程管理层:主要负责流程配置的解析初始化,并完成编排策略的工作
策略behavior层:编排执行节点,并下发执行任务到执行器
执行器:管理执行节点执行
执行节点:负责业务具体实现

实现方案
执行节点

流程引擎的核心为“责任链”,按照责任链上的节点顺序依次执行所有任务,所以我们需要的三个基本单元分别为:
request:入参
processlist:流程执行节点list
response:出参
在研发工作中,我们时常会遇到以下问题:
如果同时出现了一个问题,node1、node2、node3之间的数据交互如何实现?
如果node1入参、出参与node2,node3不一样该如何处理?
参数类型不同的node又该如何统一调度?
<