Netflix近日在他们的技术博客上发表了一篇博文，探讨其实时流处理平台Keystone的设计考虑和见解。
Keystone自2015年12月开始运营，随着Netflix订阅用户从2015年第2季度的6500万增长到本文写作时的1.3亿多，其规模大幅增长。Keystone最初是作为一个Apache Chukwa管道，随着时间推移演变成了一个Kafka前端管道。据这篇博文介绍，早在2016年，Netflix就用36个Kafka集群每天处理超过7000亿条消息。
Netflix的架构由两个不同的实时流处理平台组成。Keystone专注于数据分析，Mantis专注于运营。Keystone提供了数据管道功能和“流处理即服务”。数据管道几乎实时地生成、处理和分析来自Netflix运营的所有不同微服务的数据。流处理即服务允许内部用户在开发和运营自定义流处理应用程序时专注于业务应用程序逻辑。
Netflix在构建和扩展平台时面临的主要挑战，与工程师在构建大规模分布式系统时面临的挑战类似。路由服务支持可调的至少一次交付的语义，并在延迟和消息交付之间进行折中。
Keystone使用了Apache Flink，可以支持无状态和有状态的作业、突发或恒定流量、几秒到几小时的窗口大小、按需严格排序以及可配置的消息传递保证。资源争用也可能成为系统设计的一个问题，因为不同的作业可能在CPU、内存、I/O或网络带宽上存在竞争。系统用户有软件工程师也有业务分析师。所有这些挑战，再加上他们希望实现一个基于多租户云的系统，而该系统必须足够简单，以便其用户可以声明并执行作业，而且大多数作业无需依赖运营同事就可以完成，这些构成了一组有趣的设计需求。
Keystone平台的理念可以总结为使用户完成任务。可调折中、关注点分离和子系统故障（可能发生并将要发生，被描述为“作为一流公民的失败”）是至关重要的基础。
Netflix工程团队使用声明式协调协议来实现Keystone的设计。每个用户声明的目标状态都存储在AWS RDS中，并作为事实的唯一来源。例如，如果Kafka集群消失了，那么它仅基于AWS RDS数据就可以进行重建。
部署编排是通过持续交付工具Spinnaker实现的，每个作业都有一个独立的Flink集群。每个组件的惟一共享组件是用于协商一致的ZooKeeper和用于存储检查点状态的S3。自助服务工具帮助用户通过路由作业的用户界面和流处理即服务的CLI接口来声明作业。
一组内部开发的、针对Kafka、ElasticSearch和Hive等的托管连接器可以帮助打算使用Keystone的开发人员更快地开发，而无需考虑平台的内部结构和消息解析。自定义领域专属语言（DSL）库抽象了过滤、投影和其他常用的数据转换任务。该平台通过AWS RDS协调机制提供自修复功能，在出现故障时，可以通过用户界面用需要的数据回填或回放作业。最后，该平台内置了监控和警报功能。
Keystone平台的未来开发包括服务层、流媒体SQL支持和机器学习等功能，所有这些都将在未来的Netflix工程博客文章中详细介绍。