软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口_(计算机科学)来实现。

历史

早在1960年代，诸如E·W·戴克斯特拉就已经涉及软件架构这个概念了。自1990年代以来，部分由于在 Rational Software Corporation 和Microsoft内部的相关活动，软件架构这个概念开始越来越流行起来。

卡内基梅隆大学和加州大学埃尔文分校在这个领域作了很多研究。卡内基·梅隆大学的Mary Shaw和David Garlan于1996年写了一本叫做 Software Architecture perspective on an emerging DIscipline的书，提出了软件架构中的很多概念，例如软件组件、连接器、风格等等。加州大学埃尔文分校的软件研究院所做的工作则主要集中于架构风格、架构描述语言以及动态架构。

计算机软件的历史开始于五十年代，历史非常短暂，而相比之下建筑工程则从石器时代就开始了，人类在几千年的建筑设计实践中积累了大量的经验和教训。建筑设计基本上包含两点，一是建筑风格，二是建筑模式。独特的建筑风格和恰当选择的建筑模式，可以使得一个建筑独一无二。

软件与人类的关系是架构师必须面对的核心问题，也是自从软件进入历史舞台之后就出现的问题。与此类似地，自从有了建筑以来，建筑与人类的关系就一直是建筑设计师必须面对的核心问题。英国首相丘吉尔说，我们构造建筑物，然后建筑物构造我们（We shape our buildings, and afterwaRDS our buildings shape us）。英国下议院的会议厅较狭窄，无法使所有的下议院议员面向同一个方向入座，而必须分成两侧入座。丘吉尔认为，议员们入座的时候自然会选择与自己政见相同的人同时入座，而这就是英国政党制的起源。Party这个词的原意就是"方"、"面"。政党起源的关键就是建筑物对人的影响。

在软件设计界曾经有很多人认为功能是最为重要的，形式必须服从功能。与此类似地，在建筑学界，现代主义建筑流派的开创人之一Louis Sullivan也认为形式应当服从于功能（FORMs follows function）。

几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。最为著名的，当然就是模式理论和XP理论。

架构的种类

根据我们关注的角度不同，可以将架构分成三种：

·逻辑架构。软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等。

比如下面就是笔者亲身经历过的一个软件系统的逻辑架构图

图2、一个逻辑架构的例子

从上面这张图中可以看出，此系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。每一个层次都含有多个逻辑元件。比如WEB服务器层次中有HTML服务元件、Session服务元件、安全服务元件、系统管理元件等。

·物理架构。软件元件是怎样放到硬件上的。

比如下面这张物理架构图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。

·系统架构。系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。

系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。

此外，从每一个角度上看，都可以看到架构的两要素：元件划分和设计决定。

首先，一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。

其次，进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，就很难更改的。

根据作者的经验，一个基于数据库的系统架构，有多少个数据表，就会有多少页的架构设计文档。比如一个中等的数据库应用系统通常含有一百个左右的数据表，这样的一个系统设计通常需要有一百页左右的架构设计文档。

视图

我们决定以多种构架视图来表示软件构架。每种构架视图针对于开发流程中的涉众（例如最终用户、设计人员、管理人员、系统工程师、维护人员等）所关注的特定方面。

构架视图显示了软件构架如何分解为构件，以及构件如何由连接器连接来产生有用的形式 [PW92]，由此记录主要的结构设计决策。这些设计决策必须基于需求以及功能、补充和其他方面的约束。而这些决策又会在较低层次上为需求和将来的设计决策施加进一步的约束。

构架由许多不同的构架视图来表示，这些视图本质上是以图形方式来摘要说明“在构架方面具有重要意义”的模型元素。在 Rational Unified Process 中，您将从一个典型的视图集开始，该视图集称为“4+1 视图模型”[KRU95]。它包括：

用例视图：包括用例和场景，这些用例和场景包括在构架方面具有重要意义的行为、类或技术风险。它是用例模型的子集。

逻辑视图：包括最重要的设计类、从这些设计类到包和子系统的组织形式，以及从这些包和子系统到层的组织形式。它还包括一些用例实现。它是设计模型的子集。

实施视图：包括实施模型及其从模块到包和层的组织形式的概览。 同时还描述了将逻辑视图中的包和类向实施视图中的包和模块分配的情况。它是实施模型的子集。

进程视图：包括所涉及任务（进程和线程）的描述，它们的交互和配置，以及将设计对象和类向任务的分配情况。只有在系统具有很高程度的并行时，才需要该视图。在 Rational Unified Process 中，它是设计模型的子集。

配置视图：包括对最典型的平台配置的各种物理节点的描述以及将任务（来自进程视图）向物理节点分配的情况。只有在分布式系统中才需要该视图。它是部署模型的一个子集。构架视图记录在软件构架文档中。

您可以构建其他视图来表达需要特别关注的不同方面：用户界面视图、安全视图、数据视图等等。对于简单系统，可以省略 4+1 视图模型中的一些视图。

重点

虽然以上视图可以表示系统的整体设计，但构架只同以下几个具体方面相关：

