Workflows 工作流

Workflows（工作流）的可选配置项

启动 Workflows（工作流）时，您可以传递告诉 Temporal 服务器如何处理 Workflows（工作流）的参数。这包括为 Workflows（工作流）进行设置超时、重试策略、任务队列名称、数据转换器、搜索属性和子 Workflows（工作流）可选配置项。

超时设置

有时有必要限制特定 Workflows（工作流）可以运行的时间。不过与 Activities 活动 不同， Workflows（工作流）超时主要是为了保护系统免受”失控” Workflows（工作流）的影响，这些 Workflows（工作流）最终可能会消耗太多的资源，并且 Workflows（工作流）超时不是业务逻辑考虑一部分。 Workflows（工作流）超时设置需要考虑以下事项：

1. 当 Workflows（工作流）超时时，它将被终止，而没有向其他应用程序提供任何通知。
2. 您应该始终考虑可能发生的事故造成的超时，比如如果您的 Worker 停工一小时，这种情况是可以接受的，所以要保证您的所有 Workflows（工作流）不会超时【因为他们可以继续完成他们的工作，业务逻辑并没有出问题】。如果暂时不知道多少合适，就设置为不限制超时时间开始。
3. SDK 配备定时器和睡眠 API，可直接在 Workflows（工作流）内用于处理业务逻辑相关的超时。【业务逻辑的超时重试在 SDK 里配置使用就行，和 Workflows 的配置超时不是一个设置】

Execution timeout 执行超时

• 说明： 这是应允许 Workflows（工作流）运行的最大时间，包括重试和”Continue-as-new””继续作为新”功能。默认值设置为 10 年。注意：这不同于“运行超时“。
• 用例：这最常用于在一定时间过后停止执行cron 计划 Workflows（工作流）。

Run timeout 运行超时

• 描述：这是单个 Workflows（工作流）运行限制的最大时间量。默认值设置为与执行超时【10年】相同的值。
• 用例：这是最常用来限制单个cron 计划 Workflows（工作流）调用的执行时间。如果达到此超时，并且存在相关的重试策略，则在发生任何日程安排之前将重试执行 Workflows（工作流）。如果没有重试策略，则 Workflows（工作流）程将按照cron 时间表安排。

任务超时

• 描述： 这是服务器在 Task 任务从 Task Queue 任务队列中拉出后等待 Worker 开始处理的最大时间。默认值为 10 秒。
• 用例：这主要可用于识别 Worker 是否已宕机，以便可以恢复 Workflows（工作流）并继续执行其他 Worker 。增加默认值的主要原因是容纳具有很长事件历史记录的 Workflows（工作流），该活动可能需要超过 10 秒才能加载。

重试策略

可能有些情况下，您需要从一开始就重试 Workflows（工作流）的执行。在这种情况下，您可以在启动 Workflows（工作流）时提供重试策略。不过重试策略是为了是编写 Workflows 时保证永远不会在间歇性问题【比如网络延迟】上失败。活动 已经可用于处理此类逻辑，因此重试 Workflows（工作流）是罕见的。【意思是你非要一开始就重试 Workflows 他们也没办法，但是推荐你使用 Activites 来处理】例外情况往往是cron 计划 Workflows（工作流）或其他一些从 重试 中获益的 无状态 始终运行 的 Workflows（工作流）。 :::info

注意

启动 Workflows（工作流）时重试策略不是必选项。如果不提供一个，则为 Workflows（工作流）生成默认的。但是，如果提供一个，唯一需要的配置是 initial interval初始间隔。 :::

initial interval 初始间隔

• 描述： 在第一次重试发生之前必须花费的时间。没有默认值，如果提供重试策略，则必须提供一个值。
• 用例：这用作退避系数乘以对抗的基本间隔时间。

Backoff coefficient 退避系数

• 描述： 帮助重试策略指数退避。退避系数指定重试间隔的增长比率。默认值设置为 2.0。回退系数为 1.0 表示重试间隔始终等于初始间隔。
• 用例：使用此来增加重试之间的时间间隔。通过具有回退系数，前几次重试相对较快地发生以克服间歇性故障，但随后的重检将发生越来越远的距离，以考虑更长的持久中断。使用 maximum interval 最大间隔选项来防止系数过多地增加重试间隔。

