故障分析服务专为测试基于 Azure Service Fabric 构建的服务而设计。 借助故障分析服务，可以引入有意义的故障，并对应用程序运行完整的测试方案。 这些故障和方案会练习并验证服务在其整个生存期内经历的众多状态和转换，所有这些状态都是以受控、安全且一致的方式进行。
操作指用于测试某个服务的单独故障。 服务开发人员可以将这些用作基础构件来编写复杂的场景。 例如：
- 重新启动一个节点以模拟任意数量的重新启动计算机或 VM 的情形。
- 移动有状态服务副本以模拟负载均衡、故障切换或应用升级。
- 在一个有状态服务上触发法定人数丢失，以制造一种无法继续进行写操作的情况，因为没有足够的“备用”或“次级”副本来接收新数据。
- 在有状态服务上触发数据丢失，以创建一种所有内存状态被完全清除的情况。
方案是由一个或多个操作组成的复杂操作。 故障分析服务提供两种内置的完整方案：
- 混沌场景
- 故障转移方案
测试即服务
故障分析服务是 Service Fabric 系统服务，该服务使用 Service Fabric 群集自动启动。 该服务充当故障注入、测试方案执行和运行状况分析的主机。
启动故障操作或测试方案时，将向故障分析服务发送命令，以运行故障操作或测试方案。 故障分析服务具有状态，因此能够可靠地运行故障和方案，并验证结果。 例如，一个长时间运行的测试方案可由故障分析服务可靠地执行。 此外，因为测试是在群集内部执行，所以服务可以检查群集状态和服务，以提供有关故障更深入的信息。
测试分布式系统
Service Fabric 让编写和管理分布式可扩展应用程序的工作变得更加轻松。 故障分析服务使得测试分布式应用程序变得更加容易。 在测试时有三个需要解决的主要问题：
- 模拟/生成在现实世界中可能发生的故障：Service Fabric 的一个重要方面是它允许分布式应用程序从各种故障中恢复。 然而，为了测试应用程序能够从这些故障中恢复过来，我们需要一种机制，在受控的测试环境中模拟/生成这些现实故障。
- 生成相关故障的能力：系统中的基本故障（例如网络故障、计算机故障）可轻松地单独生成。 由于这些个别故障之间的交互，在现实世界中生成大量可能发生的情景是非常复杂的。
- 在不同开发和部署阶段的统一体验：有许多故障注入系统可以模拟各种类型的故障。 然而，当从单机开发环境转移到大型测试环境中运行相同的测试，再到在生产环境中使用这些测试时，在所有这些系统中的体验都很不理想。
尽管有许多机制可以解决这些问题，但仍然缺少一种系统能够提供必要的保证——从单机开发环境一直到生产集群内进行测试。 故障分析服务可帮助应用程序开发人员专注于测试他们的业务逻辑。 故障分析服务可提供对服务与底层分布式系统的交互进行测试所需的所有能力。
模拟/生成现实故障方案
为了测试一个分布式系统针对故障的稳定性，我们需要一种机制来生成故障。 尽管在理论上生成诸如节点关闭等故障看起来很简单，但是一开始就会遇到 Service Fabric 正在尝试解决的一系列一致性问题。 举例而言，如果我们希望关闭一个节点，所需的工作流程如下所示：
从客户端发出关闭节点请求。
将请求发送到正确的节点。
a。 如果未找到节点，它应会失败。
b. 如果找到该节点，则仅当节点关闭时才应返回。
为了从测试的角度验证故障，需要知道当故障被人为触发时，故障确实发生。 Service Fabric 提供的保证是当命令抵达节点时，该节点要么即将关闭，要么已经关闭。 在任何一种情况下，测试都应能够正确推断状态，并且在其验证中正确得出成功或失败的结论。 未在 Service Fabric 中实现且用于模拟相同故障的一套系统，可能会遇到大量的网络、硬件和软件问题，这些问题将导致无法提供上述保证。 在出现上述问题时，Service Fabric 将重新配置群集状态以解决问题，因此，故障分析服务仍然能够提供正确的保证。
生成需要的事件和方案
尽管一致地模拟真实故障本身就很难，但要生成相关联的故障则更为艰难。 例如在发生以下情况时，在有状态持久化服务中出现数据丢失：
- 只有满足写入法定人数的副本赶上了复制进度。 所有次要副本都滞后于主副本。
- 由于副本故障（由代码包或节点故障引起），写入仲裁无法达成。
- 写入仲裁组无法恢复正常运行，因为副本的数据丢失（由于磁盘损坏或计算机重新映像）。
这些相关故障在现实世界中确实会出现，但不像单独故障一样频繁。 在生产中出现之前测试这些场景至关重要。 更重要的是，有能力在受控环境中（如白天，所有工程师都在场）使用生产工作负载模拟这些方案。 比 2:00 A.M 在生产过程中第一次遇到这种情况好得多。
跨不同环境的统一体验
传统上，实践已经创建三组不同的体验：一组针对开发环境，一组针对测试环境，一组针对生产环境。 模型如下：
- 在开发环境中，生成状态转换以允许进行单个方法的单元测试。
- 在测试环境中，生成各种故障以允许采用各种故障方案进行端到端测试。
- 保持生产环境处于纯洁的状态，禁止任何人为故障并且确保有人力资源能以极快的速度响应故障。
在 Service Fabric 中，通过故障分析服务，我们主张使用相同的方法从开发环境过渡到生产环境。 可通过两种方式实现此目的：
- 为了引入受控故障，从一个单机环境到生产群集，都使用故障分析服务 API。
- 为了让群集在类似“发烧”的状态下自动诱发故障，可以使用故障分析服务生成故障。 通过配置来控制故障的发生速率可允许在不同的环境中测试同一服务。
使用 Service Fabric，尽管故障的规模在不同的环境中会有所不同，但是实际机制将是相同的。 这样从编写代码到部署过程的速度可以更快，并且能够在实际工作负荷情况下测试服务。
使用故障分析服务
C#
故障分析服务功能位于 Microsoft.ServiceFabric NuGet 包中的 System.Fabric 命名空间中。 要使用故障分析服务功能，请将 NuGet 包添加为项目的引用。
PowerShell
若要使用 PowerShell，必须安装 Service Fabric SDK。 安装 SDK 后，ServiceFabric PowerShell 模块会自动加载以供使用。
后续步骤
若要创建真正的云级服务，必须确保在部署之前和之后，服务能够承受现实的故障。 在当今的服务世界中，能够快速创新以及将代码投入生产环境非常重要。 故障分析服务能够帮助服务开发人员确切实现该目的。