Spring Cloud Data Flow：微服务时代的数据管道编排与任务调度实践

微服务时代，谁来解决数据管道的编排问题

先把话说在前头：Spring Cloud Data Flow 不是又一个大而全的微服务框架，它是 Spring Cloud 体系里专门解决"数据管道编排与任务调度"的那一块拼图。

我第一次意识到需要它，是在一个电商项目做微服务改造的中期。服务调用的部分，Feign、Nacos 这些都已经收拾得妥妥当当，但数据流转这块还停留在远古时代：订单库到报表库的同步靠一个 Shell 脚本挂着 crontab，日志清洗靠另一个服务每 5 分钟轮询一次消息队列，任务失败没有任何统一告警，谁改了代码、是不是影响了下游，全靠同事之间吼一嗓子。那段时间我几乎每天都在想两个问题：这些数据管道能不能像微服务一样被管理起来？有没有一套东西能让我们把"定义一条管道、部署一条管道、运维一条管道"做成规范化动作？

后来我花了两周时间把 Spring Cloud Data Flow 完整地过了一遍，从源码到部署再到社区实践，又用了大概三个月在真实环境里跑业务。这篇文章不是照抄官方文档的翻译稿，而是把我踩过的坑、比较过的方案、最终留下的生产实践，按一个从业者的视角整理出来。适合正在做微服务化、又对数据集成管道有真实需求的团队，也适合那些想搞明白 Stream、Task、Skipper 这些概念到底怎么串起来的开发同学。

1. 先搞清楚要解决的问题：为什么 Spring 生态要出一个 Data Flow

1.1 我当时遇到的场景：API 微服务化了，数据流转却还靠脚本

先说个很常见的项目背景。团队花了半年时间把单体系统拆成了一堆微服务，每个服务都有自己的数据库，服务间调用通过注册中心走 HTTP 或者 Feign，接口层面确实规范了。但往后退一步看数据侧：

订单服务的数据要同步到数仓做分析，商品服务的数据变更要推给下游三个系统，用户标签每天凌晨要跑一次批量任务。这些需求听起来简单，做起来全是零散逻辑。有人用 Spring Integration 写了一个文件监听服务，有人直接用 JDBC 定时拉数据，还有一条管道是另一个部门用 Python 脚本撑着的。最让我头疼的是，每个管道都是一个"孤岛"：

• 没有统一的运行状态视图，某个管道挂了，往往是下游问过来才发现。
• 改动一条管道要发版重启，而它的运行环境可能还部署在一台没人维护的虚拟机上。
• 新来的同事想复用已有的数据处理逻辑，根本不知道哪里有、哪里没有。

说白了，我们缺的不是写代码的能力，而是把"数据管道"当成一类标准化的服务去定义、部署和运维的能力。这正是 Spring Cloud Data Flow 想填补的空缺。

1.2 从 Spring Batch 到 Data Flow：一个编排平台的诞生逻辑

有人可能疑惑，Spring 生态里已经有 Spring Batch、Spring Integration、Spring Cloud Stream，为什么还要再来一个 Data Flow？这里有演进逻辑。

Spring Batch 解决的是批处理问题，比如大批量数据读写、事务管理、失败重试，它擅长的是"一个批处理作业怎么实现得可靠"。Spring Integration 解决的是消息路由和系统集成，企业集成模式那一套，它擅长的是"消息怎么在系统之间流转"。再往后 Spring Cloud Stream 出现，把消息收发封装成 Source、Processor、Sink 三种模型，让微服务可以通过 Binder 接入 Kafka 或 RabbitMQ。

这三者解决的都是"单个数据处理应用怎么做"的问题。但到了微服务规模，几十条数据管道同时存在，你就需要有人回答另一个层面的事：

• 这条管道的应用清单是什么？
• 谁来负责部署这些应用？
• 每个应用从哪个版本升级到哪个版本？
• 管道跑挂了怎么回滚？
• 某条管道占用了多少资源、当前什么状态？

Data Flow 做的事情就是把 Spring Batch、Spring Integration、Spring Cloud Stream、Spring Cloud Task 这些组件统一收口到一个平台下面，对外提供一套 DSL、一个 Dashboard 控制台、一组 REST API，让数据管道的定义和运维变成"平台能力"，而不是散落在各个服务里的重复代码。

