第 4 章 支持服务
4.1. 作业服务
Job 服务在云环境中调度并执行任务。独立的服务实现这些任务,可以通过任何受支持的交互模式启动,包括 HTTP 调用或 Knative 事件交付。
在 OpenShift Serverless Logic 中,作业服务负责控制时间触发操作的执行。因此,您可在工作流中使用的所有基于时间的状态都由工作流和作业服务之间的交互处理。
例如,每次工作流执行达到配置超时的状态时,会在作业服务中创建对应的作业,并在满足超时时执行 HTTP 回调来通知工作流。
作业服务的主要目标是管理活动的作业,如需要执行的计划作业。当作业达到其最终状态时,作业服务会将其删除。要在永久存储库中保留作业信息,作业服务会生成可由外部服务记录的状态更改事件,如 Data Index Service。
如果使用 OpenShift Serverless Operator 部署工作流,则不需要手动安装和配置 Job 服务。Operator 会自动处理这些任务,并管理每个工作流需要与之连接的所有必要配置。
4.1.1. 作业服务领导选举过程
Job 服务作为单例服务运行,这意味着只有一个活动实例可以调度和执行作业。
为了防止将服务部署到云中(多个实例可能正在运行)时发生冲突,作业服务支持领导选举过程。只有作为领导机选择的实例才会管理外部通信,以接收和调度作业。
非领导实例处于待机状态,但会继续尝试通过选举过程成为领导。当新实例启动时,它不会立即假定领导。相反,它进入领导选举过程来确定是否可以接管领导角色。
如果当前的领导响应没有响应,或者关闭了,另一个正在运行的实例将接管为领导。
这个领导选举机制使用底层持久性后端,目前仅在 PostgreSQL 实现中被支持。