每年 150 亿美元花哪了?Netflix 的大规模 Kafka 实践
发布时间:2021-02-03 00:23

Netflix 在 2019 年花费了大约 150 亿美元 来制造国际一流的原创内容。在如此高的投入之下,咱们有必要取得许多要害的事务见地,然后为一切 Netflix 内容的策划、预算和效益剖析作业供给协助。这些见地能够是以下内容:

就像危险出资人精挑细选优异的出资时机相同,Netflix 的 内容财政工程团队 旨在协助 Netflix 出资、追寻并从咱们的举动中学习经历,以便在未来不断做出更好的出资。

从工程的视点来看,每个财政运用程序都是一个微服务。Netflix 支持 分布式办理 的理念,并鼓舞工程师在运用程序中运用微服务驱动的办法,然后在公司扩张时完成数据笼统和速度之间的恰当平衡。在一个简略的环境中,服务之间能够经过 HTTP 进行杰出的交互,可是跟着咱们的扩张,它们演化成了由同步交互恳求组成的杂乱网络。这有或许导致脑裂,并损坏可用性。

上图中的这些实体是彼此相关的。假定某个节意图制造日期发作了改变,就会影响咱们的节目播出方案,然后影响现金流项目、薪水付出和年度预算等。在微服务架构中,某种程度的失利通常是能够承受的。可是,对内容财政工程的任何微服务调用失利都会打乱一大堆核算结果,并或许导致数百万美元的丢失。调用联系变得更为杂乱时还会导致可用性问题,并在企图有效地盯梢和答复事务问题时发作盲点,例如:为什么现金流猜测与咱们的发布时刻表不一致?为什么对本年度的猜测未考虑正在制造中的节目?咱们何时能够看到本钱陈述能够精确反映上游的改变?

当咱们从头审视服务间的交互,并将它们视为工作交流流后,咱们就构建出了异步的根底架构。这种架构促进了解耦,并为分布式事务网络供给了可追溯性。工作不仅仅是触发器和更新,它们成为了不可变的流,咱们能够依据工作流重构整个体系的状况。

咱们转向发布订阅模型后,每个服务都能够将改变作为工作发布到音讯总线中,然后这些工作被需求调整本身状况的服务消费。凭借这种模型,咱们能够盯梢各种服务的状况是否同步,假如还没有,它们还需求多长时刻才干回到同步状况。当咱们面临的是一大堆相互依靠的服务时,这些见地对错常有用的。依据工作的通讯和去中心化的工作处理协助咱们处理了许多问题,这些问题在大型同步调用图中是很常见的。

Netflix 挑选了 Apache Kafka 作为处理工作、音讯传递和流处理的 事实标准 。Kafka 充任一切点对点和 Netflix Studio 范围内通讯的桥梁。它为咱们供给了 Netflix 操作体系所需的高持久性和线性可扩展的多租户架构。咱们内部的 Kafka 即服务产品供给了容错才能、可调查性、多区域布置和自助服务。这使咱们的整个微服务生态体系更简单地出产和消费有意义的工作,并开释出了异步通讯的强壮能量。

Netflix Studio 生态体系中的一次典型音讯交流进程如下所示:

咱们能够将它们分解为三大子组件。

出产者能够是任何体系,当这个体系想要发布其完好状况,或要标明其内部状况的某个要害部分已针对特定实体做出了更改,它就成是出产者。一个工作除了内容负载外,还需求遵从规范化的格局,以便于盯梢和了解。这种格局包含:

改变数据捕获东西是另一类工作出产者,它将数据库改变作为工作。当你要让数据库改变对多个顾客可见时,这个东西就很有用了。咱们还运用这个形式来跨数据中心仿制相同的数据。例如,当 MySQL 中的数据需求被索引到 Elasticsearch 或 Apache Solr 中时,就会用到这个东西。运用 CDC 的优点是它不会给源运用程序添加额定的负载。

关于 CDC 工作,能够依据工作格局的 TYPE 字段为相应的数据槽转化工作。