Spring Cloud Data Flow 的前身是 Spring XD，如果你对老项目有印象，会发现它的管道/过滤器架构一脉相承。到了 Spring Cloud 时代，它把底层的运行时重新设计成"每个应用都是独立的 Spring Boot 可执行程序"，从而可以借助各类 Deployer 部署到本地、Cloud Foundry 或 Kubernetes。这个设计很关键，后面我会单独讲。

2. 三个核心概念搞懂，Data Flow 的骨架就清楚了

2.1 Stream：用 DSL 描述一条实时数据管道

先说 Stream。Data Flow 里的 Stream 不是指 Flink 那种流式计算引擎，它代表的是"一条由多个 Spring Cloud Stream 应用首尾相连构成的消息驱动型数据管道"。

管道里每个环节分为三类角色：

• Source：数据入口，负责从外部拉取或接收数据，比如 HTTP 接口、文件监听、消息队列消费。
• Processor：数据处理器，负责转换、过滤、富化数据，比如 JSON 转换、字段映射。
• Sink：数据出口，负责把数据吐到目标系统，比如写数据库、写文件、调用下游接口。

Data Flow 用一套很直观的 DSL 来形容管道，竖线表示数据流方向：

http | transform | log

这条 DSL 的含义是：HTTP 接口接收数据，经过 transform 处理，最终交给 log 打印。每一段都是一个独立的可部署应用，它们之间通过消息中间件传递数据。

实际创建 Stream 的命令大概是这样的：

dataflow:> stream create --name http-log --definition "http --server.port=9000 | log --expression=payload" dataflow:> stream deploy http-log

部署完成后，http 应用会监听 9000 端口。往这个端口发数据，数据就会沿着管道流下去，最后可以在 log 应用的日志里看到输出。

对于没接触过的人，这个设计最妙的一点是：它把原本分散在多个微服务里的"数据流转代码"统一抽象成了结构化描述。你要新增一条管道，不用再复制一套项目模板，而是像写命令一样组合已有的应用组件。熟悉了之后你会发现，这跟用 Docker Compose 描述一组容器的感觉有点像——代码变成了声明式配置，运行状态交给平台管理。

2.2 Task：短生命周期任务和批处理的承载者

Stream 解决的是"持续运行的数据流"，Task 解决的则是"跑完就退出的一次性任务"。

Task 的生命周期模型和 Stream 完全不同。Stream 应用部署后是常驻进程，Task 应用则是启动、执行、退出。Spring Cloud Task 这个底座负责记录每次任务执行的元数据，包括开始时间、结束时间、退出码、参数等等，这些记录会持久化到数据库里。你可以通过 API 查询历史上某次任务执行的具体情况。

那 Task 和 Spring Batch 是什么关系？很多人容易把这俩搞混。我的理解是：

• Spring Batch 是一个批处理开发框架，解决的是"如何处理大批量数据"，比如分片、重试、事务边界。
• Spring Cloud Task 是一个任务生命周期管理框架，解决的是"任务如何被拉起、如何被追踪、如何被管理"。

Data Flow 把 Task 纳入统一管理后，你可以把一个内嵌了 Spring Batch Job 的应用注册为 Task，然后在 Data Flow 里创建、启动、调度它，甚至把它纳入 Stream 管道中作为其中一环。比如一条订单处理管道运行过程中，需要在某个节点启动一个数据重算的批处理任务，这种组合场景在 Data Flow 里是可以编排的。

Stream 和 Task 的差异，我用一个表格概括：

维度	Stream	Task
生命周期	长期运行	启动、执行、退出
数据来源	持续消费消息	入参、文件、数据库
典型场景	实时订单同步、日志处理	月度报表、数据初始化、批量清洗
对外形态	常驻微服务	一次性执行应用
失败处理	依赖消息中间件重试机制	任务级状态记录，可手动或自动重跑

2.3 应用注册机制：为什么叫"Data Flow"而不是"一个框架"

Data Flow 和一般开发框架最大的区别，在于它把数据处理逻辑做成了"可注册、可重用、可组合"的应用资产。

每个 Source、Processor、Sink 本质上就是一个独立的 Spring Boot 应用。你不一定非要用 Spring 官方提供的默认应用组件，完全可以自己写一个 Processor，然后用下面的命令把它注册到平台：

dataflow:> app register --name my-processor --type processor --uri maven://com.example:my-processor:1.0.0

这里的 uri 可以是 Maven 坐标、Docker 镜像地址，也可以是一个 HTTP 可以下载的 jar 包。注册之后，这个组件就能在任意 Stream DSL 中使用了。

