Keystone流处理平台是Netflix的数据实时处理的主要平台，也是支持工程数据驱动文化的重要基础设施。虽然Keystone专注于数据分析，但值得一提的是，Netflix还有另一个自产的反应流(reactive stream)处理平台Mantis，它的目标是操作用例。我们将在以后的文章中讨论Mantis及其在Netflix生态系统中的重要作用。

今天，Keystone平台提供两项生产服务:

· 数据管道:支持流的路由服务和支持Kafka的消息服务，共同负责生产、收集、处理、聚合和移动所有的微服务事件，几乎是实时的。

· 流处理即服务(SPaaS):允许用户构建和操作自定义托管流处理应用程序，允许他们专注于业务应用程序逻辑，同时平台提供规模、操作和领域专业知识。

在这篇文章中，我们将讨论一些挑战，设计原则，我们的平台设计思想，高层架构，最后我们的愿景和核心价值平台提供给Netflix。

单一流作业的剖析:

…平台管理这些工作:

挑战

1. 规模

Netflix服务来自190多个国家的1.3亿用户。这个流媒体平台每天处理数万亿的事件和pb级的数据，以支持日常的业务需求。随着用户数量的不断增长，这个平台有望扩大规模。

2. 不同的用例

Keystone路由服务:该服务负责根据每个用户配置将任何事件路由到托管接收器。每个交付路由都由一个令人尴尬的(embarrassingly)并行流处理作业实现。用户可以定义可选的筛选器和/或投影聚合。事件最终被交付到存储接收器，以便使用至少一次的交付语义进行进一步的批处理/流处理。用户可以选择不同的延迟和重复的权衡。

流处理即服务(Stream Processing as a Service): SPaaS平台才投入生产一年左右，但是我们已经看到了巨大的工程收益，以及各种各样的需求。下面是一些常见问题和权衡的总结。

· 作业状态:从完整的无状态并行处理到需要10s TB的大型本地状态的作业。

· 作业复杂性:从将所有操作符链接在一起的令人尴尬的并行作业，到具有多个变换阶段和复杂会话逻辑的非常复杂的作业DAG。

· 窗口/会话:窗口大小从几秒钟内(即捕捉事务开始/结束事件)到几个小时长的自定义用户行为会话窗口。

· 流量模式:流量模式根据每个用例有很大的不同。在GB/sec级别上，流量可以是突发的，也可以是一致的。

· 故障恢复:一些用例要求秒级的低故障恢复延迟，当作业同时拥有大的状态和涉及改组时，这将变得更具挑战性。

· 回填和倒回:有些作业需要重放来自批处理源的数据或来自前一个检查点的数据。

· 资源争用:作业可能会阻塞任何物理资源:CPU、网络带宽或内存等。用户依赖该平台提供见解和指导来优化应用程序性能。

· 重复与延迟:应用程序可能在重复与延迟之间有不同的权衡偏好。

· 事件的排序:大多数用例并不依赖严格的排序假设，但是有些用例确实需要。

· 交付/处理语义:有些用例可以在管道中丢失一些事件，而其他用例可能需要更高的持久性保证。一些有状态流作业也要求严格的处理保证，其中计算的状态应该总是一致的。

· 观众:我们的用户范围从技术性很强的分布式系统工程师到临时的业务分析师。一些团队也可能选择在我们的平台产品上构建特定于领域的平台服务

3. 多租户

Keystone支持数千个流作业，针对从数据交付、数据分析到启用微服务体系结构模式等广泛的需求。由于流作业的多样性，为了向每个用户提供有意义的服务级别保证，基础设施需要提供运行时和操作隔离，同时最小化共享平台开销。

4. 弹性

虽然大多数流都有固定的流量模式，但我们必须设计系统来应对突发变化(即由于热门节目上线或意外故障场景导致的峰值)，并能够以自动化的方式适应和响应它们。

5. 弹性云原生

Netflix的微服务完全在云端运营。由于云的弹性、不断变化、较高的失效概率等特点。我们需要设计一个能够监控、检测和容忍故障的系统，从网络信号、实例故障、区域故障、集群故障、服务间拥塞/背压到区域灾难故障等等。

6. 操作的开销

该平台目前服务于数千个路由工作和流媒体应用程序。依赖平台团队手工管理所有流的成本非常高。相反，用户应该负责声明作业的生命周期细节，并且基础设施应该尽可能自动化。

7. 敏捷性

我们希望能够快速地开发和部署更改，每天多次。我们还希望让我们的用户以同样的敏捷度自信地使用服务。

平台思维和设计原则

1. 平台实现

该平台的主要目标之一是使其他团队能够专注于业务逻辑，使流处理工作的实验、实现和操作变得容易。通过有一个平台来抽象"硬东西"(hard code)，消除用户的复杂性，这将释放出更广泛的团队灵活性和产品创新。

在高层次上，我们致力让我们的用户:

