作者: Varun Khaitan

特别感谢我的非常棒的同事等：Mallika Rao，Esmir Mesic，Hugo Marques

这篇博客文章是第二部分的延续，它澄清了奈飞（Netflix）关于标题发布可观察性的模糊问题。在本文中，我们将探讨实现大规模标题的可观察性的策略、工具及方法。

为了构建一个全面的解决方案，我们决定首先引入可观察性端点。我们个性化堆栈中的每个微服务，如果要与我们的可观测性解决方案集成，都必须增加一个新的“标题健康状态”端点。我们的目标是让每个新端点都遵循几个原则：

1. 准确反映生产行为
2. 在所有端点上的标准化
3. 回答洞察三要素问题：“健康”与否，为什么不行以及如何解决这些问题。

准确体现生产过程

我们解决方案的关键部分是对生产行为的洞察力，也就是说，我们的请求到终端会产生流量，这些流量会经过与通常由调用者发起的流量相同的路径，到达实际的服务。

为了实现这种模仿效果，许多系统采用了一种“事件”处理，将我们的请求转换为对实际服务的调用，并启用日志来记录标题被过滤的原因。构建遵循软件最佳实践的服务，例如，面向对象编程（OOP）、SOLID 原则和模块化，对于在这一阶段取得成功至关重要。如果不遵循这些实践，服务端点可能会与业务逻辑紧密结合，使得新增一个与可观察性解决方案无缝集成的新端点变得困难且昂贵。

一个具有模块化业务逻辑的服务使轻松添加可观测性接口的操作变得方便。

标准化

为了标准化我们可观测性服务与个性化堆栈中各个可观测性端点之间的通信，我们开发并维护了一种稳定的 proto 请求/响应格式。该格式由我们团队定义和维护，确保所有端点都遵循统一的协议。因此，请求和响应都能统一处理。这种标准化提高了个性化堆栈内部的采用率，简化了系统架构，并提升了工程师的理解和调试能力，使问题排查更加便捷。

可观测性端点的请求格式如下:

洞察API三项

为了高效地理解标题的健康并快速处理问题，所有可观测性端点实现都必须回答：该标题是否符合当前晋升阶段的条件，如果不符——原因是什么，以及如何解决这些问题。

此可观测性系统的最终用户是发布经理，他们的职责是确保项目的顺利发布。因此，他们必须能够快速判断是否有问题，问题是什么以及如何解决。实现端点的团队必须尽可能提供详尽的信息，以便非专业的发布经理能理解问题的根本原因，并在出现任何项目设置问题时解决它们。此外，他们还必须提供足够的信息给合作伙伴工程师，当遇到系统级问题时，这些信息能帮助工程师识别底层服务的问题。

这些要求包含在以下protobuf对象中，该对象定义了端点的响应。

可观测性端点的响应格式。

我们将全面解决方案简化为以下关键步骤，这些步骤体现了我们方法的核心思想。

1. 在我们个性化和发现堆栈中的所有服务上建立可观测性端点。
2. 对每个端点实施主动监控。
3. 跟踪从 Netflix UI 的实时标题展示。
4. 将数据存储在优化且高度分布的数据存储系统中。
5. 提供易于集成的 API 以供我们的仪表板使用。
6. “时间旅行”，即提前验证。

可观测性栈高级架构图

在接下来的部分中，我们将探讨上图中的这些概念和组件。

通过定期运行的收集器任务主动地进行监控

每30分钟，我们的Title Health微服务执行一次计划收集任务，为我们的大多数个性化服务栈运行。

注：保留“Title Health”为英文，根据上下文需要也可翻译为更贴切的中文名称；微服务后加上了“执行”以提高句子流畅度；将“个性化堆栈”改为“个性化服务栈”；“大多数”更符合中文口语习惯；“计划收集任务”更简洁；删除了“任务”后面的“一个”。

对于每个我们支持的 Netflix 行（例如当下热门、即将推出等），都有一个专门的收集器。这些收集器通过与我们的目录服务接口，获取符合特定行要求的影片列表。这些服务会告知每个行预期的影片子集，我们正在评估这些影片的状态。

