Microsoft 体系结构概述

 

2002 年 7 月

Michael Platt

Microsoft Corporation

本文的目标读者是那些希望理解 Microsoft 在企业、应用程序和技术结构方面提供的方法的商业、软件和基础设施结构设计师。它包括结构的术语、模式、概念和定义，以及结构的一系列视图。

本页内容

	企业体系结构
	应用程序和技术结构
	概念视图、逻辑视图和物理视图
	应用程序结构
	应用程序模式
	技术结构
	技术模式

企业体系结构

在 ANSI/IEEE Std 1471-2000 中使用的体系结构的定义为： “一个系统的基本组织，通过组件、组件之间和组件与环境之间的关系以及管理其设计和演变的原则具体体现。”

企业体系结构 (EA) 是帮助组织理解自己的结构及其原理的概念工具。它提供了企业的结构图，是业务和技术变化的规划工具。

一般来说，企业结构表现为一整套相互关联的模型，这些模型描述了企业的结构和功能。企业结构主要用于系统化的 IT 规划和架构，以及改进的决策过程。

EA 中的各个模型以逻辑方式来排列，可以使企业的详细信息处于不断增长中，包括：

•	目的和目标
•	过程和组织
•	系统和数据
•	使用的技术

Microsoft 结构剖析

企业结构中的信息可以从不同角度来审视，并且可以满足各种需要。结构的用户包括业务经理和分析员、系统结构设计师、工作流程和程序分析员、后勤专家、组织分析员等。这些人员要求有高级的概括信息、详细的数据和各种级别的中间数据。这些需要通过创建概念视图、逻辑分析和物理实现来满足。

在 Microsoft，我们发现了四个重要并且常用的基本审视角度。它们是业务、应用程序、信息和技术角度。

业务角度

业务角度描述了业务的运作方式。它包括广泛的商业策略，以及为了将组织从当前状态推进到构想的未来状态而做的计划。一般包括以下内容：

•	企业的高级目标
•	整个企业或企业的重要部分实施的业务过程
•	执行的业务功能
•	主要的组织结构
•	各元素之间的相互关系

应用程序角度

应用程序角度定义了有关企业中应用程序的公文包并且以应用程序为中心的内容。一般包括下列内容：

•	标准数据模型
•	数据管理策略
•	组织中信息产生和使用的模式说明

信息角度还描述了数据与工作流程关联的方式，包括整个组织中存在的结构化数据存储（例如，数据库）和非结构化数据存储（例如，文档、电子表格和演示文稿等）。

技术角度

技术角度对组织提供硬件和软件支持。它包括但不仅限于：

•	台式机和服务器硬件
•	操作系统
•	网络连接组件
•	打印机
•	调制解调器

技术角度对支持应用程序和信息角度所需的基础设施和系统组件提供了逻辑化的、独立于供应商的描述。它定义了一套完成业务所需的技术标准和服务。

尽管有许多角度，但是从这些角度看到的只是一个企业结构。企业结构的价值不在于任何一个单独的角度，而在于各角度之间的相互关系、相互作用和相互依赖。

尽管所有角度都是企业结构的关键元素，本文仍将集中讨论应用程序和技术角度。

返回页首

应用程序和技术结构

软件系统的功能需求描述了软件提供的商业价值。对于天气预报服务来说，功能需求可以描述为“将组织良好的信息 A 作为输入，服务将返回对于信息 A 所表示的时间跨度和地理位置来说正确的信息 B”。

应用程序结构是自动服务的结构，用于支持和实现这样的业务需求，包括该业务与其他应用程序之间的接口。它描述了应用程序的结构，以及该结构如何实现组织的功能需求。虽然在理想情况下，一个组织应该只有一个应用程序结构，但实际上，一个组织往往会有许多不同的应用程序结构。

软件系统的运作需求定义了软件的可靠性、可管理性、性能、安全性和互操作性等。常见的例子是仅对授权用户开放的服务，这种服务要求在 99.999% 的时间内都能正确实现它的功能。

技术结构是支持组织以及实现运作（非功能）需求（尤其是组织的应用程序和信息结构）的硬件和软件基础设施的结构。它描述了所使用技术的结构和内部关系，以及这些技术如何支持组织的运作需求。

好的技术结构可以提供安全性、可用性和可靠性，还可以支持各种其他运作需求。但是如果应用程序的设计没有利用技术结构的优点的话，它的执行效果会很差，或者会难以部署和运作。同样，即使一个优秀的应用程序结构是通过使用最新的技术、利用可重用软件组件来构建的，能很好地满足业务过程的需求，它也可能不能很好地反映实际的技术配置，例如：服务器没有经过正确配置来支持应用程序组件，网络硬件设置不能支持信息流等。 从而显示出应用程序结构和技术结构之间的关系： 通过构建良好的技术结构来支持对组织来说至关重要的特定应用程序；良好的应用程序结构利用技术结构为满足整个运作需求提供始终如一的性能。

图 1. 结构之间的关系

返回页首

