转载

Netflix 技术博客：服务全球超 1.5 亿用户的微服务实践

在全球，Netflix 拥有超过 1.5 亿的用户，因此，创新和速度是我们优先考虑的。这样才能为用户带来最佳体验。

这意味着我们的微服务不断发展和变化，但不变的是我们的责任。我们有责任提供高可用性服务，这些服务每天向订阅用户提供 1 亿小时以上的流媒体内容。

为实现这种级别的可用性，我们利用了 N+1 的体系结构。在这种结构中，我们将 Amazon Web Services （AWS：亚马逊的云服务）上的区域视为很多的故障域，这种策略允许我们承受单个区域的故障。

在单个独立的区域发生故障时，我们首先在健康区域对微服务进行规模预扩展，之后我们就可以将流量从那个故障区域转移出去。

这种预先规模扩展是必要的，因为我们使用了自动规模扩展的方式，这通常意味着我们提供的区域服务规模正好能够处理它们区域当前的需求，在区域流量转移过来之后，它们的流量会增加，原有的服务规模也就可能不够用了。

虽然我们现在已经有了这种流量疏散能力，但这种弹性并非 API 一开始就有的。2013 年，我们首次开发了多区域可用性策略（multi-regional availability strategy，以防止当年的故障再次发生，并加速了我们重新构建服务运营的进程。在过去 6 年，Netflix 和我们的客户群一起不断地成长和发展，推翻了我们预先扩展微服务能力的核心假设。这两个假设是:

所有微服务的区域需求（即请求、消息和连接等需求）都可以通过我们的关键性能指标（每秒流启动：stream starts per second，缩写为 SPS）提取出来。
在流量疏散过程中，可以统一地扩展健康区域内的微服务。

这些假设简化了预扩展机制，让我们用统一的方式对待微服务，而忽略了需求的独特性和区域性。在 2013 年，由于当时的服务以及客户群也相当统一，这种方法运行得很好，但随着 Netflix 的发展，这种方法变得不那么有效了。

无效的假设

区域性的微服务需求

我们的大多数微服务都在某种程度上与服务的数据流相关，因此 SPS 似乎是简化区域性的微服务需求的合理方式。对于大型单体服务尤其如此。例如，播放器日志记录、授权、许可协议和书签最初由一个单体服务处理，该服务的需求与 SPS 高度相关。

然而，为了提高开发人员的速度、可操作性和可靠性，我们把这个单体服务分解为更小的、具有不同功能特定需求的服务，这些服务都是为了某个目标专门构建的。

我们的边缘网关（ zuul ）也通过功能分片取得了类似的成绩。下图说明了每个分片的需求、综合需求和 SPS。从综合需求和 SPS 线来看，SPS 大致相当于一天中大部分时间的综合需求。但从单个分片来看，使用 SPS 作为需求指标而引入的错误，其数量差异很大。

Netflix 技术博客：服务全球超 1.5 亿用户的微服务实践

Zuul 分片在一天中的标准化需求示意图

统一的疏散扩展方式

由于我们使用 SPS 作为需求指标，因此若假定我们可以在健康区域统一地预扩展所有微服务，这个假定看起来似乎也是合理的。为了说明这种方法的缺点，让我们看看回放许可（playback licensing：DRM）和授权的情况。

DRM 与设备类型密切相关，比如消费电子（CE）、Android 和 iOS 均使用不同的 DRM 平台。此外，CE 与移动流媒体的比例在区域上存在差异；例如移动端在南美更受欢迎。因此，如果我们把南美的流量转移到北美，对 CE 和 Android DRM 的需求将不会同步增长。

另一方面，回放授权是所有设备在请求许可之前使用的功能。虽然它确实有一些特定的设备行为，但更主要的是，疏散期间的需求是区域性的需求总体变化的函数。

缩小差距

为了解决前述方法中的问题，我们需要更好地描述特定微服务的需求，搞清楚当我们疏散流量时这些需求是如何变化的。前者要求我们捕捉区域对微服务的需求，而不是依赖于 SPS。后者需要更好地理解按设备类型划分的微服务需求，以及疏散过程中跨区域设备需求的变化。

特定微服务的区域性需求

因为服务是不统一的，我们知道了使用诸如 SPS 这样的代理需求指标是站不住脚的，我们需要针对特定微服务的需求指标。不幸的是，由于服务的多样性，其混合了 Java（带有 Ribbon /gRPC 的 Governator /Springboot 等）和 Node （NodeQuark），我们无法依赖单个需求指标来覆盖所有的用例。为了解决这个问题，我们构建了一个系统；对每个微服务，该系统都允许我们将其关联到能代表其需求的指标上。

微服务指标是配置驱动的、自服务的，并且允许确定范围，这样的话可以让微服务在不同的分片和区域之间具有不同的配置。然后我们的系统查询 Atlas （这是我们的时间序列遥感勘测平台）以收集所需要的历史数据。