架构设计则为满足架构需求的质量属性寻找适当的战术。对如何实现特定的质量属性感兴趣。质量需求指定了软件的响应，以实现业务目标。我们感兴趣的是设计使用设计模式、架构模式或架构策略创建设计的“战术“。 是什么使一个设计具有了可移植性，一个设计具有了高性能，而另一个设计具备了可集成性？实现这些质量属性依赖于基本的设计策略。我们将对这些称之为“战术”的设计决策进行分析。战术就是影响质量属性响应控制的设计决策。战术集合称为“架构策略”。架构模式以某种方式将战术打包在一起。 系统设计是由决策集合组成。对设计师来说，每个战术都是一个设计选择。例如，其中一个战术引入了冗余，以提高系统的可用性。这是提高可用性的一个选择但是不是唯一选择。 我们将每个系统质量属性的战术组织为层次形式，但是每个层次只是为了说明一些战术，而且任何战术列表都肯定是不完成的。 1. 可用性战术 恢复和修复是可用性的重要方面，为了阻止错误发展成故障，至少能够把错误限制在一定的范围内，从而使修复成为可能。维持可用性的所有方法包括某种类型的冗余，用来检测故障的某种类型的健康监视，以及当检测到故障时某种类型的恢复。有些情况下，监视或恢复是自动进行的，有时需要手动。 我们事项考虑错误检测，然后分析错误恢复，最后讨论错误预防。 1> 错误检测 用于识别错误的3个战术是命令/响应、心跳和异常 ⑴命令/响应。一个组件发出一个命令，并希望在预定义的时间内收到一个来自审查组件的响应。可以把该战术用在共同负责某项任务的一组组件内。客户机也可以使用这种战术，以确保服务器对象和到服务器的通信路径在期望的性能边界内操作。可以用一种层级形式组织“命令/响应”错误探测器，其中最底层的探测器对与其共享一个处理器的软件进程发出命令，较高层的错误探测器对较低层的探测器发出命令。与所有进程发出命令的远程错误探测器相比，这种战术所使用的通信带宽更少。 ⑵心跳。一个组件定期发出一个心跳消息，另一个组件接收听该信息。如果心跳失败，则假定最初的组件失败，并通知错误纠正组件。心跳还可以传递数据。例如，自动柜员机定期向服务器发送一次交易日志。该消息不仅起到心跳的作用，而且传送了要处理的数据。 ⑶异常。识别错误的一个方法就是遇到了异常。 命令/响应和心跳战术在不同的进程中操作，异常战术在一个进程中操作。异常处理程序通常将错误在语义上转换为可以被处理的形式。 2> 错误恢复 ...