模型的结构，即组织模式，例如分层。基本元素，即关键用例、主类、常用机制等，它们与模型中的各元素相对。几个关键场景，它们表示了整个系统的主要控制流程。记录模块度、可选特征、产品线状况的服务。

构架视图在本质上是整体设计的抽象或简化，它们通过舍弃具体细节来突出重要的特征。在考虑以下方面时，这些特征非常重要。

系统演进，即进入下一个开发周期。在产品线环境下复用构架或构架的一部分。评估补充质量，例如性能、可用性、可移植性和安全性。向团队或分包商分配开发工作。决定是否包括市售构件。插入范围更广的系统。

形式

构架模式

构架模式是解决复杂构架问题的现成形式。构架框架或构架基础设施（中间件）是可以在其上构建某种构架的构件集。许多主要的构架困难应在框架或基础设施中进行解决，而且通常针对于特定的领域：命令和控制、MIS、控制系统等等。

模式示例

[BUS96] 根据构架模式最适用的系统的特征将其分类，其中一个类别处理更普遍的结构问题。下表显示了 [BUS96] 中所提供的类别和这些类别所包含的模式。

类别 模式结构 层管道和过滤器黑板分布式系统代理交互系统 模型-视图-控制器表示-抽象-控制自适应系统反射微核

在“软件构架简介”中，David Garlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。”[GS93]

但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”[IEEE98]。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。

在 Rational Unified Process 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。

为阐明其含义，下面将详述其中的两个；完整说明请参见 [BUS96]。模式以下列广泛使用的形式来表示：

模式名环境问题影响，描述应考虑的不同问题方面解决方案基本原理结果环境示例模式名层

环境需要进行结构分解的大系统。

问题必须处理不同抽象层次的问题的系统。例如：硬件控制问题、常见服务问题和针对于不同领域的问题。最好不要编写垂直构件来处理所有抽象层次的问题。否则要在不同的构件中多次处理相同的问题（可能会不一致）。

影响

系统的某些部分应当是可替换的构件中的变化不应波动相似的责任应归为一组构件大小 — 复杂构件可能要进行分解解决办法将系统分成构件组，并使构件组形成层叠结构。使上层只使用下层（决不使用上层）提供的服务。尽量不使用非紧邻下层提供的服务（不跳层使用服务，除非中间层只添加通过构件）。

示例：

1. 通用层

严格的分层构架规定设计元素（类、构件、包、子系统）只能使用下层提供的服务， 服务可以包括事件处理、错误处理、数据库访问等等。 相对于记录在底层的原始操作系统级调用，它包括更明显的机制。

2. 业务系统层

上图显示了另一个分层示例，其中有垂直特定应用层、水平层和基础设施层。注意：此处的目标是采用非常短的业务“烟囱”并实现各种应用程序间的通用性。 否则，就可能有多个人解决同一问题，从而导致潜在的分歧。

有关该模式的深入讨论，请参见指南：分层。

模式名黑板

环境没有解决问题的确定方法（算法）或方法不可行的领域。例如 AI 系统、语音识别和监视系统。

问题多个问题解决顾问（知识顾问）必须通过协作来解决他们无法单独解决的问题。各顾问的工作结果必须可以供所有其他顾问访问，使他们可以评估自己是否可以参与解决方案的查找并发布其工作结果。

影响

知识顾问参与解决问题的顺序不是确定的，这可能取决于问题解决策略

不同顾问的输入（结果或部分解决方案）可能有不同的表示方式

各顾问并不直接知道对方的存在，但可以评估对方发布的工作

解决办法多名知识顾问都可访问一个称为“黑板”的共享数据库。黑板提供监测和更新其内容的接口。控制模块/对象激活遵循某种策略的顾问。激活后，顾问查看黑板，以确定它是否能参与解决问题。如果顾问决定它可以参与，控制对象就可以允许顾问将其部分（或最终）解决方案放置于黑板上。

示例：

以上显示了使用 UML 建模的结构或静态视图。 它将成为参数化协作的一部分，然后会绑定到实参上对模式进行实例化。

构架风格软件构架（或仅是构架视图）可以具有名为构架风格的属性，该属性减少了可选的形式，并使构架具有一定程度的一致性。样式可以通过一组模式或通过选择特定构件或连接器作为基本构件来定义。对给定系统，某些样式可作为构架描述的一部分记录在构架风格指南（Rational Unified Process 中设计指南文档的一部分）中。样式在构架的可理解性与完整性方面起着主要的作用。

逻辑视图：类图、状态机和对象图。进程视图：类图与对象图（包括任务 – 进程与线程）。实施视图：构件图。部署视图：配置图。

技巧

1. 单一的目标：Amundsen唯一的目标就是以最快的速度抵达目标，而Scott则要兼顾科学研究。

对于Scott来说，科学研究这个使命甚至优于资源与人员配备。而Amundsen的所有目的都是赢得比赛，还有平安归来。

想比之下Scott的双重目标存在很多矛盾。不错，那时确实不乏悠久的帆船科学研究历史（比如达尔文），然而达尔文并不是进行比赛，他们的船很大，同时科学研究只是附加目标，而环境也远没有南极那么恶劣及荒无人烟。

