【行云流水线】满足你对工作流编排的一切幻想～skr

流水线模型

众所周知，DevOps流水线（DevOps pipeline）的本质是实现自动化工作流程，用于支持软件开发、测试和部署的连续集成、交付和部署（CI/CD）实践。它是DevOps方法论的核心组成部分，旨在加速软件交付、提高质量和实现持续改进。流水线的核心是流水线模型，是实现工作流编排，执行的重要基石，一个优秀的流水线模型可以覆盖用户更多的实践场景，按照用户的所思所想支持编排相应的工作流程，通过模型的分层设计，通用原子能力的生态建设，尽可能满足用户的任意场景的需求。

流水线模型基于将整个工作流程划分为一系列连续的阶段或任务，并通过将每个阶段的输出作为下一个阶段的输入，实现高效的生产或处理流程。每个阶段专注于特定的任务，并将其结果传递给下一个阶段，以便整个过程能够连续地进行。

优秀的流水线模型特征

1.清晰的模型分层结构，易理解的模型与业务场景的映射关系。优秀的流水线模型将整个工作流程明确地划分为一系列清晰的阶段或任务。每个阶段应具有明确的输入和输出，以确保流程的连贯性和可追溯性。

2.高度的可编排性，可以覆盖尽可能多的工作流编排场景，让业务场景图形化，实例化。能够灵活地添加、删除或调整阶段，调整阶段见的关联关系，依赖关系，以适应变化的要求。

3.支持扇入（Fan-in）/扇出（Fan-out）模式，扇入可以帮助减少数据流的冗余和复杂性，将多个阶段的输出合并成一个输入，从而提高资源利用效率和整体性能；扇出可以实现并行处理和任务分配，将一个阶段的输出分发给多个后续阶段进行处理，从而提高整个流水线的吞吐量和并发性。

4.多种执行条件组合模式，满足用户需求，可以支持根据阶段状态，手动执行，流程审批等等多条件均具备的前提下，进行后续阶段执行。

---

生活中的流水线

说起生活中的流水线大家可能想到的是车间，厂房中的流水线。这个也是经常被拿出来举例的场景。但我今天不举这个例子。大家可以思考下这两个场景有什么区别？

任天堂Switch有一款叫做“胡闹厨房”的游戏，俗称“分手厨房”，据说一玩就分手。这是一款以高难度合作著称的游戏，在形形色色的厨房中，你需要和你的同伴一起克服重重难关，按照指定的顺序生产出美味佳肴，满足客人的味蕾。在游戏过程中，制作一道菜需要完成许多的步骤，这就像我们在工作中使用的流水线，流水线有个总目标，也会拆分成几个阶段来完成分阶段的目标，作为下个阶段的输入。

这里我们以“制作Pizza”的流程为例，简单的把操作拆分为4个阶段：准备食材Prepare（如鸡肉，起司，青椒等），揉面Knead（面粉，油，发酵），制作（组合准备的食材与披萨底座），最终烘焙完成。在整个流程中，前后阶段是隐含着依赖关系，并驱动每一个阶段继续执行下去。

回想我们在实际工作中的流程，往往并不能通过简单的串联并联解决问题。都是有依赖关系的执行流程，场景可能比以上例子更复杂。

---

行云流水线模型升级

在众多流水线能力中，工作流的编排和执行能力是最核心的能力，也是用户实现自定义流程配置的基础和载体。行云流水线通过把流程中的不同阶段和任务串联在一起，实现提高阶段见的连接效率，通过阶段内部的垂直领域原子能力，实现阶段内各个原子或步骤的执行效率提升。

为了能更好的支撑用户的使用场景，云原生流水线升级了工作流模型。

•从模型设计看：从原来的两层结构，升级为三层结构。增加阶段级（stage）概念，增加阶段级模型是为了解决与交付流程中各阶段（研发阶段，测试阶段，上线阶段）的对应关系。在研发阶段可以支持多需求的并行开发模式；在测试阶段支持对应测试环境的部署，自动化测试组合的复杂场景；在上线阶段，支持多应用的并行上线发布，有依赖关系的发布流程，支持常见发布策略（金丝雀/蓝绿）等。

•从执行模式看：

◦阶段级（stage）：使用“DAG依赖声明方式”描述流程，这也是业界主流的灵活编排方式，适用于编排比较复杂的流程