Maximum interval 最大间隔

• 说明： 指定检索之间的最大间隔。默认值是初始间隔的 100 倍。
• 用例：这对于大于 1.0 的系数很有用，因为它可防止间隔以指数级无限增长。

Maximum attempts 最大尝试

• 说明： 指定在出现故障时可以执行 Workflows（工作流）的最大尝试次数。如果超出此限制，则 Workflows（工作流）将失败，无需再次尝试。默认值是无限的。将其设置为0也意味着无限。
• 用例：这可以用来确保重审不会无限期地继续。但是，在大多数情况下，我们建议依靠执行超时来限制检索的持续时间，而不是此选项。

Non-retryable error reasons 不可重试的错误原因

• 描述：指定不应重试的错误。
• 用例：您知道的可能存在的一些错误，不应触发重试【比如重试就不保证幂等】。在这种情况下，您可以指定它们，以便如果发生错误，则不会重试 Workflows（工作流）。

Task Queue 任务队列

唯一需要的 Workflows（工作流）选项参数是 Task Queue 任务队列的名称。阅读任务队列概念页面，了解更多。

从本质上讲，任务队列是一种机制，让收到任务的 Worker 知道下一步要执行哪一段代码。 Workflows（工作流）只能使用一个任务队列，因此 Worker 也只能订阅单个任务队列一样。从开发人员的角度来看，它只是一个简单的字符串值。

Workflow Id

您可以将自定义 Workflow Id 分配 Workflow。此 Id 用于业务级别标识，例如客户Id或订单Id。Temporal Server强制保证 Id 的唯一性，并在 Namespace 命名空间内有基于工作流 Id 重用策略。

有重用策略但是尝试启动具有相同工作流 Id 的工作流会报 “Workflow execution already started工作流执行已开始” 错误。请注意，无论重用策略如何，都不可能有两个具有相同工作流 Id 的开放工作流。重用策略仅适用于已关闭的工作流。

:::info

注意

工作流由其 Namespace, Workflow Id, and Run Id 唯一标识。 :::

Allow duplicate failed only policy 只允许重复失败策略

• Description: 只允许工作流仅在使用具有相同ID的先前执行的工作流程失败时启动.
• Use case: 在需要重新执行失败的工作流程时使用此策略并保证未重新执行成功完成的工作流程。

Allow duplicate policy 允许重复策略

• Description: 允许工作流程独立于以前的工作流，无论其完成状态如何，都具有相同的 ID。 这是默认策略。
• Use case: 如果可以再次执行使用相同的工作流 ID 执行工作流时使用此功能。

Reject duplicate policy 拒绝复制策略

• 描述：指定这意味着不允许使用相同的 Workflows（工作流） ID 来启动其他 Workflows（工作流）。
• 使用案例：当每个 Workflows（工作流） ID 在名称空间保留期内只能执行一个 Workflows（工作流）时，请使用此。

Cron 调度 (定时任务调度)

当您在启动 Workflows（工作流）时指定一个 cron schedule 定时任务时， Temporal 服务器将 Workflows（工作流）视为 cron 工作。确保 Workflows（工作流）按特定时间表运行非常简单。

服务器仅在当前运行完成、失败或已过期后安排下一次运行。如果提供重试策略，并且 Workflows（工作流）失败或已过期，则将根据重试策略重新尝试 Workflows（工作流）。在重试 Workflows（工作流）时，服务器不会安排下一次运行。如果下一个预定运行将在 Workflows（工作流）仍在运行（或重试）时发生，则服务器将跳过该计划运行。在终止或取消之前，cron Workflows（工作流）不会停止。

:::info

注意

调度基于 UTC 时间。 :::

搜索属性

启动 Workflows（工作流）时，您可以将其配置为可用于复杂 Workflows（工作流）可见性搜索查询的搜索属性。阅读搜索属性指南，了解如何启用 Workflows（工作流）中的搜索属性。

Memos (备注)

