流批一体架构将实时计算与离线批处理统一到同一套引擎中，典型代表如 Apache Flink、Spark Structured Streaming。这类框架对运行环境的依赖非常复杂：JDK 版本、Scala 版本、Hadoop 类库、Python 环境以及各类连接器，任何一个环节不一致都可能导致作业提交失败。传统方式往往要求运维在每台机器上手动安装相同版本的组件，升级或回滚时更是牵一发而动全身。Docker 提供的镜像打包能力可以把这些依赖一次性固化，结合容器编排工具还能快速拉起整套计算集群，让流批一体作业的部署从逐台配置变成一键拉起。
接下来的内容会围绕实际落地展开，先梳理流批一体部署中常见的痛点，再说明如何构建适合流批一体作业的镜像，最后给出使用 Docker Compose 编排 Flink 集群的完整示例，并讨论状态持久化、日志收集与资源限制等关键细节。
流批一体部署的典型痛点与Docker的切入点
流批一体作业通常依赖多个外部系统，比如 Kafka 作为消息源、HDFS 或对象存储作为离线数据源、以及各类数据库作为维表或结果表。每个组件都有对应的客户端库和驱动，版本之间还可能存在传递依赖冲突。如果直接在物理机或虚拟机上部署，运维需要编写复杂的安装脚本，而且一旦某个组件升级，很容易破坏其他作业的兼容性。容器化之后，每个镜像只包含特定作业所需的依赖版本，不同作业之间互不影响，即使同一台宿主机上运行多个版本的 Flink 或 Spark 也不会产生冲突。
另一个常见痛点是环境漂移。开发环境、测试环境和生产环境之间的差异往往导致作业本地运行正常、上线后就报错。Docker 镜像以只读层的形式固化运行环境，只要保证镜像 tag 一致，任何节点上拉取到的都是完全相同的文件系统和库版本。这为流批一体作业的持续交付提供了可靠基础，也让回滚操作变得简单：重新启动旧版本镜像即可，不必重新配置环境。
资源隔离同样值得关注。流处理作业对延迟敏感，批处理作业则更看重吞吐，两者如果混跑在同一进程空间中容易相互干扰。Docker 基于 cgroups 和 namespaces 提供 CPU、内存、磁盘 I/O 的隔离能力，配合编排工具可以按作业维度分配资源配额。例如一个流作业可以限制为 2 个 CPU 和 4GB 内存，批作业则允许使用更多资源，从而避免单个作业拖垮整台机器。
构建适合流批一体作业的Docker镜像
镜像构建质量直接影响部署效率和运行稳定性。直接基于官方 Flink 或 Spark 镜像再拷贝 jar 包是一种常见做法，但镜像体积往往偏大，而且构建缓存利用率低。更推荐使用多阶段构建：第一阶段用 Maven 或 Gradle 镜像编译打包，第二阶段只复制运行所需的产物到精简基础镜像。下面是一个基于 Flink 官方镜像的多阶段 Dockerfile 示例。
FROM maven:3.9-eclipse-temurin-11 AS builder WORKDIR /build COPY pom.xml . RUN mvn dependency:go-offline COPY src/ ./src/ RUN mvn package -DskipTests FROM flink:1.18-scala_2.12 RUN apt-get update && apt-get install -y python3 python3-pip && rm -rf /var/lib/apt/lists/* COPY --from=builder /build/target/stream-batch-job-*.jar /opt/flink/usrlib/ COPY --from=builder /opt/flink/opt/flink-connector-kafka-*.jar /opt/flink/lib/ USER flink WORKDIR /opt/flink
第一阶段使用 Maven 官方镜像完成编译，通过提前复制 pom.xml 并执行 dependency:go-offline 来缓存依赖，后续源码变更时不会重复下载依赖。第二阶段基于 Flink 官方镜像，只安装运行所需的 Python 环境，并把构建产物复制到 /opt/flink/usrlib/ 目录。官方镜像会自动加载该目录下的 jar 包，无需修改启动脚本。同时把 Kafka 连接器从 opt 目录复制到 lib 目录，确保作业提交时连接器可用。
如果作业还需要额外的 Hadoop 依赖，可以在第二阶段继续复制对应 jar 包，或者直接使用带 Hadoop 的 Flink 镜像作为基础镜像。需要注意的是，基础镜像的选择要兼顾镜像大小和安全漏洞。官方镜像通常基于 Debian 或 Ubuntu，体积约 600MB，如果对体积敏感，可以考虑使用 Alpine 版本，但需要确认 glibc 兼容性，因为 Hadoop 和部分 JNI 库对 musl 支持不完善。
构建完成后，建议为镜像打上有意义的 tag，例如包含作业名称和版本号，而不是统一使用 latest。这样在回滚时可以精确指定历史版本，避免因 latest 指向变化而引入不确定行为。同时可以使用 docker scan 或第三方工具扫描镜像漏洞，及时升级基础镜像版本。
Docker Compose编排Flink集群的实践
单个 Flink 作业通常需要至少一个 JobManager 和多个 TaskManager 协同工作。使用 Docker Compose 可以方便地在单机或测试环境中拉起整套集群。下面是一份典型的 docker-compose.yml，定义了 JobManager 和 TaskManager 两个服务，并通过共享网络和卷实现通信与状态持久化。
version: "3.8"
services:
jobmanager:
image: stream-batch-flink:1.0
command: jobmanager
ports:
- "8081:8081"
environment:
- FLINK_PROPERTIES=jobmanager.rpc.address: jobmanager
volumes:
- flink-checkpoints:/opt/flink/checkpoints
- flink-savepoints:/opt/flink/savepoints
networks:
- flink-net
taskmanager:
image: stream-batch-flink:1.0
command: taskmanager
depends_on:
- jobmanager
environment:
- FLINK_PROPERTIES=jobmanager.rpc.address: jobmanager
volumes:
- flink-checkpoints:/opt/flink/checkpoints
- flink-savepoints:/opt/flink/savepoints
networks:
- flink-net
deploy:
replicas: 3
resources:
limits:
cpus: '2'
memory: 4G
reservations:
cpus: '1'
memory: 2G
volumes:
flink-checkpoints:
flink-savepoints:
networks:
flink-net:
driver: bridge
JobManager 服务通过端口映射将 8081 暴露到宿主机，方便访问 Flink Web UI。环境变量 FLINK_PROPERTIES 用来覆盖配置文件中的参数，这里指定了 JobManager 的 RPC 地址为服务名 jobmanager，因为同一 Docker 网络内的容器可以通过服务名互相解析。TaskManager 只有依赖 JobManager 启动后才会运行，并且通过 deploy.replicas 设置副本数为 3，实现水平扩展。
卷挂载部分使用命名卷保存检查点和保存点数据，即使容器被删除，这些状态数据仍然保留在 Docker 管理的卷中。生产环境中更推荐将检查点直接写入 HDFS 或对象存储，这样即使宿主机故障也不会丢失状态。不过对于本地测试或小型集群，命名卷已经足够。网络方面使用 bridge 驱动创建独立子网，避免与其他容器发生端口冲突。
启动集群只需执行 docker-compose up -d，停止则用 docker-compose down，如果要清理所有状态卷可以追加 -v 参数。这种方式的优势在于可以快速重建环境，非常适合在 CI/CD 流水线中运行集成测试，每个测试任务都能获得一套全新的 Flink 集群。
状态持久化、日志收集与资源限制
有状态的流批一体作业在升级或故障恢复时必须能够恢复之前的计算状态，否则会造成数据丢失或重复计算。Docker 容器本身是无状态的，因此必须通过外部存储来持久化状态。除了前面提到的命名卷，还可以直接挂载宿主机目录，例如将 /data/flink/checkpoints 挂载到容器内对应路径。这样即使容器被替换，只要挂载目录不变，状态数据就不会丢失。
对于更大规模的部署，建议使用 RocksDB 状态后端并将数据写入分布式文件系统。此时容器内只需要配置好访问对象存储的凭证，状态数据会自动同步到远端。需要注意的是，容器销毁时如果本地状态尚未上传完成，可能会丢失最后一次检查点之后的部分数据。因此可以设置作业的 checkpoint 间隔和超时时间，并在容器停止前触发一次 savepoint，通过 docker stop 的优雅停机机制让 Flink 完成状态快照。
日志收集同样是容器化部署的重要环节。默认情况下，容器日志输出到标准输出，Docker 会将其记录到宿主机日志文件中。为了集中管理和检索，可以配置 Docker 的日志驱动为 json-file 或 fluentd，也可以使用 sidecar 容器从日志目录采集。Flink 的日志默认写入 /opt/flink/log/，可以将该目录挂载出来，再配合日志采集工具统一处理。容器数量增多后，单纯依赖 Docker logs 查看日志会非常低效，建议提前规划好日志聚合方案。
资源限制方面，TaskManager 的 slots 数量需要与容器分配的 CPU 核心数匹配。如果容器限制为 2 个 CPU，而 TaskManager 配置了 4 个 slots，任务之间会争抢 CPU，导致背压和延迟升高。可以通过环境变量传递 Flink 配置，例如 taskmanager.numberOfTaskSlots 设为 2，同时设置 taskmanager.memory.process.size 与容器内存限制一致，避免 JVM 堆内存超出容器配额而被 OOM Killer 杀死。合理规划这些参数，才能让容器化带来的隔离优势真正转化为稳定的流批一体运行环境。