◦原子级（atom）：继续使用传统的“串/并行方式”，适用于简单，直接的流程

•从编排模式看：

◦图形化编排：阶段级的编排模式在业内并不多见，在交互设计和技术实现上都面临着挑战，行云流水线独创了一种新的图形化编排交互模式，提升用户操作体验

◦Yaml编排：Yaml的编排模式在业内比较常见，但编写时有一定门槛，对于熟练掌握的用户比较适合，也可以快速实现想要的流程

流水线模型与交付流程的映射

竞品分析

对比Harness，Azure，Github Actions等平台在不同pipeline维度的模型策略

| | 行云流水线 | Harness | Azure | Github | 云效 |
| 执行模式-Stage级 | DAG✅ 默认parallel | serial/parallel | DAG✅ 默认serial | DAG✅ 默认parallel | serial |
| 执行模式-Job/Atom级 | serial | serial/parallel | serial | serial | parallel |
| 编排模式-图形化 | ✅ | ✅ | ❌ | ❌ | ✅ |
| 编排模式-yaml | ✅ | ✅ | ✅ | ✅ | ❌ |

serial：只串行执行 parallel：只并行执行 serial/parallel：支持串并行组合方式，编排workflow DAG：依赖声明方式编排workflow 默认serial：无依赖声明的步骤，串行编排 默认parallel：无依赖声明的步骤，并行编排

---

平台用户的最佳实践

场景1:测试环境的按需更新与测试

测试环境一般不是独立存在的，可能也不是只更新某一个服务就可以满足测试条件的。在这种情况下，用户结合环境拓扑的概念，先基于拓扑创建一套环境，再更新所需的多个服务实例，以快速，自动化的方式实现测试环境的按需更新。通过准入流水线，创建测试环境（创建拓扑环境，更新拓扑节点等），并进行接口测试

下图为用户流水线编排界面

场景2:多维度的数据资源收集与分析

在数据分析的业务场景下，此流水线支持SRAS搜推算法服务，作为推送模型到线上的前置准备任务。用户需要收集多维度的数据源信息，通过扇入的方式聚合数据，并通过python脚本逻辑做数模型据汇总

•业务维度数据汇总：依赖于“业务数据收集”阶段➕“数据源数据收集”阶段的执行完成

•模型维度数据汇总：依赖于“数据源数据收集”阶段的执行完成

在执行每个阶段中用户在原子级别编排所需的具体执行步骤

---

云原生流水线编排功能介绍

入口：流水线列表或流水线构建记录页，点击“配置流水线”

编排界面布局：下方为阶段编排，点击其中一个stage时，上方显示stage内的原子排列顺序

1）添加阶段

图形化的“阶段编排”快速搭建流程，在每个stage的前后分别会有一个“➕”号，此加号作用是建立前后依赖关系。当点击左侧加号时，添加前置依赖阶段；点击右侧加号时，添加依赖于当前阶段的后续阶段。在点击完成的同时，弹出stage模版（分阶段选择）添加创建。

点击右侧加号，选择开发阶段中的Java单元测试模版

快速添加后续执行阶段，并在上方显示原子编排顺序

查看单元测试阶段的依赖设置，前置依赖-“DMS表管理流程处理”

2）调整依赖阶段

当调整“单元测试阶段”到DMS数据共享阶段之后执行

3）删除阶段

stage右上角直接删除并确认

4）Yaml配置中的依赖关系

现阶段开放依赖关系的查看，可通过yaml方式导出创建具备DAG模式的流水线模型，后续将开放编排yaml功能

---

Q&A

Q：流水线模型的升级与级联流水线冲突吗？

A：不冲突，从能力上看，级联流水线只具备简单的扇出能力，不具备扇入能力，也不具备复杂流程的编排能力。级联流水线更多的是支持通过流水线A触发流水线B的触发模式。级联流水线在配置上，参数传递上都比较复杂，用户使用，大规模应用成本较高。我们希望随着云原生流水线模型的升级，未来逐步替代级联流水线，并支持用户更多场景。

以上介绍了云原生流水线模型升级的价值，解决的问题，用户实践，简单上手操作等。后续随着用户使用场景的增加，我们会持续介绍用户实践，技术探索等等。欢迎大家提出建议或吐槽。

作者：京东零售 顾铮

来源：京东云开发者社区 转载请注明来源