这带来一个很重要的好处：不同的业务团队可以各自维护自己的数据处理组件，注册到同一个 Data Flow 平台后，其他团队也能复用。数据逻辑从"藏在代码仓库里的私有实现"变成了"平台上的公共能力"。

我在实际项目里把这个机制用在了公司内部的清洗组件上。原来每个管道都要单独写一遍格式转换和字段脱敏，后来我们把它做成一个公共 Processor 应用注册到 Data Flow，所有管道通过 DSL 参数引用它。改动一次，所有管道跟随升级，这比维护一摞复制粘贴的代码要省心得多。

3. 从零跑通第一个数据流：环境搭建与核心配置

3.1 Docker Compose 最快路径：数据流 Server、Skipper、MySQL、Broker

如果只是体验和学习，我不建议一开始就去搞 Kubernetes 部署，先用 Docker Compose 把全套组件拉起来是最快的路径。

Spring Cloud Data Flow 的全套运行组件包括：

• Data Flow Server：控制平面，提供 Dashboard 和 REST API。
• Skipper Server：负责 Stream 应用的部署、升级、回滚。
• 消息中间件：Kafka 或 RabbitMQ，Stream 应用的通信通道。
• 数据库：存储任务记录、Stream 定义、应用注册信息，默认 H2，生产环境务必换 MySQL 或 PostgreSQL。

下面的 Compose 配置示例里，版本号我用 2.11.x 占位，实际使用前去 Docker Hub 确认一下最新的 2.x 镜像版本就好，3.x 目前也已经可用，但 2.x 的文档和案例更多，入门阶段更友好。

services: mysql: image: mysql:8.0 container_name: dataflow-mysql environment: MYSQL_DATABASE: dataflow MYSQL_USER: dataflow MYSQL_PASSWORD: dataflow MYSQL_ROOT_PASSWORD: rootpw ports: - "3306:3306" rabbitmq: image: rabbitmq:3.12-management container_name: dataflow-rabbitmq ports: - "5672:5672" - "15672:15672" skipper-server: image: springcloud/spring-cloud-skipper-server:2.11.4 container_name: skipper-server ports: - "7577:7577" environment: - SPRING_DATASOURCE_URL=jdbc:mysql://mysql:3306/dataflow - SPRING_DATASOURCE_USERNAME=dataflow - SPRING_DATASOURCE_PASSWORD=dataflow - SPRING_DATASOURCE_DRIVER_CLASS_NAME=com.mysql.cj.jdbc.Driver depends_on: - mysql dataflow-server: image: springcloud/spring-cloud-dataflow-server:2.11.4 container_name: dataflow-server ports: - "9393:9393" environment: - SPRING_DATASOURCE_URL=jdbc:mysql://mysql:3306/dataflow - SPRING_DATASOURCE_USERNAME=dataflow - SPRING_DATASOURCE_PASSWORD=dataflow - SPRING_DATASOURCE_DRIVER_CLASS_NAME=com.mysql.cj.jdbc.Driver - SPRING_CLOUD_SKIPPER_CLIENT_SERVER_URI=http://skipper-server:7577 - SPRING_CLOUD_DATAFLOW_FEATURES_SCHEDULES_ENABLED=true depends_on: - mysql - skipper-server - rabbitmq

启动命令很简单：

docker-compose up -d

等所有容器进入 healthy 状态后，打开 http://localhost:9393/dashboard 就能看到控制台。这里有两个容易踩的坑提醒一下：

第一，演示模式下默认用 H2 数据库，看起来省事，但容器重启后所有 Stream 定义和任务记录都会丢失。如果你打算做任何稍长时间的学习或测试，第一时间把 MySQL 接上，就是上面配置里做的那样。

第二，Data Flow Server 和 Skipper Server 的数据库要指向同一个库。它们虽然职责不同，但共享一套底层元数据，如果各用各的库，后续部署 Stream 会出现莫名其妙的版本状态异常。

3.2 用 Shell 定义并部署一条实时管道

环境起来之后，推荐先用命令行 Shell 走一遍流程，因为它比 Dashboard 更能让你理解每一步背后的动作。

官方提供的 Shell 可以这样启动：

docker run -it --network host springcloud/spring-cloud-dataflow-shell:2.11.4

如果你不想拉 Shell 镜像，也可以下载对应的 jar 包运行，效果一样。在 Shell 里先配置连接 Data Flow Server：

