目录本文的目标读者是那些希望理解 Microsoft 在企业、应用程序和技术体系结构方面提供的方法的商业、软件和基础设施体系结构设计师。它包括体系结构的术语、模式、概念和定义，以及体系结构的一系列视图。 企业体系结构ANSI/IEEE Std 1471-2000 中使用的体系结构定义是：“一个系统的基本组织，表现为系统的组件、组件之间的相互关系、组件与环境之间的相互关系以及设计和进化的原理。” 企业体系结构 (EA) 是帮助组织理解自己的结构及其原理的概念工具。它提供了企业的结构图，是业务和技术变化的规划工具。 一般来说，企业体系结构表现为一整套相互关联的模型，这些模型描述了企业的结构和功能。企业体系结构主要用于系统化的 IT 规划和架构，以及改进的决策过程。 EA 中的各个模型以逻辑方式来排列，可以使企业的详细信息处于不断增长中，包括：
Microsoft 体系结构剖析企业体系结构中的信息可以从不同角度来审视，并且可以满足各种需要。体系结构的用户包括业务经理和分析员、系统体系结构设计师、工作流程和程序分析员、后勤专家、组织分析员等。这些人员要求有高级的概括信息、详细的数据和各种级别的中间数据。这些需要通过创建概念视图、逻辑分析和物理实现来满足。 在 Microsoft，我们发现了四个重要并且常用的基本审视角度。它们是业务、应用程序、信息和技术角度。 业务角度“业务角度”描述了业务的运作方式。它包括广泛的商业策略，以及为了将组织从当前状态推进到构想的未来状态而做的计划。一般包括以下内容：
应用程序角度“应用程序角度”定义了企业的资产应用，以应用程序为中心。一般包括下列内容：
应用程序角度可表示跨组织的服务、信息和功能，连接具有不同技能和技术的用户以便达到共同的业务目标。 信息角度“信息角度”描述了组织在业务处理和运作过程中需要知道的信息。包括下列内容：
信息角度还描述了数据与工作流程关联的方式，包括整个组织中存在的结构化数据存储（如数据库）和非结构化数据存储（如文档、电子表格和演示文稿等）。 技术角度“技术角度”对组织提供硬件和软件支持。它包括但不仅限于：
技术角度对支持应用程序和信息角度所需的基础设施和系统组件提供了逻辑化的、独立于供应商的描述。它定义了一套完成业务所需的技术标准和服务。 尽管有许多角度，但是从这些角度看到的只是一个企业体系结构。企业体系结构的价值不在于任何一个单独的角度，而在于各角度之间的相互关系、相互作用和相互依赖。 尽管所有角度都是企业体系结构的关键元素，本文仍将集中讨论应用程序和技术角度。 应用程序和技术体系结构软件系统的“功能”需求描述了软件提供的商业价值。对于天气预报服务来说，功能需求可以描述为“将组织良好的信息 A 作为输入，服务将返回对于信息 A 所表示的时间跨度和地理位置来说正确的信息 B”。 “应用程序体系结构”是自动服务的体系结构，用于支持和实现这样的业务需求，包括该业务与其他应用程序之间的接口。它描述了应用程序的结构，以及该结构如何实现组织的功能需求。虽然在理想情况下，一个组织应该只有一个应用程序体系结构，但实际上，一个组织往往会有许多不同的应用程序体系结构。 软件系统的“运作”需求定义了软件的可靠性、可管理性、性能、安全性和互操作性等。常见的例子是仅对授权用户开放的服务，这种服务要求在 99.999% 的时间内都能正确实现它的功能。 “技术体系结构”是支持组织以及实现运作（非功能）需求（尤其是组织的应用程序和信息体系结构）的硬件和软件基础设施的体系结构。它描述了所使用技术的结构和内部关系，以及这些技术如何支持组织的运作需求。 好的技术体系结构可以提供安全性、可用性和可靠性，还可以支持各种其他运作需求。但是如果应用程序的设计没有利用技术体系结构的优点的话，它的执行效果会很差，或者会难以部署和运作。同样，即使一个优秀的应用程序体系结构是通过使用最新的技术、利用可重用软件组件来构建的，能很好地满足业务过程的需求，它也可能不能很好地反映实际的技术配置，例如：服务器没有经过正确配置来支持应用程序组件，网络硬件设置不能支持信息流等。这显示了应用程序体系结构和技术体系结构之间的相互关系：一个好的技术体系结构能够支持组织中关键的应用程序，而一个好的应用程序体系结构能够充分利用技术体系结构，在整个运作需求中提供一致的性能。
图 1：体系结构之间的关系 概念、逻辑和物理视图所有体系结构角度都有多种体系结构视图，通常分为概念、逻辑和物理视图。“概念视图”是最抽象的视图，一般用系统用户（非 IT 专业用户）熟悉的术语来描述。概念视图用于定义应用程序的功能需求和商业用户视图，以便生成业务模型。“逻辑视图”显示了主要的功能组件和它们在系统中的关系，而不涉及功能的实现细节。体系结构设计师创建的“应用程序模型”就是业务模型的逻辑视图，因为它们决定了如何满足业务目标和需求。应用程序模型表示应用程序体系结构的逻辑视图。“物理视图”是最不抽象的，它们表示特定的实现组件和它们之间的关系。物理视图中的每个元素一般都由设计和开发过程来实现，如软件和硬件系统。“实现视图”通常归组织的开发或运作部门管理，因此不在本文的讨论范围内。
图 2：体系结构视图 每一个体系结构级别均可能有（事实上通常都会有）多个视图，例如，每个应用程序通常都会有一个逻辑应用程序体系结构。 这些视图由一组需求来驱动，反过来又会生成设计、开发、配置和运作过程及系统的输入。
图 3：体系结构视图和模式 本指南的其余部分将集中讨论应用程序和技术体系结构，以及利用 Web 服务技术构造基于服务的应用程序的概念和关键模式。虽然实现部分（包括设计、开发、配置、部署和管理）对于总体系统的生成十分重要，但是不在本文的讨论范围内。 应用程序体系结构如前所述，应用程序体系结构提供了三种视图：概念、逻辑和物理视图。体系结构设计师可以使用这些视图在组织中生成支持和满足其业务需求的模型。理想情况下，每个视图只有一个模型，但实际上每个视图可能有多个模型，这是由于组织和技术在不断成长和改变。然而，是否能得到这些模型的合理的最小集合是组织是否灵活、高效的关键。 概念视图概念视图用于定义应用程序的业务需求和商业用户视图，以便生成“业务模型”。概念性建模技术（如用例分析、活动图解、过程设计和业务实体建模等）有助于构建关键业务过程及其使用的数据的描述，可以强调业务目标和需求，并且不包含实现技术。 逻辑视图体系结构设计师创建的“应用程序模型”就是业务模型的逻辑视图，因为它们决定了如何满足业务目标和需求。应用程序模型表示应用程序体系结构的逻辑视图。 体系结构设计师关心的是应用程序的总体结构。他们决定数据管理和处理步骤的对应关系，根据逻辑信息和顺序设计模型部件之间的交互，并确定模型保留的数据类型和状态。 物理视图应用程序模型的每个元素均要求映射到真正的技术元素。通过这种方法，应用程序模型以“实现模型”的方式得以实现。当程序员将详细的业务逻辑编写成代码时，常规的开发过程承担了部分实现任务，但大部分实现活动应归为框架完成。框架完成是一种开发技术，大多数分布式应用程序和数据管理的基础设施都是由复杂的框架处理的，而这些框架由自定义的应用程序逻辑和公布的控件结构进行了扩展。框架完成使开发人员避免了繁琐的工作（例如错综复杂的异步消息处理），使普通开发人员能够对项目作出更大的贡献。 为组织规划和构建不同级别的模型是一项相当费时费力的工作。而且，能否正确定义这些模型对于组织来说也是至关重要的。体系结构模型的设计错误总是会导致严重的设计问题或运作问题（例如可伸缩性和可靠性问题），严重时甚至会导致项目无法完成以及影响业务。体系结构设计师正在寻找框架和指南以帮助他们创建和实现这些模型，并把由于使用错误模型而带来的风险降到最低。 体系结构设计师可以使用两种体系结构指南和帮助来加快建模速度和降低风险。 第一是一组体系结构概念，它们提供：
第二是一组模式，基于大量成功的分布式应用程序的实际经验，由这些基本概念组成。这些模式通过提供优秀的、经过测试的体系结构模型，封装了重要的最佳分布式应用程序设计实例，并且能使项目失败的风险降到最低。
图 4：应用程序体系结构的视图 这两组指南（概念和模式）在概念级（它们是企业模型概念和模式）、逻辑级（它们是应用程序概念和模式）和技术级都有对应的指南。提供这些概念和模式对于在组织中成功、快速和高效地实现系统以及采用技术是十分关键的。 应用程序体系结构：概念视图过去，应用程序的构建是通过集成本地系统服务（如文件系统和设备驱动程序）来实现的。这种模型在访问丰富的开发资源以及精确控制应用程序的行为方面提供了很大的灵活性，但同时也容易出错、成本较高并且较为费时。 现在，可以通过集成整个网络上现有的应用程序和服务，然后使用诸如业务实体、数据实体和其他方面在其上提供独特的附加价值，来构造复杂的分布式应用程序。这就使开发人员能够将注意力集中于提供独特的业务价值，从而减少进入市场的时间，提高开发效率，并且最终开发出高质量的软件。多年来，这一直是一个强大的体系结构模型，但它产生了“应用程序通风口”或“信息孤岛”，而这在体系结构重用中会引起重大问题。 现在，我们进入下一个计算阶段。这个阶段通过 Internet 和 Web 服务概念来实现，能够创建可以随时随地使用的强大的应用程序。它增加了应用程序的应用范围，并且可以不断交付软件。在这种情况下，软件即服务 - 一种通过通信网络来订购和使用的服务。 .NET 通过结合 N 层计算的高效的紧耦合特点以及 Web 以信息为导向的松耦合概念来推进了这种理念。这种计算方式称为“XML Web Service”。它代表了下一代应用程序开发技术，并且是概念性应用程序体系结构的基础。 Web 服务是应用程序逻辑的有效单元，它们提供了基于消息的、适合通过网络访问的接口。通常，服务既提供业务逻辑，也提供与要解决的问题相关的状态管理。在设计服务时，您的目标是有效地封装与现实世界中的过程相关的逻辑和数据，对要包括在内的内容和要作为独立服务实现的内容作出明智的选择。 状态处理由业务规则来管理。业务规则是相对稳定的算法（例如从商品清单汇总出发票的方法），一般是作为应用程序逻辑来实现的。 服务由策略来管理。与业务规则相比，策略的稳定性较差，并且可能是区域性的或针对特定客户的。策略一般是通过在运行时查阅表格来驱动的。 因此，服务的更完整的定义应该是：“服务是能在网络上运行的软件单元，它通过消息来实现逻辑、管理状态和通信，并且由策略来管理。” 应用程序的概念视图在 Application Architecture: Conceptual View（英文）中有详细介绍。 应用程序模式模式是问题在环境中的解决方案。模式将从某个领域内收集的特定知识整理成文。应用程序模式是体系结构级的模式，它定义了体系结构设计在特定应用程序环境中的最佳实例。 模式有许多种分类法可以作为特定模式的定义和解释，但不在本文的讨论范围内。许多现有的体系结构模式都可以应用到基于 Web 服务的体系结构中，但在 Web 服务的新结构还带来了大量新的模式。 技术体系结构与应用程序体系结构相似，技术体系结构也提供了三种视图：概念、逻辑和物理视图。体系结构设计师可以使用这些视图在组织中生成支持和满足其运作需求的模型。就象应用程序一样，应当只有一个技术体系结构，但实际上由于组织和技术在不断成长和改变，几乎总是存在多个技术体系结构。组织的一个关键需求是将这些完全不同的技术体系结构集成到一个完整的体系结构中，以便重用现有的应用程序，并使这些技术体系结构达到合理的最小集合。这样一个公共的体系结构对于创建高效、灵活的组织是至关重要的。 概念视图技术体系结构的概念视图用于将技术领域制定为结构和框架。它用于定义、命名和定位 IT 供应商和使用技术的组织都能理解的领域，确保在实现组织的运作或非功能性需求时所需的所有技术领域都得到定义并可供组织使用。 逻辑视图技术体系结构的逻辑视图是主要的功能元素，它们提供对企业级运作需求的支持，并提供相互之间的内部关系。企业技术元素（例如数据库、邮件系统、交易支持和可靠的消息传送）是在逻辑视图中提供的。在这个级别上提供的技术通常由企业软件供应商与服务器一起提供。 物理视图技术体系结构的每个元素均需要映射到硬件和软件的实际技术元素上。通过这种方法，技术体系结构可以实现为网络、服务器、操作系统等的完整系统。实际的物理位置、服务器产品名称和连接都显示在这个级别上。 体系结构设计师正在从 IT 供应商处寻找框架和指南，以帮助他们构建能满足组织运作需求的系统，并确保组织的技术与 IT 供应商的技术相一致。 技术体系结构：概念视图技术概念体系结构是在组织中建立企业级 Web 服务的技术基础。技术概念体系结构的高级图表显示了一组一般的级别，为 Web 服务的生成提供了基于企业的服务。这些级别包含 Web 服务应用程序或系统所需的公共元素。
图 5：技术体系结构的概念视图 图表的底部是“服务平台”，它提供了操作系统、硬件、存储、联网以及整个系统的信任和管理服务。 “服务框架”提供基于 Web 服务的应用程序所需的过程、逻辑、功能和状态管理，也是专门支持 Web 服务的完整的企业应用程序服务器。 “服务传递”包含门户和客户端服务，主要用于提供问题和技术，包括对各种设备的支持。 “服务集成”提供了服务与以下现有操作系统之间的集成和互操作：旧应用程序、商用应用程序、数据库和其他 Web 服务。这通常称为企业应用程序集成 (EAI)。 最后，“服务创建和部署”提供了设计、开发、组装、管理、部署和测试 Web 服务所需的工具、过程、方法和模式。 技术体系结构的概念视图在 Technology Architecture: Conceptual View（英文）中有详细介绍。 技术模式技术模式是体系结构级的模式，它定义了体系结构设计在特定应用程序环境中的最佳实例。企业体系结构设计师正在为组织寻找以下关键领域的指南和最佳实例：
|
