本文内容整理自阿里云实时计算 Flink 产品团队的技术分享，由李昊哲主讲。李昊哲负责 Flink 平台的控制台体验、企业级能力建设，包括开放性、权限管理和可观测性等方向。
在企业数字化转型的浪潮中，实时计算已经成为核心技术能力之一。然而，一个强大的实时计算引擎如何才能真正融入企业复杂的技术生态?答案在于"被集成能力"------让平台不仅仅是一个独立的服务，而是能够无缝嵌入到企业现有的开发流程、运维体系和数据架构中。
阿里云实时计算 Flink 在这方面进行了系统性的探索和实践。从 OpenAPI 的全面开放，到 Git 集成的原生支持，再到多维度的数据投递能力，Flink 正在构建一个真正开放、可编程、可治理的实时计算平台。
01
四层开放架构:从控制面到计算面的全面兼容
过去十年，Apache Flink 从一个开源的流处理框架，演进为支撑企业核心业务的实时计算平台。随着用户规模的扩大，对深度集成、自动化运维和统一入口的需求愈发强烈。为此，阿里云 Flink 构建了一个由内到外的四层开放架构，确保企业可以在不同层面灵活地集成 Flink 能力。
这个架构从底层到上层，层层开放:
- 控制面 (Control Plane) 是最核心的开放层。通过提供100余个 OpenAPI、多语言 SDK (Java、Python) 以及 Terraform 支持，开发者可以实现对 Flink 资源的程序化管理。无论是批量创建工作空间、动态调整资源配置，还是通过基础设施即代码 (IaC) 的方式管理整个 Flink 集群，都可以通过简洁的 API 调用完成。
- 数据面 (Data Plane) 提供了强大的数据集成能力。除了系统内置的丰富 Connector 和 Catalog，平台还支持开发者以开源开放的方式集成自定义组件。无论是自研的数据源、特殊的文件系统，还是企业内部的元数据管理系统，都可以通过标准接口无缝接入 Flink。
- 开发面 (Development Plane) 打破了传统 Web 控制台的局限。通过 VS Code 插件，开发者可以在本地熟悉的 IDE 环境中进行 Flink 作业的开发、调试和发布。更重要的是，全新的 Git 集成能力将代码版本控制与 Flink 作业管理深度融合，实现了从代码提交到生产上线的自动化闭环。
- 运维面 (Operations Plane) 强调可观测性和可控性。平台上的所有关键信息------指标 (Metrics)、日志 (Logs)、事件 (Events)------都可以投递到企业自有的监控系统 (如 Prometheus、Grafana) 或日志平台 (如 SLS)。开发者还可以上传自定义的 Log4j 配置，实现更精细化的日志管理。
02
OpenAPI:构建企业自有数据平台的基石
OpenAPI 是 Flink 被集成能力的核心。目前已开放的100余个 API 覆盖了从资源管理到作业运维的全链路场景，可以分为三大类:
|------------|------------------|----------------------------------------|
| API 类别 | 核心能力 | 典型应用场景 |
| 售卖控制台 API | 工作空间、项目空间、资源标签管理 | 批量开户 (15个 Workspace API)、资源动态升降、计费模式切换 |
| 开发控制台 API | 作业草稿、部署、调试、启停、运维 | 构建企业统一数据开发平台，集成自定义函数、连接器、Session 管理 |
| 三方监控告警 API | 指标、日志、事件、元数据获取 | 对接内部监控系统，实现统一的运维大盘和告警策略 |
这些 API 如同乐高积木，开发者可以根据企业需求自由组合。例如，某造车新势力客户完全基于 OpenAPI 构建了自己的实时计算门户。通过批量调用开户接口、循环提交作业 API 实现大规模作业的平滑上线，再结合指标回刷和日志自动上报，该客户实现了免登录 Flink 控制台的集中化运维，同时获得了近两倍的性能提升。
03
Git 集成:数据开发的工程化治理革命
传统的数据开发往往面临三大痛点:
- 多团队协作混乱。 数据、算法、运维等多个团队并行开发同一套数据链路，缺乏统一的分支管理机制和代码审查 (Code Review) 流程，导致代码冲突频发、责任边界模糊。
- 开发流程不规范。 "改完就上线"成为常态，没有统一的开发-测试-生产流程，缺乏自动化的语法校验、权限检查和依赖管理，质量风险极高。
- 作业质量风险高。 没有版本依据，作业被覆盖后无法找回历史逻辑。审计追溯困难，线上事故发生时无法将问题与具体的代码 Commit 关联，责任归属不清。
实时计算 Flink 版 的 Git 集成能力正是为解决这些问题而生。其核心设计理念是:Git 仓库是唯一的真实来源 (Single Source of Truth)。平台不再保存代码的主副本，所有代码变更必须遵循标准的 Git 工作流:
sql
开发者本地修改 → Fork 分支 → 提交 MR (Merge Request) → 触发 CI 校验 → Code Owner 审批 → 合并到主分支 → Flink 平台自动 Fetch 更新
Flink 支持主流的 Git 平台 (GitHub、GitLab、Bitbucket、Gitee、云效、CODING 等)，通过一键授权绑定，无需手动下载上传代码。平台提供了两种同步模式:自动同步模式下，代码更新后自动触发平台同步;手动同步模式下，可通过控制台的 Pull/Push 按钮一键触发。更重要的是，Flink 可以无缝集成到企业现有的 CI/CD 流水线中。通过 Flink OpenAPI 与 Jenkins、GitLab CI/CD、GitHub Actions 等工具配合，可以实现从代码提交、自动构建、测试验证到生产发布的全自动化流程。
实战案例:头部互联网企业的 Flink 工程化实践
某头部互联网平台在使用 Flink 时面临着典型的大规模代码管理挑战。该平台的单个 Git 仓库大小达到十几个GB，包含 600 多个文件夹和 3000 多个 Flink 作业。如此庞大的代码库，如何高效同步成为首要问题。更棘手的是，团队已经建立了完善的 GitLab CI + Code Owner 审核机制，但开发者在通过 MR 流程后，仍需手动将 SQL 代码拷贝到 Flink 控制台，不仅效率低下，还存在合规风险。传统的发布流程需要人工上传代码、手动创建作业、逐个配置参数，平均每次发布耗时 30 分钟。回滚时需要翻找历史文件，定位困难且耗时长。
通过引入 Flink Git 集成，该客户实现了显著的突破。首次全量 Fetch 3000 多个作业仅需 2 分钟，后续的增量 Pull/Push 操作达到秒级响应，这得益于 Flink 团队在代码同步算法上的持续优化。在合规性方面，平台完全沿用企业既有的 GitLab 审核链路，所有代码变更都有完整的审计日志，每次发布都能精确对应到具体的 Commit SHA，满足了严格的内部合规要求。效率方面的提升更加显著，发布时长从小时级缩短到分钟级，回滚粒度精确到 Commit，出现问题时可以快速定位到具体的代码变更，大幅降低了故障恢复时间。更重要的是，Flink 作业被当作一种特殊的"语言"，接入到企业现有的 Sonar 代码扫描、Owner 审批、签名校验等 CI/CD 链路中，实现了数据开发与软件工程的统一治理。
这个案例充分说明，Flink 的 Git 集成不是简单地提供一个代码上传功能，而是真正尊重并融入企业既有的研发流程，让数据开发进入"工程化治理"时代。
04
未来规划:迈向更开放的实时计算生态
Flink 的被集成能力仍在持续演进，未来的重点方向包括:
- OpenAPI 的深度扩展。 除了现有的基础运维能力，将逐步开放 Autopilot 自动调优、Hot Update 热更新、动态扩缩容等高阶能力，并保持与产品功能发布同步的迭代节奏。
- Terraform 的全面覆盖。 在已支持工作空间和项目空间的基础上，进一步开放作业级别的启停、开发运维等操作，将"基础设施即代码"的理念贯彻到每一个 Flink 作业。
- Git 集成的语言扩展。 从目前支持的 SQL 作业，逐步扩展到 Python 作业、DataStream 作业，让所有类型的 Flink 开发都能享受到版本控制和 CI/CD 的便利。
- 信息投递的标准化。 建立统一的事件模型，丰富投递内容 (如用户操作触发的审计事件)，并提供更灵活的过滤和路由能力，帮助企业在获取全面监控数据的同时，有效控制成本。
通过这些持续的努力，阿里云实时计算 Flink 版正在成为一个真正可编程、可嵌入、可治理的实时计算平台。无论是初创团队还是大型企业，都能够根据自身的技术栈和工作流，灵活地集成 Flink 的强大能力，释放实时数据的价值。
▼ 「Flink+Hologres 搭建实时数仓」 ▼
复制下方链接或者扫描二维码
即可快速体验 "一体化的实时数仓联合解决方案"
了解活动详情：https://www.aliyun.com/solution/tech-solution/flink-hologres
▼ 关注「Apache Flink」 ▼
回复 FFA 2024 获取大会资料
点击「阅 读 原文 」 跳转阿里云实时计算 Flink～****