第14章 起初,一片混沌
本作品已使用人工智能进行翻译。欢迎您提供反馈和意见:translation-feedback@oreilly.com
服务瘫痪了,人们的日子就不好过了。依赖该服务的客户会感到沮丧,依赖该服务的其他系统会停止工作,负责该系统的人员会被呼来唤去。历史表明1历史表明,即使是最著名的在线服务,也很容易出现故障,即使有数百甚至数千人专门负责其运行和正常运行。随着软件复杂性的无情增加、2旧有的防止出错和中断的方法已显得力不从心。
在并不久远的过去,围绕测试、代码风格和流程的最佳实践让我们相信,我们编写和部署的代码能够实现我们的预期。我们相信,严格的测试、测试驱动开发(TDD)、Agile 反馈循环、结对编程等实践从长远来看有助于减少错误。这些实践仍然非常重要,但对于现代复杂系统的工程设计来说,它们还远远不够。
我们需要新的最佳实践,让我们对所构建的系统再次充满信心。为满足这一需求,最佳实践正在出现,混沌工程就是其中之一。混沌工程是 Netflix 首创的一门新学科,专门用于优化复杂的分布式系统的可用性。我们可以拥有自己的信心,也可以将其工程化。
我在 Netflix 掌管混沌团队长达三年之久,在此期间,我们将混沌工程正式化,围绕它建立了一个社区,并将这一定义推广到整个行业。本章将介绍威胁复杂分布式系统可用性的各类问题。然后,我们回顾了混沌工程的发展历程,以说明混沌工程是如何发展以应对这类问题的。我们列出了混沌工程中的五个更先进的概念,并在本章的最后提供了一个常见问题解答,该常见问题解答是我们从许多有关该主题的演讲和研讨会中整理出来的。
系统的问题
你可以把 Netflix 的工程组织想象成大约一百个小型工程团队,每个团队大约有五到七个人。服务--客户使用的产品--被架构为数百个协同工作的微服务。每个微服务都只归一个团队所有,该团队负责该微服务的所有功能、路线图、运营和正常运行时间。
微服务的一个例子可能是客户微服务,它为给定的客户 ID 提供存储在该客户身上的元数据。另一个例子可能是个性化服务,它可以存储与客户相关的偏好信息,这样当客户在 Netflix 上寻找要看的内容时,我们就可以根据他们之前观看的内容来装饰他们的体验,等等。当然,代理、API 层和特定的数据存储都可以是微服务。
设想有一天,一位客户在深夜的火车上观看《怪奇物语》。我们称这位客户为 CLR。在节目的某一时刻,一个可怕的场景让 CLR 大吃一惊,导致他的笔记本电脑掉在了地上。他拿起笔记本电脑,发现节目已经停止播放了,于是他做了任何一个理智的顾客都会做的事,疯狂地刷新浏览器。但浏览器并没有立即加载,于是他又刷新了一次......大约 100 次。
现在,CLR 正在火车上,碰巧在手机信号塔之间,所以他目前与互联网是隔开的。这些请求实际上是在网络浏览器和操作系统中排队等待。当网络连接恢复时,所有 100 个请求都会一次性通过。
Netflix 方面会发生什么?这些请求进入代理服务器,然后进入 API 层,再分散到多个服务,如个性化服务,该服务提取用户 ID,并向客户服务部门请求该用户。
客户服务规模庞大,因此需要跨越由多个节点组成的集群。在每个节点上存储每个客户的数据是不合理的,因此,ID 的一致哈希值会将任何特定客户的请求导向一个特定的主节点。由于团队负责微服务的运营,因此他们还要确保集群自动扩展,以负责任地使用资源,并在节点宕机时移交数据。他们还设置了后备措施,以防止性能下降或出现错误;例如,如果客户服务无法从磁盘获取数据,它可以从内存缓存中提供数据;如果个性化服务无法从客户服务获得响应,它可以提供默认的用户体验。 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access