英文原文：
No Single Points of Failure
避免单点故障的设计原则很简单，整个系统的工作流不会因为一个单点的失败而停止整个工作。例如，在我们的电子数据采集产品Rave中，数据库服务器就是一个故障单点。如果它崩溃了，我们就不能以任何方式继续服务于客户。但是，如果我们把所有Rave的数据都放在缓存中，我们还能够继续以只读模式运行。系统确实停止工作了么？一些功能也许已经失败了，但其他一些业务流程仍然能够进展。
理解病人及医师临床操作很重要，其第一个安全要素便的单点故障。例如，在数据库服务器崩溃时我们的单点登录可从缓存中读取的失效模式。虽然这导致操刀医师无法创建新的临床内容，但这允许他们查看随机实验导航并浏览支持的应用管理、进行平衡，以及unblind。Unblinding远比创建临床内容更重要。
我们的首个威胁是线程生命周期的安全问题，然后迭代进程到下一个最关键的业务进程，如此往复，直到Medidata临床云中不存在单点故障。
失败的代价
在深入探讨细节之前我想说一下为什么我们关心这个原则。大多数企业不想因为显而易见的原因导致单点故障。Amazon已经计算出了每毫秒宕机时间的损失，这个损失的确不小。对Medidata来说问题更严重。某些功能就像是手术室中的意外情况，unblinding也可以看做生命或患者的死亡。我们不是卖广告的或类似微博似的提供140个字符的信息传播。我们的在线时间与病人的健康是直接相关的。我们对我们应用的准确性、及时性及有效性负有重大责任。当你在医院准备接受手术时，医生电脑上的Medidata标志更像是一个平稳及安全的标志。
一个系统的单点故障包括基础设施，但我想扩大这个定义，其包括导致整个系统的失败的人及进程。我们的定义将包括一切需要被提供或维护业务功能。对Medidata来说，这不仅包括物理机器和基础设施，还包括验证、测试、部署以及使这些运作的人和进程。如果我们不去验证，我们就不能抓到并纠正bug。如果我们没得到代码审查的批准，我们不能抓住并解决致命错误。如果没人知道它是如何工作的我们就不能修复它。下面让我们来看一些单点故障。
故障的类型
物理的或者虚拟的机器故障是单点故障最明显的例子。下面是潜在问题的列表
物理或虚拟的数据库服务器
物理或虚拟的网站或应用节点
物理或虚拟的网站或应用节点的文件系统或者内存
物理机器的虚拟化环境
其他可能出现单点故障的物理或虚拟的基础设施
路由器
数据中心
代理服务器
电源
信用卡注册的SAAS解决方案
转移我们的关注到以下的人员和流程的单点故障：
保证什么
现在我们看过了几个单点故障的例子，让我们看看怎么来防止它们。在设计容错系统的第一步的一开始就开始了。当设计产品的时候问自己：
从一开始就找出你的系统能“保证”什么。 对于文件上传，你要保证的是一旦文件上传到S3，我们能够在接下来处理这个文件的时候从出现的故障中挣扎出来。一旦文件在S3，UX就要返回，而且处理要能够异步继续。你要为什么优化？Amazon为在任何时候任何混乱中保证你的订单。Medidata 为任何时候任何混乱中保证你的审计，因为在我们的监管环境中，跟踪改变了什么数据，谁改变数据， 数据改变时间 和原因是绝对的要求。
提高你的胜算
既然你已经了解了一些单点故障，我们在这里为你提供了一些补救它们的策略：
使用无状态的web和应用服务器(Use stateless web and application servers)
使用负载均衡器(Load balancers are your friend.)
如果你使用AWS，那么你可以使用一些AWS工具，如RDS multizone, multizone deployment, point in time restores, readonly slaves。
对于一些比较敏感的进程，你一定要确保你的数据是多区带的(For super sensitive process make sure your data is multiregion.)
缓存你所用到的依赖的结果，以便当依赖用过之后，你可以从缓存中读取依赖(Cache results of your dependencies so you can read from cache if the dependency goes down.)
使用没有主节点并且可以动态添加节点的技术（如，Cassadra）。
使用拥有主节点并且有一个可靠地主节点选举算法的技术，像Paxos。
自动化所有的事情
测试！拥有你自己的Chaos Monkey
培训新人
写好文档
使用 5-whys 来找出某件事情出故障的过程/根本(process/base)原因。
用文档记录你的DR计划。并测试它们。进行演习来确保人为的过程可以正常工作。
经常假想一下你的系统在极端情况先会发生什么，确保你的所想象的是一个极端的情况，这本身就是很极端的。当你使用比你预期的更多的数据的时候会发生什么？当我有两倍于现在的日志条目时会怎么样？我可以处理它吗？要了解你系统的耐压点，以及当超过耐压点时你系统的表现情况。
在避免单点故障的寻求中，另一个关键点是监控和测量。我们要估算度量，这样我们才知道，当出故障时候，DR计划起作用了，DR计划要多久来执行，DR 计划有效果。然后我们需要知道为什么出故障然后我们才能修好它。
故障是常态
总而言之， 故障是云运作的正常模式。我们要计划好它。但是避免单点故障也是对弹性的一个要求。单一的东西不能扩展也不能收缩。在面对延展性，可靠性的问题的时候，我们想要许多我们能轻而易举使用的临时资源，而不需要时候又能排除开它们。单点故障不符合这个定义。这个想法在我们的传讯计划也适用。我们实施了“智慧边界，哑路由”的模式。我们想服务于工作流程的管理。这块常常交给我们的竞争对手卖给我们的状况百出，笨拙不灵活的中间件。智慧边界哑路由产生了耦合更松，更可用到，更有发展的系统，因为我们不需要操心路由器。我们只要关注我们的边界（我们的服务），并且想尽办法来保护它们。
因特网建立在命运共享的概念之上。所以我引用我们的灰胡子的父亲其中一句话来结束：
“命运共享模型认为，损失与实体相关联的状态信息是可以接受的。在同一时间，该实体本身就会丢失。具体而言，有关传输级的信息被同步存储在连接到网络并使用其通信服务的主机上。” – David D. Clark
或者像Mark Twain 说的:
“把所有的鸡蛋放在一个篮子里，然后看好这只篮子”
注意:这个篮子是个合乎逻辑的篮子。 您的篮子应该是具有无单点故障的高可用性的，水平可扩展性的。
本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。
2KB翻译工作遵照
CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。
2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务
