7.5. 创建无服务器工作流时的最佳实践


按照基于 Serverless 工作流特定语言(DSL)原则的这些最佳实践,创建有效的无服务器工作流来设计、处理数据和管理错误。这些原则可帮助您构建强大的工作流。

工作流设计原则

Serverless 工作流 DSL 优先选择在编写工作流时清晰和易用性。

行为的优先级
在开发工作流或 API 时,请确保需要作者(工作流写入器)。该行为按照以下顺序进行优先级排序: Authors > Operators > implementedors > Specifications writers。
Linguistic fluency 和 clarity
  • 使用 call、Emit、for、forkRaise运行设置切换Wait 等操作。 这些简单、通用理解的术语使您的工作流易于阅读和理解。
结构和可扩展性
  • 使用隐式默认行为来减少冗余。
  • 如果组件不可重复使用,则声明组件内联,以保持自包含的定义。
  • 使用外部引用导入和重复使用共享组件,可促进模块化设计。
  • 优先选择更严格的枚举的灵活性,以确保在不同运行时环境之间具有可扩展性和适应性。
数据流和运行时管理
控制数据流对于高效的工作流至关重要。任务是工作流的基本计算单元。域特定语言(DSL)定义运行时必须执行的几个默认任务类型。其中包括 Do,Listen,Raise,Run,Try, 和 Wait
安全性和错误处理
Secrets
请谨慎使用 Secret。避免在调用输入中直接传递它们,因为这可能会公开敏感信息。
容错和错误处理
Serverless 工作流设计时具有恢复故障的弹性。
Orchestrator UI 集成最佳实践

要使工作流结果有效地显示在 Orchestrator UI 中,并便于工作流链,您必须根据 WorkflowResult 模式构建输出数据。另外,包括任何错误信息作为工作流输出的一部分,以便 UI 和后续工作流可以相应地处理它们。

工作流输出模式
结果放置
用于后续处理的主要输出必须放在 data.result 属性下。
模式参考
您的输出架构文件(schemas/workflow-output-schema.json)必须引用 workflow Result 模式。
输出定义

在工作流定义中包含 outputs 部分。本节包含 UI 将显示的人类可读键/值对。

工作流结构:

id: my-workflow
version: "0.8"
specVersion: "0.8"
name: My Workflow
start: ImmediatelyEnd
dataInputSchema: schemas/basic__main-schema.json
extensions:
  - extensionid: workflow-output-schema
    outputSchema: schemas/workflow-output-schema.json
functions:
  - name: print
    type: custom
    operation: sysout
  - name: successResult
    type: expression
    operation: '{
      "result": {
      "message": "Project " + .projectName + " active",
      "outputs":[]
      }
      }'
start: "successResult"
states:
  - name: successResult
    type: operation
    actions:
      - name: setOutput
        functionRef:
          refName: successResult
    end: true
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2026 Red Hat
返回顶部