什么是容错，以及如何构建容错系统

正常运作与优雅降级

在设计容错系统时，您可能希望应用程序始终保持在线并完全正常运行。在这种情况下，您的目标是正常运行——您希望即使系统某个组件发生故障或离线，您的应用程序以及用户体验也能保持不变。

另一种方法是所谓的“优雅降级”，即允许中断和错误影响功能并降低用户体验，但不会完全摧毁应用程序。例如，如果某个软件实例在流量高峰期遇到错误，其他用户的应用程序体验可能会变慢，某些功能可能会变得不可用。

 

容错成本

在构建容错系统时，另一个重要的考虑因素是成本。这是一个比较难处理且因人而异的因素，但重要的是要记住，虽然选择和使用容错能力更强的架构和工具本身就存在成本，但选择不高容错能力也会带来巨大的成本。

 

• 一次宕机损失多少钱？对于关键任务系统来说，即使几分钟的宕机也可能导致数百万美元的收入损失。

• 一次服务中断会给银行带来多大的声誉损失？消费者的要求很高，尤其是在某些垂直行业。例如，仅仅几分钟的应用程序中断就足以吓跑数百万客户。

• 一次宕机会给工程工时带来多少损失？你的团队在宕机恢复过程中所花费的时间，就意味着他们无法开发新功能或开展其他重要工作。

• 宕机对团队士气、员工留任/招聘会造成怎样的影响？宕机通常发生在不方便的时间。例如，US-east-1 宕机发生在感恩节前一天，当时大多数美国工程师都在休假，这迫使他们不得不在节假日或半夜赶到办公室处理紧急情况。优秀的工程师在选择工作地点时通常有很多选择，他们会避免在那些可能影响他们正常生活的地方工作。

容错目标

实现 100% 的容错率实际上是不可能的，因此架构师在设计容错系统时通常要回答的问题是他们希望能够存活到什么程度。

生存目标可能有所不同，但对于在一个或多个公共云上运行的应用程序，以下是一些常见的目标，按弹性升序排列：

• 应对节点故障。在同一可用区（AZ，数据中心）的多个节点（通常是不同的物理服务器）上运行软件实例，可以使您的应用程序在一个或多个节点发生故障（例如硬件故障或错误）时依然能够正常运行。

• 应对可用区故障。在云区域内的多个可用区（数据中心）运行软件实例，可以有效应对可用区故障，例如暴风雨期间某个数据中心断电。

• 跨区域故障生存。跨多个云区域运行软件实例，可以让您在影响整个区域的中断事件中生存下来，例如本文开头提到的 AWS US-east-1 中断。

• 应对云提供商故障。在云端和本地，或跨多个云提供商运行软件实例，即使云提供商全面中断，也能让您安然无恙。

这些并非唯一可行的生存目标，容错能力只是应对中断和其他灾难的一个方面。架构师还需要考虑恢复时间目标 (RTO) 和恢复点目标 (RPO) 等因素，以最大程度地减少中断发生时的负面影响。但考虑容错能力的目标也同样重要，因为它们会影响应用程序的架构及其成本。