唯品会：在 Flink 容器化与平台化上的建设实践

自 2017 年起，为保障内部业务在平时和大促期间的平稳运行，唯品会就开始基于 Kubernetes 深入打造高性能、稳定、可靠、易用的实时计算平台，现在的平台支持 Flink、Spark、Storm 等主流框架。

本文将分为五个方面，分享唯品会 Flink 的容器化实践应用以及产品化经验：

• 发展概览
• Flink 容器化实践
• Flink SQL 平台化建设
• 应用案例
• 未来规划

一、发展概览

1、集群规模

在集群规模方面，我们有 2000+ 的物理机，主要部署 Kubernetes 异地双活的集群，利用 Kubernetes 的 namespaces，labels 和 taints 等实现业务隔离以及初步的计算负载隔离。

Flink 任务数、Flink SQL 任务数、Storm 任务数、Spark 任务数，这些线上实时应用加起来有 1000 多个。目前我们主要支持 Flink SQL 这一块，因为 SQL 化是一个趋势，所以我们要支持 SQL 任务的上线平台。

2、平台架构

我们从下往上进行解析实时计算平台的整体架构：

• 资源调度层（最底层）

实际上是用 deployment 的模式运行 Kubernetes 上，平台虽然支持 yarn 调度，但是 yarn 调度与批任务共享资源，所以主流任务还是运行在 Kubernetes 上的。并且，yarn 调度这一层主要是离线部署的一套 yarn 集群。在 2017 年的时候，我们自研了 Flink on Kubernetes 的一套方案，因为底层调度分了两层，所以在大促资源紧张的时候，实时跟离线就可以做一个资源的借调。

• 存储层

主要用来支持公司内部基于 Kafka 的实时数据 vms，基于 binlog 的 vdp 数据和原生 Kafka 作为消息总线，状态存储在 HDFS 上，数据主要存入 Redis、MySQL、HBase、Kudu、HDFS、ClickHouse 等。

• 计算引擎层

主要是 Flink、Storm、Spark，目前主推的是 Flink，每个框架会都会支持几个版本的镜像以满足不同的业务需求。

• 实时平台层

主要提供作业配置、调度、版本管理、容器监控、job 监控、告警、日志等功能，提供多租户的资源管理（quota，label 管理）以及 Kafka 监控。资源配置也分为大促日和平常日，大促的资源和平常的资源是不一样的，资源的权限管控也是不一样的。在 Flink 1.11 版本之前，平台自建元数据管理系统为 Flink SQL 管理 schema；从 1.11 版本开始，则是通过 Hive metastore 与公司元数据管理系统融合。

• 应用层

主要是支持实时大屏、推荐、实验平台、实时监控和实时数据清洗的一些场景。

二、Flink容器化实践

1、容器化方案

上面是实时平台 Flink 容器化的架构图。Flink 容器化其实是基于 Standalone 模式部署的。

我们的部署模式共有 Client、Job Manager、Task Manager 三个角色，每一个角色都会有一个 Deployment 来控制。

用户通过平台上传任务 jar 包、配置等，存储于 HDFS 上。同时由平台维护的配置、依赖等也存储在 HDFS 上，当 pod 启动时，就会进行拉取等初始化操作。

Client 中主进程是一个由 go 开发的 agent，当 Client 启动时，会首先检查集群状态，当集群准备好后，从 HDFS 上拉取 jar 包，再向这个集群提交任务。Client 的主要任务是做容错，它主要功能还有监控任务状态，做 savepoint 等操作。

通过部署在每台物理机上的 smart-agent 采集容器的指标写入 m3，以及通过 Flink 暴漏的接口将 metrics 写入 prometheus，结合 grafana 展示。同样通过部署在每台物理机上的 vfilebeat 采集挂载出来的相关日志写入 es，在 dragonfly 可以实现日志检索。

1）Flink 平台化

在实践过程中，一定要结合具体场景和易用性，再去考虑做平台化工作。

2）Flink 稳定性

在我们应用部署以及运行过程中，异常是不可避免的，这时候平台就需要做一些保证任务在出现异常状况后，依旧保持稳定性的一些策略。

• pod 的健康和可用：由 livenessProbe 和 readinessProbe 检测，同时指定 pod 的重启策略，Kubernetes 本身可以做一个 pod 的拉起。
• Flink 任务产生异常时