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

　　在这一节中，我们讨论了SLAs中的一些在达成前需要被彻底分析的内容。我们同样也讨论了一些工具来帮助我们评估解决方案中哪些SLAs是符合实际并可以达成的。一旦这些被确定，我们将开始关注设计和计划如何使我们的系统达到这些SLAs，并主动地设计好系统如何在规定的约束条件内可以正常的运作。
　　第三步. 测量关键数据点
　　通过着眼于依赖关系，我们确定了期望的SLAs。在此之后，我们需要去搜集那些用于检测期望运作模型的必要数据点。在这一节中，我们将讨论在系统运行时可以搜集到的不同的数据点。 虽然每个项目需要搜集不同的关键指标，但实际上花90%的时间收集以下最小的指标集就足以用于适当的调整系统行为。
　　响应时间: 该值记录了请求方向所依赖的服务发起请求至请求方接收到服务响应之间的总时间。这个响应时间考虑了所有网络延迟以及系统所依赖的服务真正的处理时间。
　　数据负载规模: 服务调用返回响应的总规模。尤其是在处理粗粒度服务的时候，大数据量会影响整个处理管道。所以，掌握数据负载规模是非常有帮助的。
　　吞吐量: 该值可以是每秒服务处理的请求数或每秒服务处理返回的数据规模。该关键数据点可以被用来控制服务的请求流。
　　异常的类型/数量: 该值是一个固定的时间周期内根据类型分组的异常总数。该数据点可以被用来基于集成的服务的状态临时关闭系统的部分功能。 在下一节中，我们将使用前面提到的数据点创建一种可以适应生存的架构。换句话说，我们将讨论请求流的控制(有时称为限流)和断路器(circuit breaker)的实现
　　第四步. 创建系统故障模型
　　目前我们已经理解了所有解决方案集成的服务以及解决方案可以满足的合理SLAs，并且识别出了那些需要被测量(以用于检测系统的实时运作质量是否符合了已达成的SLAs)的数据点。解决方案架构师还需要确认方案是否可以经受的起依赖系统的故障并且以一种可预见的方式响应故障。
　　每个被依赖的服务都可能因为不同的原因或以完全不同的方式发生故障。不幸的是，这些故障场景并没有在系统所要求的这些功能的需求文档里被良好的描述。 因此，需要为所有的依赖故障制定计划并提出可行的恢复或限制功能的手段以供系统继续以最优的方式运作，而这个重任就落在了架构师的肩上。
　　尽管不同的图表技术都可以用来表述系统的故障模型，我们将会在后续描述一种特殊的信息记录方式。然而，只要你交流的对象(开发团队、业务分析师和项目利益相关者)能够在没有你特别解释的情况下阅读懂该图，那么图表工具或方法的选择将不会像内容本身那样重要。
　　对于解决方案集成的每一个系统来说，都有一系列的组件可能发生故障。本文到目前为止，我们已经创建了可用性，响应时间和吞吐量等模型。因此，我们将在咱的所有故障模型中仅仅考虑以下类型：
　　响应时间变长
　　重复的应用错误
　　系统不可用
　　一个系统的故障模型创建如下，其中搜集了在我们的电子商务解决方案中的不同类型的故障。请记住，这个表格需要简洁但并不要求很全面。

场景/服务	订单执行服务	库存服务	客户数据库	商品目录	客户评论服务	系统行为
搜索商品				响应时间变长		提供缓存的版本
阅读客户评论					系统不可用	关闭功能
添加商品到购物车		X		响应时间变长
结账	重复的应用错误	响应时间变长	X			对请求限流

　　在上面的例子中，每个场景都会依赖一些列的集成服务。在每一行中，我们提供了一种在集成服务可能失败时可用的应对方法。简单的“X”符号用来表示这些服务可以正确的工作。
　　在对本模型更加详尽的实现中，我们需要考虑不同故障的组合情况。因此，这将是一个更加复杂的模型，它针对每个场景将拥有多行来展示不同的故障组合。 最后，我们期望的针对每个场景或功能的系统故障响应将以列表的形式展示在右手边。令人遗憾的是，在表格中定义的每个系统故障响应都是有利有弊的。

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