您还可以将非索引信息位附加到 Workflows（工作流）（称为 Memos(备注)）上，该信息在 Workflows（工作流）搜索结果中可见。

子 Workflows（工作流）

如果 Workflows（工作流）是由另一个 Workflows（工作流）启动的，则它被视为子 Workflows（工作流）。子 Workflows（工作流）的完成或失败报告给启动它的 Workflows（工作流）（父 Workflows（工作流））。

以下是一些更常见的原因列表，其中列出了您可能希望将代码执行分解为”子 Workflows（工作流）”的原因：

• 使用不同的一组 Workers 执行代码。
• 多个 Workflows（工作流）调用启用。
• 变通方法用于解除事件历史记录大小限制。
• 在 Workflows（工作流） ID 和其他资源之间创建一对一映射。
• 执行一些周期性逻辑。

您不想使用子 Workflows（工作流）的主要原因之一是缺乏与父 Workflows（工作流）共享状态。Parent (父工作流)和子 Workflows（工作流）只能通过异步信号进行通信。如果执行逻辑在 Workflows（工作流）之间紧密耦合，则使用可以依赖共享对象状态的单个 Workflows（工作流）可能更容易。

ParentClosePolicy 父停止策略

创建子 Workflows（工作流）时，您可以定义 ParentClosePolicy父停止策略如果孩子的 Parent (父工作流)停止执行，则终止、取消或放弃 Workflows（工作流）执行：

• ABANDON：当家长停止时，不要对子 Workflows（工作流）做任何事情。
• TERMINATE：当 Parent (父工作流)停止时，终止子 Workflows（工作流）。
• REQUEST_CANCEL：当 Parent (父工作流)停止时，子 Workflows（工作流）

您可以为每个孩子设置策略，这意味着您可以选择不按每个孩子进行终止/取消传播。这对于异步启动子 Workflows（工作流）很有用（请参阅此处的相关问题或相应的 SDK 文档）。

常见问题

Workflows（工作流）的运行时间是否有限制？
旨在无限期运行的 Workflows（工作流）程应谨慎编写。 Temporal 存储 Workflows（工作流）执行的整个生命周期的完整事件历史记录。服务器强制执行最多 50，000 个事件，您应该尽量避免接近此限制： Temporal 服务器在每 10，000 个事件时发出警告。

处理无限期运行 Workflows（工作流）的惯用方法是使用”Continue-as-new”功能，该功能在所有 SDK 中都可用。例如，对于大容量 Workflows（工作流），合理的截止点可能是每天一次。

“Continue-as-new”功能会完成当前的 Workflows（工作流）Execution，并自动使用相同的 Workflows（工作流） ID 启动新的 Execution，会有一个不同的 Run ID ，通过它以继续执行相应的参数。这使事件历史记录保持在限制之内，但继续执行逻辑。

:::info 注意：
使用Go SDK 的 Signals，您应该确保在信号 Channel 上进行异步 Drain，否则信号将会丢失。(意思是 Channel 里是有缓存的信号的，记得消费完） :::

如何处理 Workflows（工作流）中的”工作程序”失败/重新启动？
不需要。 Workflows（工作流）代码完全不受任何 Worker 故障或停机影响。一旦 Worker 或 Temporal Server 恢复， Workflows（工作流）的当前状态将完全恢复并继续执行。 Workflows（工作流）可能失败的唯一原因是 Workflows（工作流）业务代码抛出一个异常，而不是基础设施的宕机中断。

Workers 能否处理比缓存大小或支持线程数量更多的 Workflows（工作流）实例？
是的，可以。但是，代价是延迟增加。

Worker 是无状态的，因此任何处于受阻状态的 Workflows（工作流）都可以安全地从 Worker 身上删除。稍后，当需要时（以外部事件的形式）可以在相同或不同的” Worker “上复活。因此，单个 Worker 可以处理数百万次的 Workflows（工作流）的执行，只要它的消费速率可以跟上信息生产速率，并且可以接受延迟稍高的情况。

如何负载测试 Workflows（工作流）执行？
Temporal 压力测试博客文章涵盖了许多不同的场景，根据这些场景可以测试 Workflows（工作流）执行。