在 Netflix，从流媒体棒到智能电视，每天都会通过自动化测试数百种不同的设备类型，需要确保新软件版本继续提供我们客户喜欢的 Netflix 体验质量。此外，Netflix 不断与其合作伙伴（如 Roku、三星、LG、亚马逊）合作，将 Netflix SDK 移植到他们的新设备和即将推出的设备（电视、智能盒子等），以确保在允许设备上的 Netflix 应用程序可以走出去走向世界。Netflix 的合作伙伴基础设施团队提供解决方案，通过大规模启用设备管理来支持这两项重大工作。
背景
为了规范 Netflix 和合作伙伴网络中网络环境的多样性，并创建一个一致且可控的计算环境，用户可以在该环境上对设备运行回归和 Netflix 应用程序认证测试，合作伙伴基础设施团队提供了一个定制的嵌入式计算机，称为参考自动化环境。 (RAE)。硬件的补充是 RAE 和云端的软件，桥接两端的软件是双向控制平面。它们共同构成了设备管理平台，这是Netflix Test Studio (NTS)的基础设施。然后用户通过以即插即用的方式将他们的设备连接到 RAE 来有效地运行测试。
该平台允许大规模有效的设备管理，其功能集大致分为两个领域：
- 为控制设备及其环境（硬件和软件拓扑）提供服务级抽象。
- 收集和汇总连接到队列中 RAE 的所有设备的信息和状态更新。在这篇博文中，我们将重点介绍后一个功能集。
在连接到 RAE 的设备的整个生命周期中，设备可以随时更改属性。例如，在运行测试时，设备的状态将从“可用于测试”变为“在测试中”。此外，由于这些设备中有许多是预生产设备，因此会经常更改固件，因此生产设备中通常是静态的属性有时也会发生变化，例如分配给的 MAC 地址和电子序列号 (ESN)。设备上的 Netflix 安装。
因此，能够使设备信息保持最新以便设备测试正常工作是非常关键的。在设备管理平台中，这是通过将设备更新设为事件源来实现的通过控制平面到云，以便 NTS 将始终拥有有关可用于测试的设备的最新信息。那么，挑战在于能够以可扩展的方式摄取和处理这些事件，即随着设备数量的增加而扩展，这将是本博文的重点。
下图总结了架构描述：
RAE 配置为有效地成为被测设备 (DUT) 所连接的路由器。在 RAE 上，有一个称为 Local Registry 的服务，它负责检测、载入和维护有关连接到 RAE 的 LAN 侧的所有设备的信息。当连接新的硬件设备时，Local Registry 会检测并收集有关它的一组信息，例如网络信息和 ESN。本地注册表定期探测设备以检查其连接状态。随着设备属性和属性随时间发生变化，这些更改将保存到本地注册表中，并同时向上游发布到设备管理平台的控制平面。除了属性变化，本地注册中心定期向上游发布设备记录的完整快照，作为状态协调的一种形式。这些检查点事件使数据馈送的消费者能够更快地重建状态，同时防止错过更新。
在云端，名为 Cloud Registry 的服务会摄取 Local Registry 实例发布的设备信息更新，对其进行处理，然后将物化数据推送到CockroachDB支持的数据存储中。之所以选择 CockroachDB 作为后备数据存储，是因为它提供了 SQL 功能，并且我们的设备记录数据模型已经过规范化。此外，与其他 SQL 存储不同，CockroachDB 从头开始设计为可水平扩展，这解决了我们对 Cloud Registry 能够随着设备管理平台上载入的设备数量进行扩展的能力的担忧。
控制平面
MQTT构成设备管理平台控制平面的基础。MQTT 是用于物联网 (IoT) 的 OASIS 标准消息传递协议，被设计为高度轻量级但可靠的发布/订阅消息传递传输，非常适合连接具有少量代码占用和最小网络带宽的远程设备。
MQTT 客户端连接到 MQTT 代理并发送带有主题前缀的消息。相比之下，代理负责接收所有消息，过滤它们，确定谁订阅了哪个主题，并相应地将消息发送给订阅的客户端。使 MQTT 对我们非常有吸引力的关键特性是它支持分层主题、客户端身份验证和授权、每个主题的 ACL 以及双向请求/响应消息模式，
在控制平面内，设备命令和设备信息更新以主题字符串为前缀，该主题字符串包括 RAE 序列号和device_session_id，这是与设备会话对应的 UUID。将这两部分信息嵌入到每条消息的主题中，使我们能够应用主题 ACL 并有效控制用户可以看到哪些 RAE 和 DUT 并与之交互，以安全和隔离其他用户的设备。
由于Kafka是 Netflix 支持的消息传递平台，因此在两个协议之间建立了一座桥梁，以允许云端服务与控制平面进行通信。通过桥接器，MQTT 消息直接转换为 Kafka 记录，其中记录键设置为消息分配到的 MQTT 主题。由于在 MQTT 上发布的设备信息更新包含device_session_id在主题中，这意味着给定设备会话的所有设备信息更新将有效地出现在同一个 Kafka 分区上，从而为我们提供了一个明确定义的消息消费顺序。
。。。
采用流处理框架
有许多框架可用于可靠的流处理以集成到 Web 服务中（例如，Kafka Streams、Spring[url=https://docs.spring.io/spring-kafka/reference/html/]KafkaListener[/url]、Project Reactor、Flink、Alpakka-Kafka等等）。我们选择 Alpakka-Kafka 作为 Kafka 处理解决方案的基础，原因如下。
- 事实证明，Alpakka-Kafka 可以满足我们提出的所有系统要求，包括对 Netflix Spring 集成的需求。它还进一步提供了对流处理的高级和细粒度控制，包括自动背压支持和流监控。
- 与可能满足我们所有系统需求的其他解决方案相比，Akka 是一个更加轻量级的框架，它与 Spring Boot 应用程序的集成相对较短和简洁。此外，Akka 和 Alpakka-Kafka 代码比其他解决方案简洁得多，这降低了维护人员的学习曲线。
- 基于 Alpakka-Kafka 的解决方案随着时间的推移维护成本远低于其他解决方案，因为 Akka 和 Alpakka-Kafka 在文档和社区支持方面都是成熟的生态系统，已经存在至少 12 年和 6 年年，分别。
基于Alpakka的Kafka处理流水线的构建可以用下图来概括：
。。。。
更多点击标题见原文。
结论
Kafka 流处理可能很难正确处理。许多系统实现细节需要根据业务需求来考虑。幸运的是，Akka 流和 Alpakka-Kafka 提供的原语使我们能够通过构建与我们现有的业务工作流相匹配的流解决方案，同时在构建和维护这些解决方案时提高开发人员的生产力来实现这一目标。借助 Cloud Registry 中基于 Alpakka-Kafka 的处理器，我们确保了控制平面消费者端的容错能力，这是在设备管理平台内实现准确可靠的设备状态聚合的关键。
虽然我们实现了消息容错消费，但这只是设备管理平台设计和实现的一个方面。平台及其控制平面的可靠性取决于在多个领域所做的重要工作，包括 MQTT 传输、身份验证和授权以及系统监控，我们计划在未来的博客文章中详细讨论所有这些。同时，作为这项工作的结果，随着我们将越来越多的设备加入我们的系统，我们可以预期设备管理平台会随着时间的推移继续扩展以增加工作负载。