概念视图、逻辑视图和物理视图

所有结构角度都有多种结构视图，通常分为概念视图、逻辑视图和物理视图。概念视图是最抽象的视图，一般用系统用户（非 IT 专业用户）熟悉的术语来描述。概念视图用于定义应用程序的功能需求和商业用户视图，以便生成业务模型。逻辑视图显示了主要的功能组件和它们在系统中的关系，而不涉及功能的实现细节。架构师创建的应用程序模型就是业务模型的逻辑视图，因为它们决定了如何满足业务目标和需求。应用程序模型表示应用程序结构的逻辑视图。物理视图是最不抽象的，它们表示特定的实现组件和它们之间的关系。物理视图中的每个元素一般都由设计和开发过程来实现，如软件和硬件系统。实现视图通常归组织的开发或运作部门管理，因此不在本文的讨论范围内。

图 2. 结构视图

每一个结构级别均可能有（事实上通常都会有）多个视图，例如，每个应用程序通常都会有一个逻辑应用程序结构。

这些视图由一组需求来驱动，反过来又会生成设计、开发、配置和运作过程及系统的输入。

图 3. 结构视图和模式

本指南的其余部分将集中讨论应用程序和技术结构，以及利用 Web Service 技术构造基于服务的应用程序的概念和关键模式。虽然实现部分（包括设计、开发、配置、部署和管理）对于总体系统的生成十分重要，但是不在本文的讨论范围内。

返回页首

应用程序结构

如上所述，应用程序结构提供了三种视图： 概念视图、逻辑视图和物理视图。结构设计师可以使用这些视图在组织中生成支持和满足其业务需求的模型。理想情况下，每个视图只有一个模型，但实际上每个视图可能有多个模型，这是由于组织和技术在不断成长和改变。然而，是否能得到这些模型的合理的最小集合是组织是否灵活、高效的关键。

概念视图

概念视图用于定义应用程序的业务需求和商业用户视图，以便生成业务模型。概念性建模技术（例如，用例分析、活动图解、过程设计和业务实体建模等）有助于构建关键业务过程及其使用的数据的描述，可以强调业务目标和需求，并且不包含实现技术。

逻辑视图

结构设计师创建的应用程序模型就是业务模型的逻辑视图，因为它们决定了如何满足业务目标和需求。应用程序模型表示应用程序结构的逻辑视图。

结构设计师关心的是应用程序的总体结构。他们决定数据管理和处理步骤的对应关系，根据逻辑信息和顺序设计模型部件之间的交互，并确定模型保留的数据类型和状态。

物理视图

应用程序模型的每个元素均要求映射到真正的技术元素。通过这种方法，应用程序模型以实现模型的方式得以实现。当程序员将详细的业务逻辑编写成代码时，常规的开发过程承担了部分实现任务，但大部分实现活动应归为框架完成。框架完成是一种开发技术，大多数分布式应用程序和数据管理的基础设施都是由复杂的框架处理的，而这些框架由自定义的应用程序逻辑和公布的控件结构进行了扩展。框架完成使开发人员避免了繁琐的工作（例如，错综复杂的异步消息处理），使普通开发人员能够对项目作出更大的贡献。

为组织规划和构建不同级别的模型是一项相当费时费力的工作。而且，能否正确定义这些模型对于组织来说也是至关重要的。结构模型的设计错误总是会导致严重的设计问题或运作问题（例如，可伸缩性和可靠性问题），严重时甚至会导致项目无法完成以及影响业务。结构设计师正在寻找框架和指南以帮助他们创建和实现这些模型，并把由于使用错误模型而带来的风险降到最低。

结构设计师可以使用两种结构指南和帮助来加快建模速度和降低风险。

第一是一组结构概念，它们提供：

•	一般的理解和通信
•	关于如何以及何时使用某个概念的指南，以及有关其属性的信息。
•	根据这些指南或实际的技术，何时可以实现和使用这些概念的指示。

第二是一组模式，基于大量成功的分布式应用程序的实际经验，由这些基本概念组成。这些模式通过提供优秀的、经过测试的结构模型，封装了重要的最佳分布式应用程序设计实例，并且能使项目失败的风险降到最低。

图 4. 应用程序结构视图

这两组指南（概念和模式）在概念级（它们是企业模型概念和模式）、逻辑级（它们是应用程序概念和模式）和技术级都有对应的指南。提供这些概念和模式对于在组织中成功、快速和高效地实现系统以及采用技术是十分关键的。

应用程序结构： 概念视图

过去，应用程序的构建是通过集成本地系统服务（如文件系统和设备驱动程序）来实现的。这种模型在访问丰富的开发资源以及精确控制应用程序的行为方面提供了很大的灵活性，但同时也容易出错、成本较高并且较为费时。

现在，可以通过集成整个网络上现有的应用程序和服务，然后使用诸如业务实体、数据实体和其他方面在其上提供独特的附加价值，来构造复杂的分布式应用程序。这就使开发人员能够将注意力集中于提供独特的业务价值，从而减少进入市场的时间，提高开发效率，并且最终开发出高质量的软件。多年来，这一直是一个强大的结构模型，但它产生了“应用程序通风口”或“信息孤岛”，而这在结构重用中会引起重大问题。