dataflow:> config server --uri http://localhost:9393

接着注册官方提供的一些默认应用：

dataflow:> app import --uri https://dataflow.spring.io/rabbitmq-maven-latest

这一步会把一批常用的 Source、Processor、Sink 组件导入进来，比如 http、time、log、file、transform、jdbc 等。如果你是使用 Kafka 的消息环境，就把上面的 rabbitmq 换成 kafka。

创建一个最简单的 Stream：

dataflow:> stream create --name http-log --definition "http --server.port=9000 | log --expression=payload" dataflow:> stream deploy http-log

部署指令发出后，Data Flow Server 会通过 Skipper 把 http 和 log 两个应用分别启动起来。这里用的本地 Deployer，应用会作为独立的 Java 进程运行。

然后向 http 应用发送一条测试数据：

curl -X POST http://localhost:9000 -d "hello dataflow"

回到 Data Flow 的日志目录，观察输出。本地部署模式下，应用日志通常写在 /tmp/spring-cloud-dataflow-<随机目录>/logs 下面，以应用名命名。也可以直接打开 Dashboard 的 Runtime 页面，在对应应用实例的日志 Tab 里查看。

你能在日志里看到 log 应用打印出了：

hello dataflow

这就算跑通了一条完整的实时管道。虽然例子很简单，但它的意义在于帮你验证整个链路：应用注册、DSL 解析、Skipper 部署、消息中间件连接、日志归集，所有环节都是通的。

3.3 立刻就要记住的四个核心配置项

学习阶段跑通 Demo 不难，难的是你要搞清楚哪些配置是后面绕不开的。我个人建议在深入学习前先把下面四类配置的用途记牢。

第一，数据源配置。Data Flow Server、Skipper Server、以及每一个被部署出来的 Stream 应用，都可能是独立的 Spring Boot 程序。它们共享外部数据库的元数据表，但连接配置需要分别提供。Server 端的数据源配置通过 SPRING_DATASOURCE_URL 系列环境变量传入，而 Stream 应用的数据源配置通常要放到 applicationProperties 里透传。

第二，消息中间件配置。Stream 应用默认连接什么消息中间件、Broker 地址是什么，这组配置决定了管道能不能真正跑起来。在 Docker 部署时，Data Flow Server 需要知道 Kafka 或 RabbitMQ 的地址，并且这些参数要能影响到后续所有部署出来的应用。做法是在 Data Flow Server 的环境变量里设置：

SPRING_CLOUD_STREAM_RABBIT_BINDER_ADDRESSES=rabbitmq:5672 SPRING_CLOUD_STREAM_RABBIT_BINDER_USER=guest SPRING_CLOUD_STREAM_RABBIT_BINDER_PASSWORD=guest

第三，公共属性透传。所有自定义的、要给每个 Stream 应用注入的 Spring Boot 配置项，可以通过下面的方式统一设置：

SPRING_CLOUD_DATAFLOW_APPLICATIONPROPERTIES_STREAM_MANAGEMENT_ENDPOINTS_WEB_EXPOSURE_INCLUDE=*

这条配置的语义是"给所有 Stream 应用统一暴露 Actuator 端点"。类似的用法可以推广到日志级别、注册中心地址、配置中心地址等场景。

第四，调度功能开关。如果你打算用 Data Flow 调度 Task，必须先开启调度功能：

SPRING_CLOUD_DATAFLOW_FEATURES_SCHEDULES_ENABLED=true

同时还需要根据部署环境配置调度器。本地模式下用spring.cloud.scheduler.local.enabled=true，Kubernetes 模式下用 CronJob 作为调度器。这个开关默认是关闭的，很多人在网上照着文档敲 schedule 命令却发现报"调度未启用"，多半就是这个原因。

4. 生产化绕不开的细节：Skipper、配置平台和监控

4.1 Skipper：版本升级与回滚到底帮我们解决了什么

刚用 Data Flow 的人很容易忽略 Skipper 的存在，因为它只在部署和更新 Stream 时才刷存在感。但生产环境里，它恰恰是最能体现"平台价值"的组件。

Skipper 负责管理 Stream 应用的部署包版本，默认部署策略是 BlueGreen。简单说，当你要升级某个 Processor 应用时，Skipper 不会粗暴地把旧实例杀掉了事，而是先按新版本拉起一批实例，确认它们没问题后，再切换流量并清理旧实例。整个过程对下游基本无感。

