系统中的故障场景建模(5)

　　当务之急是架构师需要考虑清楚定义系统故障响应后带来的全部影响。在我们的例子中，当商品目录服务响应时间较高时，商品将在缓存的版本中搜索。使用该特定的缓存后可能最终将导致用户的得到的商品目录是略微过时的版本。不管怎样，这总比简单的抛出一种异常然后终止用户的搜索来的更好。
　　如上面的例子所见，系统行为的决策带来的影响对业务来说意义深远。因此，强烈建议与关键的业务利益相关者共同鉴定和确认系统响应来获得针对业务目标的更好的优化。
　　一种用来加速决策过程的方法是将所有可行的系统故障响应作为选项列举出来，根据业务风险评出相应的等级，并辅以简短的解释作为说明。一些业务风险的例子比如：运营成本，开发时间或花费，简化的功能。
　　在下一节中，我们将看看解决方案架构师如何主动设计解决方案来实现在系统故障模型中指定的所需行为，并测试该实现。
　　定义系统故障响应的可用工具和模式
　　在本文的上一节中，我们讨论了一些不同的步骤来帮助定义故障模型以及在应对解决方案依赖的第三方服务/系统出现故障时，如何选择需要的系统响应。 在这一节中我们将着眼于不同的模式和方法论，这些内容可以帮助我们在设计阶段和运行阶段确保指定解决方案的故障响应被实现了，同时还可以正确的被测试。
　　通过依赖注入模拟故障
　　尽管这听起来并不需要架构师高度关注，但是使用依赖注入模式对于设计一种能在服务中断的情况下，系统依然可用的解决方案来说是极其重要的。 依赖注入使得解决方案的各种服务的不同实现可以以插件的形式插拔。这对在模拟依赖系统的行为作为测试保护措施时特别有用。
　　通过依赖注入，开发者可以在不重新编译代码的情况下注入那些精心设计用以触发已知场景的服务。可以通过简单的改变配置来模拟不同的服务故障组合。该模式对于在单元测试和集成测试(我们将简短的涉及到)时测试我们要求的系统行为极其有帮助。
　　不管怎样，该模式应该在整个项目中被强制执行。个别违规的开发可能会破坏依赖注入的一些前提条件。通用的措施是解决方案架构师可以通过代码复查来确保该模式被正确的实施了。这是一种工具并仅当在整个项目中被统一使用时才会有效：明智的做法是将它整合到开发团队可以使用的应用开发框架中去。
　　从单元测试和持续集成中获益
　　反复的测试和确认，当某一故障场景发生时，解决方案的行为是否会以规定的方式执行是非常重要的。达到这一点最有效的方式就是自动化执行这些测试。 一种可以达到该目的的方式是通过将故障模型和独立的测试进行映射，并创建一整套用于模拟所依赖服务特定行为的测试套件。因为错误的不同组合可以并且应该在测试套件中被测试，所以测试套件执行的总时间可能比单元测试套件更长。 作为解决方案架构师，我们需要确认这些受益于依赖注入的长时间运行的集成测试并没有跑在开发者的工作站上。
　　上述工作最合适的候选人就是构建服务器。不幸的是，当今大多数的开发小组仅仅通过利用构建服务器的构建能力，是不能将持续集成的全部潜力发挥出来的。当今很多的构建服务器具备了很多功能来执行上述测试套件。但是如果你的构建服务器不能提供这些能力或者你根本就没有构建服务器，那么目前已有很多的开源解决方案供你选择。
　　除了在构建服务器上执行常规单元测试之外，执行上述的测试套件，将给予架构师平和的心态，并在特定场景中的某些情况发生时确保系统行为。
　　尽管架构师的“兵工厂”(arsenal)里有如此伟大的一件工具，但持续集成测试并不能确保系统可以一直以期望的行为工作。他们只提供了在面对单一故障场景时的一种特定行为。如果要关注系统的长期行为，我们将在下一节中讨论测试装置(test harnesses)的用途。
　　创建测试装置
　　在某些情况下，仅仅建立个别用于返回预定义异常的回执(stubs)可能就足够了。然而大多数时候，能够逐渐改变系统对依赖的响应以及观察解决方案在环境变化时的行为是非常重要的。尤其是在测试到包含断路器(circuit breaker)实现的场景时。
　　为了测试在变化的故障模式中的系统行为，有必要花较少的精力建立一个可以模拟独立或组合服务故障的可控环境。一些时候，这还需要创建可以输入脚本的应用，并可以在一段时间内按控制返回一系列录制的响应。
　　通过当今操作系统提供的虚拟化能力和第三方的解决方案，通过创建虚拟化来达成这项任务是可行的。这些环境可以在每次迭代中的某一段时间内被使用，并可以在不使用时撤下。
　　需要注意的一件事是，创建测试装置并不是一次性的活动，它需要在解决方案的每个迭代中重新考虑。一旦引入了更多的依赖，那么就需要更多的精力去保持测试装置与当前代码基础的相关性。
　　结束语
　　作为解决方案架构师，我们日益面临交付解决方案的挑战。这些解决方案需要集成已存在的那些部署在云中，在不同的客户端数据中心或相同的数据中心中的其他解决方案。不管这些服务在哪里，集成系统的行为将会以很多种方式影响到我们的解决方案。
　　我们作为架构师的一部分责任是识别，设计和测试如何应对这些系统中的故障和异常现象。在本文中，我们讨论了如何能更好的为集成其他服务做好计划。我们着眼于识别出我们的SLAs去理解目标系统的性能。然后我们又通过创建故障模型来识别出系统会如何故障并且针对不同的故障组合解决方案该如何响应。最后，我们讨论了一些可以整合到解决方案中的通用实践，使得实现和测试期望系统的行为更将简单。
　　我们在本文中涉及到工具和技术只是我们作为解决方案架构师用于确保交付高质量软件可选工具的冰山一角。除了技术方面，在项目团队组织方面多花精力也是不容忽视的。对于所有服务团队中的人力与团队工作动力方面的内容值得在另一篇独立的文章中来讲述。

原文转自：http://www.ltesting.net