Fred Wilson在谈专注的力量时 经常引Steve Jobs为例——“我们专注于打造一个适合所有场景电脑的生产线，然后逐渐关闭其它的生产线”。专注是类似Minimal Viable Products及 time box scheduling产品背后的原动力，Amundsen专注在比赛上，所以一切策略都以这个为目标展开。

2. 使用简单，已被验证的技术。比赛中最难以接受的就是Scott的计划选择了一组复杂且未经验证的运输技术。

Amundsen的计划是简单的，他们选用狗拉雪橇；而在那时，狗拉雪橇的这个技术无疑是得到论证的，因此奇怪的应该是不选用狗的人。

然而在早先的旅行中Scott对狗有着非常不好的体验，所以他并未选用这个运输途径。取而代之的是，Scott选用了motor-sledge，这是机动雪橇的早期版本。在那个时候，这还是个试验中的技术，最终3架motor-sledge都在途中损坏。然而当下的问题不是讨论他们为什么有那么差的体验，而土著人民却非常善于用狗，而是缺乏对事物的详细了解并往下定论。

小马的任务是搬运补给，但是很小的蹄子让其不能胜任工作，因为它很容易受到潮湿和冰冻的侵害。9匹小马在旅行开始时就失去了作用，然而马和motor-sledge的补给只能储存在船上。对比而言，狗无疑更适应战场，它们可以吃南极洲捕获的企鹅和海豹肉。

使用人力拉沉重的雪橇，本来只作为应急，但是马和motor-sledge的缺失让这个方案执行了3/4的旅途。而雪橇还在不停变重，因为沿途他们不得不收集一些岩石以作科学研究。这样，问题就在于他们根本没有足够的食物以支撑整个过程。他们并不清楚，一天吃4000卡路里的他们却需要消耗6000到10000卡路里的能量。

3. 定制、测试、重复。Amundsen的计划很周密，不留任何漏洞。当他发现设备达不到需求时，会自己动手，他亲自做了防风镜、滑雪板、犬绳及肉干。这种自力更生正是开发者需要具备的品质：

所有Amundsen的工具都出自自己的工坊，并经过一次又一次的提炼。Amundsen在制造工具时使用了两个信条：第一，远甚于批量生产的设备；第二，参与制造，可以确保设备在比赛中的表现。

4. 冷静且无情的。捕获焦点，必须具备认知重点的能力，只做必要的事情。

Walter Sullivan在The South Pole Fifty Years After使用另一个方式完美的阐述了这个道理：

登月通过一连串的火箭完成，而在这个过程中这些火箭被逐一抛弃；那个挪威人使用了同样的策略，在旅途中不断抛弃虚弱的动物，并且作为其它动物和人的食物。

5. 灵活的。Amundsen原计划是去北极，但是在听说两个美国人已经抵达北极后，果断的将目标转向了南极，以获取世界第一这个奖励。

6. 从实际出发。Scott使用人拉雪橇不仅仅是为了运输，更加入了一种浪漫主义风格。Scott日记的背后甚至反射出Wagner的身影：

在我的记忆中，没有任何与狗有关的探险可以达到这样的高度——人们直面险阻，并用自己的双手达到目的……无可否认的是，在这种情况下，征服才是更高贵、更华丽的胜利。

7. 技巧让一切都变得不同。Amundsen招募了多个经验老道的滑雪人并组成团队，相比，Scott的队伍无疑都是一些门外汉，并未针对需求进行训练。

8. 选择正确的团队。Scott的团队有许多来自英国的绅士，而Amundsen则选择了一些具有户外经验并有不同技能的工匠。

9. 错误的叠加。Scott的团队注定无法赢得比赛，然而他们的死亡却是由一系列的错误叠加引起。天气比预期的更冷，这样导致他们返程时在预定时间并未到达下一个补给点，补给点存放了食物、燃料及其他物资。当Scott、Wilson和Bowers三人死亡时，离下一个补给点仅11英里远。马、motor-sledge及一个错误的补给点判断，让下一个补给点离他们遥遥无期。悲剧的铸成绝不因一个错误，而是由一系列错误叠加形成。

10. 后见之明。在事情开始时没有什么是清晰可见的，然而在结果产生时一切都已尘埃落定。Scott在开始时做了他认为最合适的决策，而其它人也同意他的观点。每一个项目也是如此，没有人会愚蠢到从开始就放弃；然而通往成功的路径总是很少，并且沿途充满了太多的岔路。所以我们有必要去吸取一些成功的经验，多了解一些最佳实践。

忆往昔，不难发现成功的团队总是具备一些共同的特性：规模小、良好的引导、专注、高技巧及具备丰富的经验，同时他们还有着健壮的计划、丰富的资源以及强大的战场适应能力。

实践

实践中的理解

软件架构是对软件系统运行时元素的抽象，软件系统可能有很多层抽象，或由多重业务流程所组成，每层抽象或每个业务流程都有自己的软件架构。

软件架构是平衡的艺术。