实际操作中，更新一个 Stream 里某个应用版本的命令是这样的：

dataflow:> stream update --name http-log --properties app.log.version=2.1.1.RELEASE

版本号只是示例，生产环境以自己的镜像标签为准。这个命令发出后，Skipper 会解析出 http-log 管道里 log 应用的版本变化，然后执行升级流程。你可以通过stream history查看升级历史，如果升级后发现问题，用stream rollback回滚到上一个版本：

dataflow:> stream history --name http-log dataflow:> stream rollback --name http-log --release-version 0

这里我想多说一句。没有这类平台能力的时候，升级一条管道里的某个组件，意味着你要手动去改配置、重新部署、测试、再回滚，全程靠人肉盯。Data Flow 把这一套流程变成了有记录、可追溯、可回滚的标准动作。对于团队里管着超过五条管道的人来说，这个能力比"多写几个微服务"实在得多。

4.2 和 Nacos、Kubernetes 等外部系统的配合方式

生产部署时，很少有团队会把 Data Flow Server 裸跑在一台虚拟机上。大多数容器化做得比较到位的公司，会把它作为一组普通 Spring Boot 服务部署到 Kubernetes，然后用 Nacos 或 Consul 管理配置。

这里要调整一个认知：Data Flow Server 和它部署出来的 Stream 应用是完全独立的进程。你给 Data Flow Server 配置了 Nacos，不等于所有 Stream 应用都会自动接入。想让所有管道应用共用一套配置中心，需要把相关参数放到spring.cloud.dataflow.applicationProperties.stream下面，这样部署出来的每个 Stream 应用都会带上这些配置。

另外需要注意的是，Data Flow 本身有 API 和 Dashboard 两个入口。在生产环境，通常不应该把 Dashboard 暴露到公网，而是放到内网管理面。API 地址则由内部其他系统调用，用来动态创建管道。我们团队的做法是：业务方通过一个内部管理页面提交管道需求，后端调用 Data Flow 的 REST API 完成 Stream 或 Task 的创建、部署、启停。

Kubernetes 部署时，Deployer 是 kubernetes 实现，每个 Stream 应用会被包装成 K8s Deployment 资源。这意味着资源配置、副本数、namespace、镜像拉取策略等都可以通过 Data Flow 的部署属性传入。下面是一个部署时指定资源限制的示例：

dataflow:> stream deploy http-log --properties "deployer.http.kubernetes.limits.memory=512Mi"

如果你对 K8s 比较熟，会发现这层抽象非常实用：不需要每次改资源都去手工改 Deployment YAML，而是通过平台统一完成。

4.3 监控与日志：最容易被后置、最后一定会补课的部分

Data Flow Server 和每个 Stream 应用都是 Spring Boot 项目，天然带有 Actuator。生产环境里我建议至少做两件事。

第一，给每个 Stream 应用暴露 Prometheus 端点。在 Data Flow Server 的配置里加入：

SPRING_CLOUD_DATAFLOW_APPLICATIONPROPERTIES_STREAM_MANAGEMENT_ENDPOINTS_WEB_EXPOSURE_INCLUDE=health,info,prometheus,metrics

然后在部署 Stream 时，通过应用属性指定 Prometheus 抓取路径。这样每条管道上的每个应用，都能被纳入现有的 Prometheus 监控体系。我见过不少项目只监控了 Data Flow Server 本身，管道里挂掉了一个 Sink 应用却毫无感知，结果数据在中间堆积了几小时才发现，这就是监控覆盖不到位。

第二，日志统一归集。本地 Demo 阶段直接看 /tmp 下的日志文件没问题，生产环境一定要把日志输出重定向到标准输出，然后由容器运行时采集。配合 ELK 或 Loki，做到"一条管道跑在哪个节点、最近处理了什么数据、报了什么错"都能检索。

日志排查这块，我踩过一个挺深的坑：Stream 里某个 Processor 应用启动失败，我习惯性地去看 Data Flow Server 的日志，结果发现 Server 日志里只有"部署失败"的简短记录，并没有应用本身的异常堆栈。原因是每个 Stream 应用是独立进程，它的错误日志只存在于自己的输出中。后来我养成了习惯，每次排查 Stream 应用问题，第一件事是去 Runtime 页面找到对应实例的日志，而不是盯着控制台日志看。

5. 什么场景我不建议无脑上 Data Flow

5.1 和手写代码相比，Data Flow 多出来的价值到底在哪

