日均万亿事件：Netflix怎么做实时流处理？

在这篇文章中，我们将讨论流式处理所面临的挑战、Keystone 的设计原则、思维模式、架构总览、我们的愿景以及 Keystone 为 Netflix 所带来的核心价值。

单个流式作业：

通过平台管理这些作业：

在用户签入代码后，CI 自动化流程将开始构建 Docker 镜像，并通过平台后端注册镜像，用户可以执行部署和其他操作。

4. 流式处理引擎

我们目前正在基于 Apache Flink 为 Keystone 的分析用例构建一个生态系统。我们计划集成和扩展 Mantis 流式处理引擎。

5. 连接器、托管 operator 和应用程序抽象

为了帮助我们的用户提高开发敏捷性和创新，我们提供了全方位的抽象，包括托管连接器、让用户可以接入处理 DAG 的 operator，以及与各种平台服务的集成。

我们为 Kafka、Elasticsearch、Hive 等提供了托管连接器。这些连接器抽象出了自定义连线格式、序列化、批处理 / 限定行为以及接入处理 DAG 的便利性。我们还提供动态数据源 / 接收器 operator，用户可以在不同的数据源或接收器之间切换，而无需重新构建。

其他托管的 operator 还包括过滤器、投影聚合和易于理解的数据卫生自定义 DSL。我们将继续与用户合作开发更多的 operator，并让更多团队可以使用这些 operator。

6. 配置和不可变部署

多租户配置管理有一定的挑战性。我们希望提供动态且易于管理的配置体验（用户无需重新提交和构建代码）。

托管的配置和用户定义配置都保存在应用程序的属性文件中，这些配置可以被环境变量覆盖，也可以通过自助 UI 覆盖这些属性。这种方法适用于我们的调和架构，用户通过 UI 声明想要的配置并部署编排，确保运行时的最终一致性。

7. 自我恢复

在分布式系统中，故障是不可避免的。我们完全相信故障会在任何时候发生，所以我们的系统被设计成具有自我恢复能力，这样就不必在半夜醒来处理事故。

从架构上看，平台组件服务被隔离出来，以便在发生故障时减少影响范围。调和架构还通过持续调和来确保系统级别的自我恢复能力。

单个作业遵循相同的隔离模式，以减少故障影响。但是，为了处理故障并从故障中恢复，每个托管流式作业都配有健康监视器。健康监视器是运行在 Flink 集群中的内部组件，负责检测故障情况并执行自我修复：

• 集群任务管理器漂移：当 Flink 容器资源视图与容器运行时视图不匹配时就会出现漂移，通过主动终止受影响的容器，可以自动纠正漂移。

• 暂停作业管理器首领：如果未能选举出首领，集群就会进入无脑状态，此时需要对作业管理器执行纠正措施。

• 不稳定的容器资源：如果某个任务管理器出现不稳定的模式（如定期重启 / 故障），它将被替换。

• 网络分区：如果容器遇到网络连接问题，它将自动终止。

8. 回填和回放

因为故障是不可避免的，所以有时候用户可能需要回填或回放处理作业。

对于备份到数据仓库中的源数据，我们在平台中构建了相应的功能，用来动态切换数据源而无需修改和重新构建代码。这种方法有一定的局限性，建议将它应用在无状态作业上。

或者，用户可以选择回到之前自动保存的检查点开始重新处理。

9. 监控和警报

所有单个的流式作业都配有个性化的监控和警报仪表盘。这有助于平台 / 基础设施团队和应用程序团队监控和诊断问题。

10. 可靠性和测试

随着平台和底层基础设施服务不断创新，提供越来越多的新功能和改进，快速采用这些变化的压力是自下而上的（架构层面）。

随着应用程序的开发和发布，可靠性的压力是自上而下的。

于是，压力在中间相遇了。为了获得信任，我们需要让平台和用户能够有效地测试整个技术栈。

我们坚持为所有用户进行单元测试、集成测试、金丝雀运营。我们正在这方面取得进展，但仍然有很多问题需要解决。

现在和未来

在过去的一年半中，Keystone 流式处理平台每天可以处理万亿个事件。我们的合作伙伴团队已经用它构建各种流式分析应用。此外，我们也看到了一些建立在 Keystone 之上的更高级别的平台。

但是，我们的故事并未就此结束。要实现我们的平台愿景，还有很长的路要走。以下是我们正在研究的一些有趣的事项：

• 模式（schema）

• 让平台交互变得更灵活的服务层

• 提供流式 SQL 和其他更高级别的抽象，为不同的用户提供价值

• 分析和机器学习用例

• 微服务事件溯源架构模式