面对软件错误构建可靠的分布式系统-3架构模型

 架构模型

对于软件架构这个术语来说，没有一个标准的、被普遍

接受的定义，因为它还是一门年幼的学科，……虽然没

有标准的定义，却也不乏定义……

卡内基·梅隆大学软件工程学院

本章提出了一个用于构建容错系统的软件架构。虽然每个人对于架构一词都有一个模糊的概念，但是这个词却几乎没有一个广为接受的定义，这就导致了很多误解。我认为如下定义对软件架构进行了比较全面的总结：

架构是一组有关软件系统组织方式的重要决策；是对系统构成元素、元素接口以及这些元素间协作行为方式的选择；是一种把这些结构和行为元素逐步组合为更大子系统的合成方式；也是一种构建风格，在其指导下把这些元素、元素接口、元素间的协作和合成组织起来。

Booch，Rumbaugh 和 Jaclbson[19]

2.1 架构的定义

从最高的抽象层次上看，架构就是“一种思考世界的方式”。然而，从实用性的层次上看，我们就必需得把我们看待世界的方式转化为一本实用的手册和一组规程，它们可以告诉我们如何使用我们看待世界的特定方式来构造一个特定的系统。

我们的软件架构通过如下一些方面来刻画：

            1．问题领域——我们的架构是为解决什么类型的问题而设计的？软件架构一定不是通用的，而是为解决某一类特定问题而设计的。缺少了关于用来解决哪类问题的描述的架构是不完整的。

            2．哲学—— 软件构造方法背后的原理是什么？架构的核心思想是什么？

 

9

            3．软件构造指南——我们如何来规划一个系统？我们需要一个明确的软件构造指南集。我们的系统将由一个程序员团队来编写和维护——所以对所有的程序员和系统设计者来说，理解系统的架构和它的潜在哲学是很重要的。从实用性的角度来讲，这些知识以软件构造指南的方式表现出来更便于维持。一个完整的软件构造指南集包括编程规则集、例子程序和培训资料等等。

            4．预先定义好的部件——以“从一组预先定义好的部件中选择”的方式进行设计远比“从头设计”的方式要来得容易。Erlang的OTP库包含了一个完整的现成部件集（称之behaviour库），一些常用的系统都可以使用这些部件构建起来。例如gen_server这种behaviour就可以用来构建client-server系统，gen_event这种behaviour可以用来构建基于事件（event-based）的程序。关于预定义部件的更完整的讨论见6.1节。 6.2.2 节将给出一个关于如何使用gen_server这种behaviour来编写一个服务器软件的简单例子。

            5．描述方式——我们如何描述某一部件的接口？我们如何描述系统中两个部件之间的通信协议？我们如何来描述系统中的静态和动态结构？为了回答这些问题，我们将介绍一些专门的符号。其中一些用来描述程序的API，而其他的则用来描述协议和系统结构。

            6．配置方式——我们如何来启动、停止和配置我们的系统？我们可以在系统工作过程中进行重配置吗？

 

2.2 问题领域

我们的系统最初是为开发电信交换系统而设计的。电信交换系统对可靠性和容错性有着苛刻的需求。电信系统需要“永久地”运行，必须有软实时的响应能力，当发生软件和硬件故障的时候要有合理的反应。Däcker[30]给出了电信系统需要具有的十条属性要求。

1．系统必须能够应对超大量的并发活动。

2．必须在规定的时刻或规定的时间内完成任务。

10

3．系统应该可以跨计算机分布运行。

4．系统要能够控制硬件。

5．软件系统往往很庞大。

6．系统要具有复杂的功能，例如：特性冲突。

7．系统应该能不间断运行许多年。

8．软件维护（例如重配置等）应该能在不停止系统的情况下进行。

9．满足苛刻的质量和可靠性需求。

10．必须提供容错功能，包括硬件失灵和软件错误。

我们可以对上述需求作出如下分析：