Netflix 微服务经验教训

Netflix 是微服务架构的先驱之一，本文介绍了 Netflix 在实践微服务架构过程中总结的经验教训，对其他团队也有很好的借鉴意义。原文: Microservices Lessons From Netflix

微服务架构

Netflix 运行在 AWS 上，从单体架构开始，然后迁移到微服务。Netflix 迁移到微服务的原因如下：

• 在对单一代码库进行大量修改时很难发现错误

• 很难垂直扩容

• 有许多单点故障

微服务的优势

本文介绍了 Netflix 在微服务上的经验教训。

微服务挑战与解决方案

微服务架构的 3 个主要问题是：

• 依赖性

• 可扩展性

• 差异性

1.依赖性

以下是出现依赖性问题的 4 种情况：

i) 服务内请求

客户端请求会导致一个服务调用另一个服务，换句话说，服务 A 需要调用服务 B 来创建响应。

服务内请求

问题在于，某个微服务发生故障会导致级联故障。解决方案有：

• 使用断路器模式可防止级联故障，避免可能会失败的操作

• 进行故障注入测试，检查断路器模式是否按预期工作，方法是创建人工流量

• 设置回退到静态页面，使系统始终反应灵敏

• 执行指数退避（exponential backoff），避免惊群问题（thundering herd problem）

但是，可用性降低和系统测试范围的扩大都会成为问题。因为当单个微服务的宕机时间合并在一起时，可用性就会降低。而随着微服务数量的增加，测试范围的变化也会指数级增长。

因此，很重要的一点是要确定关键服务并创建旁路路径以避免非关键服务故障。

ii) 客户端库

API 网关允许在多种类型的客户端之间复用业务逻辑。

API 网关是路由 API 请求的中心入口点，含有以下限制：

• 堆消耗变得难以管理

• 潜在逻辑缺陷或错误

• 潜在传递依赖关系

解决办法是保持 API 网关的简单性，避免成为新的单体。

iii) 持久化

存储层的选择取决于 CAP 定理，换句话说，需要在可用性和一致性水平之间进行权衡。

解决方案是研究数据访问模式，选择合适的存储。

iv) 基础设施

整个数据中心都可能发生故障，因此解决方案是在多个数据中心之间备份基础设施。

福布斯报道的 Netflix 故障新闻

2.可扩展性

系统在保持性能的同时管理增加的工作量的能力称为可扩展性，水平可扩展性的 3 个维度：

• 尽可能保持服务无状态

• 如果无法实现无状态，则对服务进行分区

• 服务副本

有状态服务和无状态服务

以下是出现可扩展性问题的 3 种情况：

i) 无状态服务

无状态服务的 2 个特点是：

• 没有实例亲和性（粘性会话），换句话说，请求不会被路由到同一服务器上。

• 无状态服务的故障并不明显

无状态服务需要副本，以实现高可用性，必须按需设置自动扩容。

此外，自动扩容还能减少以下问题的影响：

• 计算效率降低

• 节点故障

• 流量高峰

• 性能缺陷

数据库和高速缓存不是无状态服务。

混沌工程检查自动扩容是否按预期运行，通过受控的中断来测试系统恢复能力，以确保提高可靠性。

ii) 有状态服务

数据库和高速缓存是有状态服务。此外，保存大量数据的自定义服务也是有状态服务。有状态服务的失败是值得注意的事件。

有状态服务的一个反模式是不备份的粘性会话，从而会造成单点故障。

解决办法是在不同数据中心的多台服务器上写入副本，并将读取路由到本地数据中心。

iii) 混合服务

高速缓存是一种混合服务。混合服务需要承担极大的负载，例如，Netflix 的缓存每秒会收到 3000 万个请求。

构建混合服务的最佳方法如下：

• 使用一致性哈希等技术划分工作负载

• 启用请求级缓存

• 允许回退到数据库

使用混沌工程来检查混合服务是否能在极端工作负载下保持正常运行。

3.差异性

软件架构的变化被称为差异性，随着差异逐渐增加，系统的复杂性也会增加。

以下是出现问题的两种情况：

i) 运行漂移

运行漂移是随着时间推移而出现的无意识差异，通常是系统新增功能的副作用。运行漂移的例子有：

• 警报阈值提高

• 超时增加

• 吞吐量下降

解决办法就是持续学习和自动化。

持续学习和自动化

工作流程如下：

• 审查事件解决方案

• 采取补救措施，防止问题再次发生

• 分析众多事件，找出模式

• 从事件解决方案中总结最佳实践

• 尽可能将最佳实践自动化

• 促进采用最佳实践

• 重复以上过程

ii) 多模态（Polyglot）

工程师故意引入的差异被称为多模态，当使用不同编程语言创建不同微服务时，就会出现这种情况。

它有以下缺点：

• 需要大量工作才能获得生产工具

• 额外的运维复杂性

• 服务器管理困难

• 多种技术的业务逻辑重复

• 成为专家的学习曲线增加

解决这一问题的办法是使用成熟的技术。

此外，多模态还强制对 API 网关进行分解，这是一件好事。因此，使用多模态架构的最佳方法是：

• 提高团队对每种技术成本的认识

• 限制对关键服务的中心化支持

• 根据影响确定优先次序

• 通过提供成熟的技术库，创建可重复使用的解决方案

以下是 Netflix 提供的微服务架构最佳实践清单：

• 自动执行任务

• 设置警报

• 自动扩容以处理动态负载

• 通过混沌工程提高可靠性

• 一致的命名约定

• 健康检查服务

• 快速回滚的蓝绿部署

• 配置超时、重试和回退

此外，变化是不可避免的，而事物总是在变化中被破坏。因此，最好的办法是加快进度，但减少破坏性变化。

此外，重组团队以支持软件架构也很有帮助。

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！