《混沌工程》图文案例解释

混沌工程的发展简史

2008年8月， Netflix 主要数据库的故障导致了三天的停机， DVD 租赁业务中断，多个国家的大量用户受此影响。之后 Netflix 工程师着手寻找替代架构，并在2011年起，逐步将系统迁移到 AWS 上，运行基于微服务的新型分布式架构。这种架构消除了单点故障，但也引入了新的复杂性类型，需要更加可靠和容错的系统。为此， Netflix 工程师创建了 Chaos Monkey ，会随机终止在生产环境中运行的 EC2 实例。工程师可以快速了解他们正在构建的服务是否健壮，有足够的弹性，可以容忍计划外的故障。至此，混沌工程开始兴起。

【来源火龙果】

本文案例内容来源于OREILY出版的《混沌工程》侯杰翻译的中文版P41

1）APP访问用户信息A 服务，A服务向E服务请求个性化服务。

2）由于A服务非常繁忙，所以交由A1…An散列集群来处理

3）Smith用户向A服务发起请求，由于断网，而他不知道，所以积累了多个请求在队列中进行排队

4）网通了，这些请求都发向了A服务，Smith被安排在A43虚拟节点上，由于大量的请求造成A43十分繁忙

5）Smith一直没有收到请求，就从本地的缓存中返回用户，使得A43向E服务发起请求后就变得非常空闲了。

6）由于A43变得非常空闲，被系统收回，Smith用户的请求改为A56接受

7）由于A43被收回，所以E响应延迟，向A发送不带个性化的信息，A把收到的不带个性化的信息发送给所有用户

所有用户由于收到不带个性化的信息，所以多次发送大量的重复请求，把服务A搞趴下

“牛鞭效应”是经济学上的一个术语，指供应链上的一种需求变异放大现象，使信息流从最终客户端向原始供应商端传递时，无法有效地实现信息共享，使得信息扭曲而逐级放大，导致了需求信息出现越来越大的波动，此信息扭曲的放大作用在图形上很像一个甩起的牛鞭，因此被形象地称为牛鞭效应。