· 快速发现和实验数据，使数据驱动的创新驱动产品

· 快速原型的流处理解决方案

· 有信心地进行服务的生产和运营

· 了解性能、成本、工作生命周期状态等，以便做出明智的本地决策

· 提供工具使用户能够自助服务

2. 构建块

为了使用户能够专注于业务逻辑，而不必担心分布式系统的复杂性或一些预先存在的解决方案的普通细节，我们的目标是提供一组丰富的可组合操作符，这些操作符可以轻松地插入流作业DAG。

此外，流作业本身也可以成为其他下游服务的构建块。我们与一些合作伙伴团队一起构建"托管数据集"和其他特定于域的平台。

从我们的平台向下，我们还努力利用其他构建模块，如容器运行时服务、平台动态配置、公共注入框架等，与Netflix软件生态系统进行深度集成。这不仅帮助我们在现有解决方案的基础上构建服务，还让我们的用户熟悉开发和运营环境。

3. 可协调的权衡

任何复杂的分布式系统本质上都有一定的局限性，因此设计这样的系统应该考虑各种权衡，即延迟与重复、一致性与可用性、严格排序与随机排序等。某些用例可能需要这些权衡的不同组合，因此平台应该公开这些旋钮，并允许单个用户自定义并向系统声明需求，这是非常重要的。

4. 第一类公民的失败

失败在任何大型分布式系统中都是一种常态，特别是在云环境中。任何适当设计的云本地系统都应该将故障视为头等公民。

以下是影响我们设计的一些重要方面:

· 假设不可靠的网络

· 信任底层运行时基础设施，但要设计自动修复功能

· 为多租户支持强制作业级别隔离

· 当发生故障时，减小爆炸半径(影响的范围)

· 设计自动调节，如果任何组件偏离所需状态，甚至发生灾难故障

· 正确处理和传播反压力

5. 关注点分离

用户和平台之间:用户应该能够通过平台UI或API声明"目标状态"。目标状态存储在一个真理存储源中，从"当前状态"到"目标状态"的实际执行由平台工作流处理，不需要与用户交互。

控制平面和数据平面之间:控制平面负责工作流编排/协调，数据平面负责繁重的工作，以确保事情发生并保持所需的状态

不同子组件之间:每个组件负责自己的工作和状态。每个组件的生命周期都是独立的。

运行时基础设施:流处理作业部署在开源的Netflix Titus容器运行时服务上，该服务提供供应、调度、资源级隔离(CPU、网络、内存)、高级网络等。

我们的解决方案

考虑到前面提到的挑战和设计原则，我们关闭了一个声明式的协调体系结构来驱动一个自服务平台。在高层次上，这种体系结构允许用户到UI来声明所需的作业属性，平台将编排和协调子服务，以确保尽快满足目标状态，即使面临失败。

下面的部分将介绍高层体系结构，并简要介绍设计的各个方面。我们将在以后的后续文章中分享更多深入的技术细节和用例。

1. 声明性和解

声明性协调协议用于整个体系结构堆栈，从控制平面到数据平面。利用此协议的逻辑结论是，将用户声明的目标状态的单一副本存储为持久的真相来源，所有其他服务都将在其中进行协调。当状态冲突发生时，无论是由于暂时的故障还是正常的用户触发操作，都应该始终将真理的来源视为权威，所有其他版本的状态都应该视为当前的世界观。整个体系有望最终向真理之源和解。

Source of Truth存储是一个持久的存储，它保存所有需要的状态信息。我们目前使用AWS RDS。它是整个系统真理的唯一来源。例如，如果卡夫卡集群由于ZK状态的破坏而消失，我们总是可以仅根据事实的来源重新创建整个集群。同样的原则也适用于流处理层，以纠正任何处理层偏离其期望目标状态的当前状态。这使得持续的自我修复和自动化操作成为可能。

我们可以从这个协议设计中得到的另一个好处是，操作被鼓励为幂等的。这意味着控制指令由用户传递到控制平面，再传递到作业集群，不可避免的故障条件不会导致长时间的对抗效果。这些服务最终会自行协调。这也带来了操作灵活性。

2. 部署业务流程

通过与Netflix内部持续部署引擎Spinnaker的交互，Control plane简化了编排工作流。Spinnaker内部抽象了与Titus容器运行时的集成，这将允许控制平面用不同的权衡来编排部署。

flink集群由作业管理器和任务管理器组成。今天，我们通过为每个作业创建独立的Flink集群来实现完全的作业实例级隔离。惟一共享的服务是用于协商一致协调的ZooKeeper和用于存储检查点状态的S3后端。

在重新部署期间，无状态应用程序可以在延迟和重复的权衡之间进行选择，将使用相应的部署工作流来满足需求。对于有状态的应用程序，用户可以选择从检查点/保存点恢复或从新的状态开始。

3. 自助服务工具

