设计分布式系统以进行部署
Bill Gibson 和 Alex Torone
Microsoft Corporation
适用范围：
Microsoft Visual Studio® 2005 Team System
摘要：本文介绍了 Visual Studio 2005 Team System 中用于构建分布式应用程序的软件设计工具。
注意：本文档在产品投入生产前编写，部分细节可能与实际产品不一致。文中的信息均依据当时的产品状况，仅供您在规划时参考。如有更改，恕不另行通知。Microsoft 对本文档中的主题持有专利权、专利申请权、商标权、版权或其他相关的知识产权。Microsoft 只提供在任何书面许可协议中明确规定的权利，而不授予您本文档的上述专利权、商标权、版权或其他知识产权。
本页内容
| 引言 | |
| 设计分布式系统的难题 | |
| 改进分布式系统的设计和部署 | |
| “分布式系统设计器”概述 | |
| 扩展性 | |
| 与 Visual Studio 2005 Team System 集成 | |
| 结论 |
引言
“分布式系统设计器”由各种支持分布式系统图形设计和验证的工具组成。该工具集面向应用程序体系结构设计者、设计人员、开发人员和操作体系结构设计者。“分布式系统设计器”是源于 Dynamic Systems Initiative (DSI) 的早期工具，旨在改进企业级分布式系统的开发、部署和管理。有关 DSI 的详细信息，请参阅 Microsoft Dynamic Systems Initiative。这些工具是 Visual Studio 2005 Team System 的一部分。
面向服务的体系结构是下一代分布式应用程序的基础。Microsoft“Indigo”平台将实现业界领先的面向服务的系统。“Indigo”将建立于当前 Windows 平台提供的 SOAP 和 Web 服务支持之上，并增加了传输和系统拓扑结构的广泛支持。同时，它还将在服务与服务之间实现安全、可靠且持久的基于消息的通信。Indigo 平台本身有诸多重大改进，企业现在便可以使用 SOAP、XML 消息传递和 ASP.NET Web 服务来开发面向服务的系统。有关详细信息，请参阅 Indigo。
设计分布式系统的难题
设计和部署分布式系统是一个相当复杂的过程。本节说明了一些可能出现的问题。
使分布式系统的设计可视化
使系统结构可视化并作为一个整体已变得越来越困难。原因就在于，在面向服务的体系结构中系统越发地支离破碎。此外，随着时间的推移，企业一般会形成很多不同的系统，如采购部门、开发部门。这些系统中的应用程序也可能各式各样。由于各系统所采用的编程技术数量千差万别，在它们之间共享功能和数据一般非常困难。为了实现互操作，设计基于消息的界面已日益成为对开发人员和体系结构设计者的一项基本要求；设计新消息并确保与现有消息架构兼容至关重要。经由消息而实现的互操作是面向服务的体系结构的核心。
保持设计与代码同步
为了保持系统设计文档最新，体系结构的设计者和开发人员之间一定要加强交流。然而，一旦开始编写代码（即便是出于完善的目的），系统设计文档常常会变得过时且不准确。但这种使设计文档与变化迅速的代码同步的艰巨任务很快要成为过去。
部署设计
软件和硬件供应商常认为开发人员了解平台配置（SQL、IIS、BizTalk 等）的每个细微差别，并认定操作管理能完全识别应用程序开发人员使用的框架和消息协议。尽管操作应是总体软件开发生命周期的一部分，但该部分在组织上和功能上都与开发分离。操作人员与开发人员基本上不主动协作，双方一般是被动地合作，通常是在开发后期诊断可早期预防的问题。
请试着开发和部署简单的 Web 服务。虽然开发人员的关注焦点是实现服务，但仍需考虑以下方面：安全性、身份验证模型、目标环境所需的其他支持服务、使 Web 服务按预期运行所需的配置设置。对于操作而言，必须能识别新服务所需的协议与服务，以及企业 IT 策略是否得以遵循。将开发与操作分隔将导致部署问题（结果常是配置不匹配），严重的将导致设计与数据中心不兼容（结果使大量的 IT 预算浪费在纠正部署问题上）。
尽管很多企业试图通过文档、设计审查及精心绘制的图表来解决上述问题，但往往由于缺少相关的工具和公共语言而无法有效地实施和传达策略。此外，这些过程到目前为止并未出现在开发人员和操作人员的日常工具中，因此过程本身存在一定的问题。
为安全性配置应用程序
确保分布式应用程序的安全是一项既耗时又复杂的过程，其中涉及大量影响应用程序设计的技术和设置。目前，尚未出现一种集成的方法来在设计应用程序时表现应用程序的安全配置或数据中心的安全要求。因此，确保正确实施安全性确实非常困难。
改进分布式系统的设计和部署
“分布式系统设计器”是一种集成的设计工具，其目标是实现分布式系统的可视化设计和验证。设计器使用“系统定义模型”(SDM) 作为描述应用程序服务及运行时环境的连接状态、配置情况与相互关系的基础元模型。SDM 基于多层模型，该模型包括应用程序、应用程序宿主环境、网络拓扑、操作系统和物理设备。该模型不仅允许“分布式系统设计器”描述每层的设计，而且还允许它表达各层的约束和策略以便跨越分布式系统所有层。
“分布式系统设计器”支持两个域（开发和操作）的集成模型。这样，设计人员可以使用下面的方法解决客户问题：
| • | 提供公共语言（基于 SDM）来描述分布式系统的设计和配置。 |
| • | 允许开发人员表达应用程序对运行时环境的要求。 |
| • | 允许操作人员表达作为目标部署环境策略的应用程序运行时、安全性和连接要求。 |
| • | 使用抽象概念允许开发人员和操作人员在共同的基础上交流。 |
| • | 与现有 Visual Studio 项目系统和 .NET 技术集成。 |
| • | 提供可视设计元素与代码的完全同步。 |
| • | 纳入扩展性框架，允许建立新型应用程序和宿主系统的模型。 |
下面一节详细描述了“分布式系统设计器”工具集的各个设计器和编辑器。
“分布式系统设计器”概述
“分布式系统设计器”包括以下设计器：
| • | 应用程序连接设计器 |
| • | 逻辑数据中心设计器 |
| • | 系统设计器 |
| • | 部署设计器 |
应用程序连接设计器
应用程序连接设计器 (ACD) 可帮助开发人员或体系结构设计者定义和配置要纳入系统中进行部署的应用程序。工具箱提供了一组预定义的应用程序原型，包括 Web 服务、Web 应用程序、Windows 应用程序、外部数据库、外部 Web 服务和外部 BizTalk 服务。此外，工具箱还包括了通用应用程序原型，以便在设计中记录其他应用程序类型。
应用程序连接图表显示了在一个 Visual Studio 解决方案中定义的应用程序。可以从工具箱中添加每个应用程序来从头创建图表，也可以根据现有解决方案或现有项目通过反向工程来创建图表。
应用程序连接图表示例见图 1。
图 1：应用程序连接设计器
ACD 可同时显示“内部”和“外部”应用程序。内部应用程序是在解决方案内部定义的一个个可部署应用程序，将这些应用程序组织在一起可形成一个或多个可部署系统。通常，一个内部应用程序就是一个项目，它定义了一个可托管的可执行程序（例如，Web 应用程序或 Windows 应用程序）。资源既可以包括在该项目中，也可以位于其他引用项目或共享项目中，包括类库项目。外部应用程序允许开发人员对部署过程中要涉及的其他系统进行可视化引用。
每个应用程序都用一个框代表，较小的框代表连接点，说明应用程序是连接目标还是连接源。这些连接点也称作端点。应用程序所提供的服务由提供程序端点（实心形状）表示；与其他应用程序所提供服务的连接点由客户端点（空心形状）表示。各个应用程序都通过端点彼此连接在一起。
尽管 SDM 模型主要关注端点的类型、配置和连接，但各个应用程序可扩展该模型以表现服务所提供的行为的定义。例如，可以使用以下两种方法之一定义 Web 服务端点：单击 Web 服务提供程序端点，允许在“端点详细信息”窗口中定义该 Web 服务的操作；或者，导入现有 Web 服务描述语言 (.wsdl) 文件中的行为定义。如果按上述方法扩展模型，ACD 可支持完整的设计体验。例如，允许完全指定 Web 服务应用程序的行为和配置。
显示在 ACD 中的连接描述了开发环境中应用程序的当前配置。如果应用程序已经过调试，它将沿着显示的连接路径运行。
ACD 支持方法的延迟实现，它允许用户先创建和验证设计，然后再将设计付之代码。如果从工具箱中将应用程序定义添加到 ACD，相应的项目、代码和配置文件不会立即创建。代码的第一次生成也称作“实现”。应用程序定义可以增量实现，也可以一次性实现。在图表中，已实现的应用程序用阴影来区分。一旦应用程序得以实现，只要保持图表和代码文件打开，图表中显示的生成代码文件、配置文件和应用程序设计将始终保持同步。如果图表由于某种原因关闭，重新打开它将使其与代码同步，同时可用图表关闭期间的代码变化来更新它。这样，ACD 中的设计模型便可轻松地与代码变化保持同步，从而解决了其他工具无法解决的问题。如果应用程序是通过对现有项目或解决方案进行反向工程而创建的，系统认为应用程序已经实现，并自动执行同步。
通过对实现加以延迟，体系结构设计者和应用程序设计人员可以集中精力完成系统的功能设计和验证，同时延迟一些最好稍后由开发小组作出决策的实现。这些决策可能包括编程语言和模板的选择，或用于 Web 项目的服务器位置。
由于图表被保存为文件（.dsdgm 文件），故可将它包括在源代码控件中，并纳入小组的常规工作流。已实现应用程序的相关信息都保存在每个项目的 .sdm 文件中。因此，您可以在多个解决方案中复用项目，并将工作划分成不同的单元分配给小组中不同的开发人员。
ACD 可以访问应用程序配置设置的完整模型并定义宿主约束。宿主约束允许应用程序设计人员指定宿主环境的相关要求。通过在“设置和约束编辑器”中定义有关应用程序定义的宿主约束，应用程序开发人员可以请求在目标部署环境中启用一组必需功能，从而将重要的应用程序要求传达给操作人员。之后，操作人员可以确定是否要对逻辑数据中心进行更改以满足上述请求。作为部署验证的一部分，系统要根据逻辑数据中心的设置和约束来验证应用程序的设置和宿主约束（请参考“部署设计器”）。
逻辑数据中心设计器
逻辑数据中心设计器 (LDD) 用于创建代表数据中心逻辑结构的相互连接的逻辑服务器的图表。这些逻辑数据中心图表可将有关目标部署环境的重要信息传达给开发人员。借助该设计器，操作体系结构的设计者可以指定和配置数据中心的服务器类型、许可的通信类型、特定的通信路径以及启用的服务类型。
通常，逻辑数据中心图表由操作分析人员创建并拥有，但由开发人员使用。创建了逻辑数据中心图表后，操作分析人员可在整个应用程序开发生命周期中锁定该图表并管理图表版本，使其与数据中心的设计更改保持同步。与其他“分布式系统设计器”一样，逻辑数据中心设计器也与 Visual Studio 完全集成。但是，逻辑数据中心图表的创建独立于应用程序的开发过程。这些图表被保存为 .lsad 文件，可由部署于同一目标环境中的其他分布式系统复用。
下图显示了一个简单逻辑数据中心图表的构建过程。
图 2：逻辑数据中心设计器
在 LDD 中，工具箱包含预定义的逻辑服务器原型，它们可添加到图表中。逻辑服务器代表数据中心中的应用程序主机。本地类型包括 Windows 客户端服务器、Web 服务器（IIS 服务器）、SQL Server 和一般服务器。除一般服务器外，每个原型都定义了一组用于配置服务器的设置和适用约束。之所以包括一般服务器，只是考虑到记录。一般服务器允许在要建立模型的数据中心中存在其他类型的服务器。每个逻辑服务器都有两个端点，分别指定特定的通信协议。可以将端点添加到逻辑服务器中，以便通过该端点与其他逻辑服务器通信。
通过编辑所提供的设置，可以对数据中心内逻辑服务器的配置建立模型。除了编辑所提供的设置外，也可以从实际服务器中导入这些设置。一旦完成数据中心的描述工作，即可使用“设置和约束编辑器”指定与应用程序类型及配置有关的策略约束，这里的应用程序指可在该数据中心实现实例中托管的应用程序。这些约束都基于应用程序层中的设置创建，因为它们用于约束服务器可托管的应用程序类型，并指定应用程序所需的配置。例如，对于 Web 服务器托管的应用程序，可以约束 ASP.NET 安全设置；对于 Windows 客户端服务器托管的应用程序，则必须具备所需的 .NET Framework 版本。将某些设置标记为固定可指定这些设置不在开发期间改写。
“设置和约束编辑器”见图 3 所示。
图 3：设置和约束编辑器
工具箱还包含了若干区域和端点。区域代表数据中心的通信边界。区域端点代表区域与服务器之间的连接点。区域与服务器之间的通信路径由区域端点控制，可以配置区域端点来确定允许进出区域的通信协议类型。服务器端点用于指定服务器与跨区域发送（或接收）通信数据的服务器之间所允许的通信路径和协议。
作为部署验证的一部分，系统要根据应用程序中定义的设置和约束来验证逻辑数据中心图表中定义的配置设置和应用程序约束（请参考“部署设计器”）。这样，数据中心的策略和部署要求便可从操作小组传达到开发小组。
系统设计器
系统设计器用于根据 ACD 中定义的应用程序构建和配置系统。在“分布式系统设计器”中，系统是部署单位，而且是一个或多个应用程序及其他子系统的一项配置。由于系统可以从其他系统构建，因此定义大规模分布式系统方案可行。应用程序体系结构设计者可以设计复杂的多层系统，以此作为“嵌套”系统的层次结构。
在创建系统定义时，可以独立于 ACD 中显示的开发配置来定义部署配置。如果允许，系统图表的应用程序使用可改写 ACD 定义的应用程序的应用程序设置。可以创建多个系统定义，每个定义在解决方案中定义不同的应用程序配置。这样，不同的计划内部署（可能针对不同的数据中心配置、不同的地理部署或不同的客户）可以有不同的配置。
图 4 显示了包含嵌套系统的系统图表示例。
图 4：系统设计器
部署设计器
部署设计器用于将特定系统的部署定义到目标逻辑数据中心。通常，部署设计器由开发人员和体系结构设计者使用。在部署设计器中，系统中的应用程序绑定到目标数据中心中的逻辑服务器。该设计器所提供的功能突显了 SDM 模型的内在通信优势，SDM 模型是分布式系统设计器的基础。一旦完成部署的定义工作，即可根据需要验证它。验证可确认系统中的所有应用程序是否都绑定到逻辑服务器，并检查应用程序是否符合逻辑数据中心图表中指定的应用程序约束。此外，验证还可确认逻辑服务器是否符合在应用程序连接图表和系统图表中指定的宿主约束。
最后，验证可确保存在必需的通信路径，并确定是否存在正确的通信协议，以及这些协议是否在应用程序和主机服务器之间兼容。
图 5 显示了部署图表的示例。
图 5：部署设计器
所有验证错误都显示在 Visual Studio 错误列表中，该列表为更正和调整错误提供了一种简单的导航机制。双击错误列表中的错误时，部署设计器将打开相应的图表，选择相应的应用程序或逻辑服务器并导航到相应的设置可对其进行更正。这样，用户便可在部署之前（甚至在完全实现系统之前）更正配置错误。借助部署设计器，您可以生成所有必需应用程序和数据中心配置设置的报告，并将它用在自定义部署工具的脚本创建中。
扩展性
“分布式系统设计器”将包括一个扩展性模型，该模型允许合作伙伴扩展平台，以及添加对其他协议和其他种类应用程序和逻辑服务器的支持。
与 Visual Studio 2005 Team System 集成
“分布式系统设计器”提供了对分布式应用程序的设计和部署的支持。设计器通过以下几种方式与其他 Visual Studio 2005 Team System 工具集成：
| • | 使用“分布式系统设计器”设计、开发和测试的分布式系统开发项目都由 Visual Studio 2005 Portfolio Management Tools 管理。 |
| • | 应用程序使用 Visual Studio 2005 Team Test 进行单元测试。 |
| • | 源代码控件和集成工作项目跟踪使用 Visual Studio 2005 Team Foundation Server and Client。 |
结论
“分布式系统设计器”由一组设计器组成，这些设计器可简化基于面向服务体系结构的分布式系统的设计和验证过程。
| • | 面向服务的体系结构：根据预想，面向服务的体系结构将成为下一代分布式应用程序的基础。但使体系结构必要的片段可视化并加以设计却是一件非常困难的事。应用程序连接设计器 (ACD) 和系统设计器将帮助应用程序体系结构设计者、设计人员和开发人员从整体上可视化并设计面向服务的系统。 |
| • | 操作设计：“分布式系统设计器”可创建图表来代表系统的应用程序层和应用程序宿主层。由于组成应用程序的服务不断变化，第一次部署应用程序时（以及应用程序的整个生命周期中），借助这些图表可帮助设计和部署应用程序的人根据操作要求来验证应用程序的配置。 |
| • | 可执行设计：借助“分布式系统设计器”中的统一模型，应用程序和基础结构设计者可在设计过程中捕获大量的元数据。这种元数据既可用于生成代码，也可用于根据数据中心定义来验证应用程序的设计。该模型允许应用程序体系结构设计者创建更正式、更精确的设计。在应用程序的整个生命周期中，保持设计与代码同步仍然很关键，这有助于应用程序体系结构设计者根据需要维护和扩展应用程序。 |
“分布式系统设计器”可以帮助企业成功构建基于 Web 服务且面向服务的应用程序，并为数据中心的成功部署进行有效的准备工作。
有关 Visual Studio 2005 Team System 的其他成员的详细信息，请参阅：
| • | Visual Studio 2005 Team System:Overview |
| • | Visual Studio 2005 Team System:Building Robust and Reliable Software |
| • | Visual Studio 2005 Team System:Software Project Management |
| • | Visual Studio 2005 Team System:Enterprise-Class Source Control and Work Item Tracking |
| • | Visual Studio 2005 Team System:Microsoft Solutions Framework |
| • | Visual Studio 2005 Team System:Extending the Suite |
| • | Visual Studio 2005 Team System:Enabling Better Software Through Better Testing |