![](https://csdnimg.cn/release/download_crawler_static/10804367/bg4.jpg)
列举出所有可能的组件故障模式,及其组合。对每一种故障,确保服务能够
在没有无法接受的服务质量损失情况下继续运作,或者确定该故障的风险对
这个服务是可接受的(比如,没有地理冗余的服务所在的数据中心挂掉了)。
一些非常不寻常的故障组合,要处理它们在成本上是不可接受的,可能会被
认为是不可能发生的。但是,做这种决定时要谨慎。我们已多次惊讶的发现
某些不寻常的事件的组合,是如何频繁发生在运行成千上万的服务器每天数
以百万计的组件故障的情况下了。罕见的组合可以变得司空见惯。
Commodity hardware slice。服务的所有组件都应当基于普通商用硬件。比如,
一个具有轻 量 级 存 储 的 服务器可能是 具有双套接字,单 磁 盘 的 价值
1000-2500 美元的 2-4 核系统;一个具有重量级存储的服务器,与之配置相
似,但是会具有 16 到 24 个磁盘。关键的洞察如下:
1. 由大量廉价服务器组成的大规模集群要比由少量大型服务器组成的便宜
很多。
2. 服务器性能比 IO 性能的增长快得多。同样数量的磁盘,小型服务器的性
能更均衡。
3. 耗电量跟服务器数量是线性关系,跟时钟频率是三次方关系,这使得高
性能服务器运营成本更高。
4. 小服务器 failover 时只会影响服务整体工作负载中的一小部分。
单一版本软件。有两个因素让服务比大多数打包发行的软件开发成本更低,
进化更快,对于服务来说:
软件只需要面向一个单一的内部部署环境
之前的版本不需要像面向企业的产品那样一支持就是 10 几年
单一版本软件相对容易为消费者提供服务,尤其是免费提供。但是在向非消
费者销售基于订阅的服务时,这一点也是同等重要的。企业已经习惯了强力
地影响它们的软件提供商,并且习惯了在部署新版本时拥有完全的控制(通常
是非常缓慢的)。这抬高了运维成本和支持成本,因为有很多版本需要支持。
最经济型的服务不会让客户可以控制它们的运行版本,同时只会保有一个版
本。控制这种单一版本软件时需要:
发布要避免造成用户体验发生重大改变
对于那些想要控制版本升级的客户来说,要么自己部署一套,要么切换
到愿意提供多版本支持的服务商。
多租户(Multi-tenancy)。多租户是指将所有公司或终端用户都囊括在同一个没
有物理隔离的服务里,而与之相比单租户则是指将用户进行分组放到独立的
集群中。进行多租户的理由几乎与单一版本软件相同,同时也正是因为这样,
才可以为建立在自动化基础上的大规模服务从根本上降低成本。
回顾一下,我们上面已经提出的基本设计原则和考虑点是:
Design for failure。
冗余和故障恢复
基于廉价硬件
提供单一版本软件
实现多租户