系统中的故障场景建模
发表于:2012-09-06来源:InfoQ作者:Burag Cetinkaya点击数:
标签:测试环境搭建
在当今诸多企业解决方案中,集成系统数量日益增长,迫使我们以系统的方式处理依赖项和环境的故障。通过在架构阶段对依赖项的故障进行建模,我们可以交流、测试并实现系统对故障的响应,以此减少业务的风险与成本。
在当今诸多企业解决方案中,集成系统数量日益增长,迫使我们以系统的方式处理依赖项和环境的故障。通过在架构阶段对依赖项的故障进行建模,我们可以交流、
测试并实现系统对故障的响应,以此减少业务的风险与成本。
在本文中,我们将介绍系统故障建模。系统故障建模是一种用以帮助提前发现依赖项和环境故障,并在解决方案的架构早期采取主动措施的技术。
我们将使用四步的流程来创建故障模型,而每一步都将循序渐进的揭示创建故障模型的必要信息。在本文的最后,我们将探讨不同的工具和模式对架构产生的效果,使得系统在面对不同故障模式时都可以设计和实现出我们需要的系统响应。
场景/服务 |
订单执行服务 |
库存服务 |
客户数据库 |
商品目录 |
客户评论服务 |
搜索商品 |
|
|
|
X |
|
阅读客户评论 |
|
|
|
|
X |
添加商品到购物车 |
|
X |
|
X |
|
结账 |
X |
X |
X |
|
|
以下列举的是每一步的概览:
第一步:我们将从场景的层面发现解决方案中的功能性依赖并介绍依赖项的矩阵模型,该矩阵模型将在后续的步骤中用到。
第二步:我们将从集成系统的视角查看解决方案的执行环境,并定义服务品质协议(SLAs)。
第三步:在这一步中,我们将会识别出那些可被系统收集用于了解解决方案当前运行状态的关键数据点。这些数据稍后将被用于识别出解决方案所在的故障场景。
第四步:我们将关注集成服务可能失败的多种不同的方式。我们会建立解决方案故障模型并确定我们的解决方案应该在这些故障场景中以何种方式应对。
第一步. 理解功能性依赖
当我们开始在新的解决方案中启动处理依赖性故障的计划流程时,一个关键的问题是要理解该解决方案的功能划分以及每个功能区对于第三方系统的依赖。对于架构师来说,理解这些根本的依赖关系是构架一个可以应付依赖项及环境故障的解决方案的前提。
我们使用的第一个模型是依赖项矩阵。该模型是系统依赖项矩阵,它概括并跟踪了系统的各种依赖。在这个模型中,系统功能划分(或场景)被拆解提取,并被关联到他们所依赖的第三方系统。
下图展示了系统依赖矩阵的示例。
场景/服务 |
订单执行服务 |
库存服务 |
客户数据库 |
商品目录 |
客户评论服务 |
搜索商品 |
|
|
|
X |
|
阅读客户评论 |
|
|
|
|
X |
添加商品到购物车 |
|
X |
|
X |
|
结账 |
X |
X |
X |
|
|
系统依赖项矩阵帮助解决方案架构师理解各功能划分分别依赖于哪些集成服务。本文始终会使用矩阵衡量计算响应时间、可用性、故障模型和系统对依赖项故障的响应。同样,系统依赖项矩阵也是本文后续将谈到的各模型的基础。
原文转自:http://www.ltesting.net