如果只有一两条固定的数据管道，手写 Spring Integration 甚至直接写一个消费 Kafka 的 Spring Boot 服务，反而是更灵活的选择。原因很简单，代码完全在你手里，依赖最少，排查问题路径最短。

但一旦管道的数量上来，情况就变了。假设你有十条管道，每条管道由两到三个应用组成，这意味着你至少要维护二三十个可部署的微服务。它们之间的依赖关系、版本关系、配置差异，靠人脑是记不住的。这时候 Data Flow 带来的价值不是"写代码更快"，而是"管理成本更低"。

Data Flow 的核心价值在于一个词：编排。它把数据管道变成了平台上的结构化资产，而不是散落在代码仓库里的私有实现。开发同学可以复用已有组件，运维同学可以在控制台上看所有管道的运行状态，管理层可以追踪每次变更的历史。这些能力，手写代码很难低成本获得。

5.2 和 Flink、Spark Streaming 的本质区别：通用计算引擎还是管道编排平台

很多人第一次看到 Stream 概念，会下意识想到 Flink 和 Spark Streaming，然后疑惑 Data Flow 是不是要跟它们竞争。这里必须把边界说清楚。

Data Flow 的 Stream 本质上是"消息驱动型的数据管道应用编排"。它处理的数据是逐条流转的消息，数据逻辑跑在每个独立的应用里，状态管理依赖外部消息中间件或数据库。它的强项是路由、转换、清洗、转发。

Flink 和 Spark Streaming 则是通用的分布式流计算引擎，它们有内置的状态管理、Checkpoint、精确一次语义，适合做窗口统计、复杂事件处理、大规模聚合计算。

换句话说，你不太可能用 Data Flow 去实现一个需要五分钟滑动窗口加去重的风控指标计算，但用 Data Flow 把订单消息从 Kafka 搬到数仓并进行字段脱敏，则是非常顺手的场景。

下面这个表格方便大家对比选型：

对比维度	Spring Cloud Data Flow	Flink / Spark Streaming
定位	数据管道编排平台	流计算引擎
状态管理	依赖外部系统	内置 State 和 Checkpoint
数据处理模式	每个应用独立部署，消息驱动	任务提交到计算集群
优势场景	管道编排、组件复用、批流组合	复杂计算、大状态、精确一次
运维复杂度	中等，依赖多语言应用生态	需要独立集群运维

5.3 我的选型建议：哪些团队应该谨慎

说点实在的。下面这几类情况，我建议你先别急着上 Data Flow。

第一类是团队本身没有 Spring Boot 基础。Data Flow 的生态几乎全部围绕 Spring Boot 构建，虽然控制台和 API 看起来友好，但一旦要写自定义组件，还是要回到 Spring Boot 开发。团队不熟悉这套技术栈，学习成本会拖慢节奏。

第二类是管道数量极少且非常固定。如果公司就一条订单同步管道，一年到头不用改，用 Spring Batch 写个定时任务就足够了，没必要引入一套控制平面和简化平台。

第三类是对低延迟和资源占用要求极其苛刻的场景。Data Flow 部署的 Stream 应用是独立进程，进程间通信要经过消息中间件，延迟比纯内存的 Flink 或 Akka Streams 要高出不少。任何一个计算框架都有自己的定位，先想清楚需求属于哪一类，再决定上不上。

顺带提一句，经常有人把 Spring Cloud Data Flow 和 Spring Cloud Gateway 放在一起问，比如"Spring Cloud Gateway 能做集群吗"。这俩解决的问题完全不同。Gateway 是 API 网关，处理的是 HTTP 请求的路由、限流、鉴权；Data Flow 处理的是数据管道的定义与编排。它们完全可以共存于一个技术体系里：通过 Gateway 暴露数据接入接口，流量再进入 Data Flow 管理的 Stream 管道。

根据我个人经验，Data Flow 更适合当作"数据平台基础设施"来慢慢养，而不是一次性临时需求的工具。如果你正处于微服务化推进阶段，建议先拿一条日志采集或订单同步管道做试点，把应用注册、Skipper 升级、监控日志这套流程完全跑通，再逐步扩大范围。版本选择上留意 Spring Boot 大版本的兼容关系：Data Flow 2.x 基于 Boot 2.7，3.x 对应 Boot 3，后续升级时要一起评估，不要只换 Data Flow 版本而忽略了底层微服务框架的连带影响。