在数据进入 Kafka 后,便能够对其运用各种消费形式。工作有多种用法,包含作为体系核算的触发器、作为近实时通讯的内容传输负载,以及作为增强和物化数据内存视图的头绪。

当微服务需求数据集的完好视图,但部分数据是来自另一个服务的数据集时,数据增强办法的运用就会更加遍及。联接的数据集可用于提高查询功能或供给聚合数据的近实时视图。为了丰厚工作数据,顾客从 Kafka 中读取数据并调用其他服务来结构联接的数据集,然后将其发送到其他 Kafka 主题。

增强进程能够作为独自的微服务运转,该微服务担任履行扇出和物化数据集。在某些状况下,咱们期望进行更杂乱的处理,例如依据时刻窗口、会话的处理和状况办理等。关于这种状况,主张运用老练的流处理引擎来构建事务逻辑。在 Netflix,咱们运用 Apache Flink 和 RocksDB 来做流处理。咱们也在考虑运用 ksqlDB。

财政数据集的一项要害需求是工作的次序。在 Kafka 中,咱们能够经过发送带有键的音讯来完成这一意图。运用相同键发送的工作或音讯都能确保正确的次序,由于它们被发送到了相同的分区。可是,出产者依然能够弄乱工作的次序。

例如,“Stranger Things”的发行日期先是从 7 月移至 6 月,然后又从 6 月移至 7 月。由于种种原因,这些工作或许会依照过错的次序写入 Kafka。一个很小的次序过错或许会严重影响许多财政核算结果。

为了防止这种状况,主张出产者只发送发作改变的实体的首要 ID,而不发送 Kafka 音讯的完好内容。增强进程运用实体的 ID 查询源服务,以获取最新的状况或内容,然后供给了一种很好的办法来处理次序紊乱问题。咱们将其称为推迟物化,它能够确保数据集的次序是正确的。

咱们运用 Spring Boot 来完成微服务,这些服务从 Kafka 主题读取数据。Spring Boot 供给了很棒的内置 Kafka 顾客,能够无缝消费,并供给了简洁的注解,用于消费和反序列化数据。

关于数据,还需求评论的一个概念是 合约 。跟着工作流用得越来越多,咱们终究得到了一组互不相同的数据集,其间一些数据集被很多运用程序消费。在这些状况下,在输出上界说一种 schema 是抱负的挑选,并有助于确保向后兼容。为此,咱们运用 Confluent Schema Registry 和 Apache Avro 来构建带有 schema 的流。

除了专有的微服务顾客外,咱们还有 CDC 数据槽,将数据索引到多种存储中,以便进行进一步的剖析。其间包含用于要害字查找的 Elasticsearch、用于审记的 Apache Hive,以及用于进一步下流处理的 Kafka。这些数据的内容能够直接来自 Kafka 音讯,并运用 ID 字段作为主键,依据 TYPE 字段进行 CRUD 操作。

在分布式体系中,确保一次仅一次音讯传递并不是一件简单的工作,由于触及的组件太多,过分杂乱。顾客行为应该具有幂等性,以应对任何潜在的根底设施和出产者毛病。

但即便运用程序是幂等的,也不该该为已处理过的音讯进行重复深重的核算。为了做到这一点,一种盛行办法是经过分布式缓存来盯梢音讯的 UUID,只需在到期时刻距离内遇到相同的 UUID,就不进行重复处理。

Flink 在内部运用 RocksDB 完成状况办理,运用键作为音讯的 UUID,以此来完成只处理一次。假如你只想运用 Kafka,Kafka Streams 也供给了一种办法。依据 Spring Boot 的运用程序能够运用 EVCache 。

关于 Netflix 来说,实时检查其根底架构中的服务水平是至关重要的。Netflix 开发了 Atlas 来办理维度时刻序列数据,咱们用它可视化目标。咱们运用出产者、处理器和顾客发布的各种目标来协助咱们构建整个根底架构的近实时视图。

咱们监控的一些要害目标有:

服务热线
在线咨询
资深顾问 资深顾问