Cadence有哪些不同服务？历史服务作为核心工作流引擎如何工作？

三类核心微服务定义 #

Cadence集群的核心由三类微服务组成，各职责明确：

• 前端服务（FE，Frontend Service）：集群统一入口网关，无状态可水平扩展。负责所有外部请求的接入校验、限流、权限校验以及路由转发，所有客户端、工作进程、管理端的请求都需要先经过FE处理，再转发到对应后端服务。
• 匹配服务（MS，Matching Service）：任务分发层，无状态可水平扩展。负责维护所有任务队列的状态，将待执行的决策任务、活动任务和轮询拉取任务的工作进程做匹配，把任务下发到空闲的工作节点执行。
• 历史服务（HS，History Service）：Cadence的核心工作流引擎，有状态服务，通过分片机制实现水平扩展。负责所有工作流实例的生命周期管理、执行历史存储、状态维护，是整个集群的状态核心。

三类服务协同工作流程 #

三类服务按照工作流执行的链路依次协作：

1. 客户端发起工作流启动请求后，先进入FE做参数校验，校验通过后FE根据工作流ID的哈希结果，将请求转发到对应分片的历史服务。
2. 历史服务初始化工作流实例状态，生成首个决策任务，将任务投递到匹配服务对应的任务队列中。
3. 匹配服务持有任务后，等待对应任务队列的工作进程发起轮询请求，匹配到空闲工作进程后将决策任务下发。
4. 工作进程执行完决策任务后将结果回传给FE，FE转发到对应历史服务分片，历史服务根据决策结果更新工作流状态：如果需要执行活动任务，就生成活动任务投递到匹配服务；如果决策判定工作流执行完成，就标记工作流为终态，执行链路结束。
5. 活动任务执行完成后结果同样经过FE回传给历史服务，历史服务再生成新的决策任务，重复上述流程直到工作流进入终态。

历史服务核心工作逻辑 #

作为核心工作流引擎的历史服务，采用事件溯源的核心设计模式运行：

• 所有工作流实例按ID哈希分配到固定的历史服务分片，同一工作流的所有状态变更都由同一个分片处理，避免分布式一致性问题。
• 所有工作流的状态变更、执行动作都会先以事件的形式持久化存储，不会直接修改工作流当前快照状态，工作流的最新状态始终可以通过回放全量历史事件生成，保证状态的一致性和可追溯性。
• 内部维护独立的定时器队列，处理工作流的超时判定、定时任务触发、重试延迟等待等定时逻辑，到触发时间后自动生成对应事件更新工作流状态，触发后续任务调度。
• 所有工作流状态查询、历史执行记录查询的请求，最终都会由FE转发到对应分片的历史服务，返回查询结果。

内容的提问来源于stack exchange，提问作者Long Quanzheng