.NET 通过结合 N 层计算的高效的紧耦合特点以及 Web 以信息为导向的松耦合概念来推进了这种理念。这种计算方式称为 XML Web Service。它代表了下一代应用程序开发技术，并且是概念性应用程序结构的基础。

Web Service 是应用程序逻辑的离散单元，它们提供了基于消息的、适合通过网络访问的接口。通常，服务既提供业务逻辑，也提供与要解决的问题相关的状态管理。在设计服务时，您的目标是有效地封装与现实世界中的过程相关的逻辑和数据，对要包括在内的内容和要作为独立服务实现的内容作出明智的选择。

状态处理由业务规则来管理。业务规则是相对稳定的算法（例如，从商品清单汇总出发票的方法），一般是作为应用程序逻辑来实现的。

服务由策略来管理。与业务规则相比，策略的稳定性较差，并且可能是区域性的或针对特定客户的。策略一般是通过在运行时查阅表格来驱动的。

因此，服务的更完整的定义应该是：“服务是能在网络上运行的软件单元，它通过消息来实现逻辑、管理状态和通信，并且由策略来管理。”

在应用程序结构：概念视图中将详细讨论应用程序的概念视图。

返回页首

应用程序模式

模式是问题在环境中的解决方案。模式将从某个领域内收集的特定知识整理成文。应用程序模式是结构级的模式，它定义了结构设计在特定应用程序环境中的最佳实例。

模式有许多种分类法可以作为特定模式的定义和解释，但不在本文的讨论范围内。许多现有的结构模式都可以应用到基于 Web Service 的结构中，但在 Web Service 的新结构还带来了大量新的模式。

返回页首

技术结构

与应用程序结构一样，技术结构也提供了三种视图： 概念视图、逻辑视图和物理视图。结构设计师可以使用这些视图在组织中生成支持和满足其运作需求的模型。就象应用程序一样，应当只有一个技术结构，但实际上由于组织和技术在不断成长和改变，几乎总是存在多个技术结构。组织的一个关键需求是将这些完全不同的技术结构集成到一个完整的结构中，以便重用现有的应用程序，并使这些技术结构达到合理的最小集合。这样一个公共的结构对于创建高效、灵活的组织是至关重要的。

概念视图

技术结构的概念视图用于将技术领域制定为结构和框架。它用于定义、命名和定位 IT 供应商和使用技术的组织都能理解的领域，确保在实现组织的运作或非功能性需求时所需的所有技术领域都得到定义并可供组织使用。

逻辑视图

技术结构的逻辑视图是主要的功能元素，它们提供对企业级运作需求的支持，并提供相互之间的内部关系。企业技术元素（例如，数据库、邮件系统、交易支持和可靠的消息传送）是在逻辑视图中提供的。在这个级别上提供的技术通常由企业软件供应商与服务器一起提供。

物理视图

技术结构的每个元素均需要映射到硬件和软件的实际技术元素上。通过这种方法，技术结构可以实现为网络、服务器、操作系统等的完整系统。实际的物理位置、服务器产品名称和连接都显示在这个级别上。

结构设计师正在从 IT 供应商处寻找框架和指南，以帮助他们构建能满足组织运作需求的系统，并确保组织的技术与 IT 供应商的技术相一致。

技术结构： 概念视图

技术概念结构是在组织中建立企业级 Web Service 的技术基础。技术概念结构的高级图表显示了一组一般的级别，为 Web Service 的生成提供了基于企业的服务。这些级别包含 Web Service 应用程序或系统所需的公共元素。

图 5. 技术结构的概念视图

图表的底部是“服务平台”，它提供了操作系统、硬件、存储、联网以及整个系统的信任和管理服务。

“服务框架”提供基于 Web Service 的应用程序所需的过程、逻辑、功能和状态管理，也是专门支持 Web Service 的完整的企业应用程序服务器。

“服务传递”包含门户和客户端服务，主要用于提供问题和技术，包括对各种设备的支持。

“服务集成”提供了服务和以下现有的运作系统之间的集成和互操作： 旧式应用程序、商业应用程序、数据库和其他 Web 服务。这通常称为企业应用程序集成 (EAI)。

最后，“服务创建”提供了设计、开发、组装、管理、部署和测试 Web Service 所需的工具、过程、方法和模式。

在应用程序结构：概念视图中将详细讨论应用程序的概念视图。

返回页首

技术模式

技术模式是结构级的模式，它定义了结构设计在特定应用程序环境中的最佳实例。企业结构设计师正在为组织寻找以下关键领域的指南和最佳实例

•	安全性、身份识别和信任
•	未来系统和现有操作（旧的）系统之间的集成和互操作
•	部署、监控和管理
•	分布式技术结构的可伸缩性和性能
•	技术结构的可靠性和可用性

转到原英文页面

返回页首