一旦收集器获得了候选标题的列表，它就会使用上述标准化模式来批量调用分配的行级数据服务，以检索所有候选标题的健康状况信息。此外，一些收集器会改为轮询我们的Kafka队列以获取展示数据。

除了通过我们的个性化服务评估标题的健康外，我们还会通过审查展示数据来关注我们的推荐算法是如何处理标题的。确保我们的算法公平对待所有标题是至关重要的，因为每个标题都有无限的潜力。

此数据是从实时展示流数据处理后放入Kafka队列。我们的标题健康系统会定期从该队列中获取数据。专门的数据收集器每两分钟从Kafka队列中获取展示数据。然后，这些数据按分钟汇总，计算标题在接近实时状态下收到的展示数量，并作为利益相关方的额外健康指标展示出来。

Netflix Hollow 是一个开源的 Java 库和工具集，用于从单个生产者向多个消费者分发内存中的数据集，以实现高速只读访问。考虑到我们的数据格式，Hollow 数据流是跨服务箱传播数据的绝佳策略。

当收集者从个性化堆栈中的合作伙伴服务或我们的印象流收集健康数据时，这些数据会被存储在每个收集者的专属Hollow feed中。Hollow提供了多种功能，帮助我们监控Netflix行的整体健康，确保没有大规模发布问题。它还允许我们通过维护每部作品的数据历史来追踪其变化，并计算之前版本与当前版本之间的差异。此外，它还允许我们在检测到有问题的数据更改时回滚到之前的版本。

我们有几个仪表盘，这些仪表盘使用我们的标题健康服务来展示标题的状态给各个利益相关者。这些用户界面通过我们服务中的一个端点，以便请求某个标题在所有支持行中的当前状态。此端点利用Hollow在内存中的功能从所有可用的Hollow Feed高效获取当前状态。结果将以标准化格式返回，便于未来用户界面的支持。

另外，我们还有其他接口可以总结标题在不同部分的子集中的整体健康，以突出特定成员的体验和反馈。

关于仪表板请求的消息。

奈飞上线的标题在最终发布到我们的平台之前，会经历几个预热阶段。对于每个阶段而言，初始几小时的推广尤为关键，尤其是在标题发布后，对于覆盖面及个性化程度尤其如此。因此，为了防止标题发布时出现问题，我们的可观测系统需要能够提前模拟流量，以便相关团队能在影响用户前发现问题并解决。我们称这种能力为 “时间旅行”。

许多与标题设置相关的元数据和资产有特定的时间表，以确定它们何时可供成员使用。为了确认一个标题在体验开始时是否可以观看，我们需要模拟从未来某个时间发出的请求，即这些特定元数据或资产可以使用的时间。这是通过在请求中加入一个未来的时间戳来实现的。该端点会使用这个未来时间戳的上下文来与任何进一步的下游服务进行通信。

一个带有未来时间戳的请求示例。

或

总之，# 最后

在这一系列文章中，我们探讨了在 Netflix 提升标题发布的可观察性的旅程。在第 1 部分，我们发现了管理大量内容发布所面临的挑战，以及需要可扩展的解决方案以确保每个标题的成功发布。在第 2 部分，我们强调了处理模糊性的战略方法，介绍了“标题健康”框架，以协调团队工作并优先处理核心问题。在本文中，我们详细介绍了复杂的系统策略和架构，包括可观察性端点、主动监控以及“时光旅行”功能；所有这些功能旨在确保用户能够获得令人兴奋的观看体验。

通过投资这些创新解决方案，我们增强了每个作品的可见性和成功，与内容创作者和合作伙伴建立了信任关系。这一过程不仅增强了我们的运营能力，从而进一步为未来的创新打下坚实基础，确保每个故事都能触及目标受众，让每位用户都能在 Netflix 上享受他们最喜欢的节目。

请继续关注我们，因为我们将让世界充满欢乐，并继续带来新的想法和创新。感谢您加入我们进行这次探索。