对于路由作业:通过self-service，用户可以请求一个流来生成事件，可选地声明过滤/投影，然后将事件路由到托管sink，如Elasticsearch、Hive或提供给下游实时消费。Self-service UI能够从用户获取这些输入，并将其转换为具体的最终所需的系统状态。这允许我们构建一个驱动目标状态的解耦编排层，还允许我们抽象出用户可能不关心的某些信息，例如要生成到哪个Kafka集群，或者特定的容器配置，并在需要时为我们提供灵活性。

对于自定义SPaaS作业，我们提供命令行工具来生成flink代码模板库和CI集成等。

一旦用户自定义并检入代码，CI自动化将启动，以构建docker映像、将映像和配置注册到平台后端，并允许用户执行部署和其他管理操作。

4. 流处理引擎

我们目前的重点是利用Apache Flink，并围绕它为Keystone分析用例构建一个生态系统。继续前进，我们计划集成和扩展螳螂流处理引擎，以用于操作用例。

5. 连接器、托管操作符和应用程序抽象

为了帮助我们的用户提高开发灵活性和创新，我们提供了一系列的抽象，包括托管连接器、用户可以插入到processing DAG的操作符，以及与各种平台服务的集成。

我们提供Kafka, Elasticsearch, Hive等托管连接器。连接器抽象出了围绕自定义有线格式、序列化(因此我们可以跟踪不同格式的负载以优化存储和传输)、批处理/节流行为的底层复杂性，并且很容易插入到DAG处理中。我们还提供了动态源/接收器操作符，允许用户在运行时在不同的源或接收器之间切换，而无需重新构建。

其他托管运营商包括过滤器，投影仪，数据卫生与易于理解的自定义DSL。我们将继续与用户合作，为集合贡献经过验证的操作符，并使更多的团队可以访问它们。

6. 配置&不可变部署

多租户配置管理具有挑战性。我们希望使配置体验是动态的(这样用户就不必重新构建/重新发布代码)，同时易于管理。

默认的托管配置和用户定义的配置都与应用程序属性文件一起存储，我们已经做了一些准备工作，允许这些配置可以被环境变量覆盖，并且可以通过自助服务UI进一步覆盖。这种方法符合协调体系结构，它允许用户到我们的UI来声明预期的配置，而部署编排将确保运行时的最终一致性。

7. 故障自愈

在分布式系统中，故障是不可避免的。我们完全期待它随时会发生，并且设计了我们的系统来自我修复，这样我们就不必半夜被吵醒来减轻事故的影响。

在体系结构上，平台组件服务是隔离的，以便在出现故障时减少爆炸半径。协调体系结构还通过不断协调远离漂移行为来确保系统级的自恢复。

在单个作业级别上，遵循相同的隔离模式以减少故障影响。然而，为了处理和从这些失败中恢复，每个托管流作业都带有一个健康监视器。健康监视器是一个运行在Flink集群中的内部组件，负责检测故障场景并执行自修复:

· 集群任务管理器漂移:如果Flink的容器资源视图始终与容器运行时视图不匹配。漂移将自动纠正主动终止受影响的容器。

· 停机作业管理器领导者:如果领导者未能当选，集群将变得无脑。将对作业经理采取纠正措施。

· 不稳定的容器资源:如果某些任务管理器显示不稳定的模式，例如周期性重启/失败，则将替换它。

· 网络分区:如果任何容器遇到网络连接问题，它将自动终止。

8. 回填和倒带

同样，失败是不可避免的，有时用户可能需要对处理作业进行回填或倒带。

对于备份到数据仓库的源数据，我们在平台中构建了一些功能，允许在无需修改和重构代码的情况下动态切换源。这种方法有一定的限制，只建议用于无状态作业。

或者，用户可以选择将处理回滚到以前的自动获取检查点。

9. 监测和报警

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

10. 可靠性及试验

随着平台和底层基础设施服务不断创新以提供新特性和改进，快速采用更改的压力来自于自下而上(架构上)。

随着应用程序的开发和生产，可靠性的压力来自于自上而下。

压力在中间汇合。为了提供和获得信任，我们需要让平台和用户都能够有效地测试整个堆栈。

我们坚信让单元测试、集成测试、操作金丝雀和数据奇偶校验金丝雀对所有用户都是可访问的，并且易于流处理范例采用。我们在这方面正在取得进展，但仍面临许多挑战。

现在和未来

在过去的一年半里，Keystone流处理平台已经证明了自己每天超过万亿次的事件规模。我们的合作团队已经构建并生产了各种分析流用例。此外，我们开始看到更高级别的平台构建在顶部。

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

· 模式

· 服务层支持更灵活的平台交互

· 提供流SQL和其他高级抽象来为不同的受众解锁值

· 分析和机器学习用例

· 微服务事件源架构模式

这篇文章展示了Keystone平台的高层视图。在未来，我们将继续深入到用例、组件特性和实现的更详细的钻取。

文章翻译自: