第4章 部署模式 Deployment Plan（部署规划）

已开发了基于组件的应用程序，该应用程序在逻辑上构造为多层结构，如 Three-Layered Services Application. 中所述。您希望将它分布到一组在物理上为多级结构的服务器上，如 Tiered Distribution 中所述。

图 1: 三层服务应用程序

影响因素

确定将组件部署到哪一级时，必须在实际环境的上下文中考虑下列影响因素：

• Layered Application 主要涉及对组件之间的设计依赖性进行管理，而"分级分布"则涉及对运行时服务器配置进行优化以满足系统级的运行要求。因此，将应用程序组织成多层结构所基 于的标准在根本上与优化物理组件部署所使用的标准是不同的。例如，将组件分配到不同的层的主要驱动力之一是尽量减少不同层中的组件之间的依赖性。相反，优 化组件部署的主要驱动因素是将组件的资源消耗配置文件与适当的服务器进行匹配。这意味着直接将层与级进行对应通常不是最优的分布策略。例如，开放系统互联 (OSI) 网络协议栈参考模型的构造为七层结构。没有人会要求甚至推荐在七台不同的服务器上分别驻留一层。
• 构造多层应用程序与构造硬件基础结构通常要分别由不同的两类人来完成的。这两类人通常具有不同的技能，而他们所共有的技能则会很少。例如，应用程序体系结构侧重于应用程序组件以及组件之间的关系，而系统体系结构侧重于服务器以及连接它们的网络。
• 部 署组件的硬件每增一级，复杂性、部署工作量和成本都将相应增加。将所有组件部署到同一级相对比较简单。随着级数的增加，确定应将哪些组件部署到哪一层也就 越发困难。同样，将所有组件部署到一个位置所需的工作量相对较少；而在添加更多的级后，必须在构建和部署过程后投入额外的工作量，以确定应将哪些组件部署 到哪一层。最后，每增加一级，都增加了组成该级的附加硬件的固定成本和重复成本。
• 组成应用程序的每个组件都消耗不 同数量的资源，如内存、处理器使用率、文件句柄、IO 套接字以及磁盘空间。根据这一影响因素，为各级分配组件有两种方法：专用级和通用级。专用级为驻留具有特定资源使用配置文件的组件而进行优化。由于专用级 中的服务器针对特定的配置文件进行优化，因此对于满足该配置文件的组件，每个服务器的驻留容量要远远大于按常规方法配置的服务器。因此，使用专用级通常会 导致较多的级数，但每级的服务器数较少。另一方面，通用级中的服务器是按常规方法配置的，因此部署决策主要考虑到下列因素：在给定的系统资源被完全耗尽之 前，每个服务器可以存放多少组件。使用通用级通常会导致较少的级数，但每级的服务器数较多。
• 不同的组件具有不同的 运行要求，如安全性、可用性和容错。例如，从 Web 与从外围网络（也称 DMZ、网络隔离和屏蔽子网）的公司一侧访问的组件具有不同的安全要求。前一影响因素的两种方法在此处也同样适用。可以增加专用级以驻留具有特定运行要求 的组件，或者配置通用级以满足所有运行要求。
• 安全要求通常驱使您增加级，并使每级驻留具有共同安全要求的组件。每增加一级，除了前面提到的增加复杂性、部署工作量和成本外，还会增加总体安全风险。每增加一级还会增加需要进行安全保护的新服务器和其他基础设施。
• 业务、政治和法律上的考虑可能要求将解决方案的特定组件驻留于特定的地理位置。例如，包含公司敏感信息的数据库可能需要驻留在安全的公司数据中心，而包含业务逻辑的应用程序服务器可能驻留在第三方驻留设备中。
• 组件调用所跨越的每个进程和服务器边界都会对响应时间造成不利的影响。跨越进程边界的组件调用比进程内调用的速度慢几倍，而跨越网络的组件调用的速度比同一进程内的组件调用慢一个数量级。

解决方案

应用程序体系结构设计者必须与系统体系结构设计者共同创建部署规划，以说明每个应用程序组件将部署到哪一级。沟通成功的关键是双方都从明确指定的一组高质量 要求开始，并向下细化到可测试级别。例如，"应用程序必须可伸缩"要求对于可测试性而言还不够具体。更具可测试性的要求可能为："应用程序在启动时必须支 持 50 个响应时间为两秒的并发用户，并且必须可扩展为支持 500 个响应时间为三秒的并发用户。"这一要求还应以系统和应用程序体系结构设计者都能理解的方式简练表述出来。除了从特定的要求开始外，双方还必须透彻了解将 对解决方案施加的技术、法律和业务约束。

基于这些要求和约束，应用程序设计者定义一组组件（在 Three-Layered Services Application 中指定），而系统设计者定义一组级（在"分级分布"中指定）。执行此映射的过程时，在双方之间的讨论中，由于每一方都知晓了另一方的观点而时常导致组件和级发生重大更改。

要展开此项沟通活动，应将前述影响因素作为指南，将 Three-Layered Services Application 中指定的组件角色映射为级。例如，用户界面组件可以映射为 Web 级，而业务组件几乎总是映射为应用程序级。

下 一步是考虑应用程序中的每个组件，并将它分配到某一级。在大多数情况下，通过确定组件在应用程序中所扮演的角色，然后将它分配给在上一步中为该角色确定的 相应级来将该组件分配给某一级。但是，有些组件不可避免地具有独特的运行或资源要求，从而导致其映射到交替的多级。虽然这些特殊情况是预料中的，但是如果 数量过多，您可能需要修改角色与级之间的初始映射关系。

将组件分配到级时，可能找不到与某个组件较好匹配的级。如果发生这种情况，那么两个团队必须协同工作，从修改组件以便更好地适合基础结构或修改基础结构以便更好地适合组件中进行选择，以确定其成本和优点。

基于 Three-Layered Services Application，目前已确定了几种常见的企业应用程序部署规划模型：简单 Web 应用程序、复杂 Web 应用程序、扩展企业应用程序以及智能客户端应用程序。

简单 Web 应用程序

简单 Web 应用程序配置将所有组件部署到一个通用级。此配置（如图 2 所示）从理解上是复杂程度最低且最简单的配置。

图 2: 简单 Web 应用程序部署

复杂 Web 应用程序

复杂 Web 应用程序配置（如图 3 所示）将表示组件和域组件进行分离，并将其部署到不同级（已专业化以处理其独特要求）。

图 3: 复杂 Web 应用程序部署

用 户界面组件 (UIC) 和用户界面进程组件 (UIP) 是对 Internet 公开的，并且可能潜在地与许多客户端交互。由于这些表示层组件通常公开于公司防火墙外部，因此其安全要求通常比未公开的组件具有多得多的限制。此外，许多 组织要求公开于 Internet 中的服务器不能包含任何敏感数据。因此，通过将表示层组件单独放入一级并配置该级使其具有最高安全性，可显著提高解决方案的总体安全性，同时可尽量降低对 安全性要求相对较低的组件的影响。

由于表示层组件公开于 Internet 中，因此其性能和可伸缩性要求通常不同于域和数据访问层组件的性能和可伸缩性要求。表示层组件通常为处理以突发方式与组件交互的许多并发用户而进行优化。 域和数据访问层组件通常为处理来自相对较少的源所发出的稳定请求流而进行优化。配置一个可充分支持这两组优化的级可能是非常困难的。因此，解决方案是使用 两级，并使每一层针对所驻留的组件类型进行优化。

扩展的企业应用程序

扩展的企业应用程序使用其他应用程序所提供的服务，并且还可能将功能作为服务公开，以供其他应用程序使用。图 4 显示此部署配置。

图 4: 扩展的企业应用程序部署

将服务网关 (SG) 和服务接口 (SI) 放入 Web 级的原因与将表示组件放入 Web 级的原因相同，后者已在本模式中的前面部分讨论。

智能客户端应用程序

智能客户端配置将用户界面组件部署到客户端级而不是 Web 级。之所以将表示组件移动到客户端级，主要动机是丰富的用户界面需要具有与用户进行高度交互的能力。主流 Web 技术不支持这些丰富的用户界面需求。图 5 显示具有其他级的智能客户端配置。

图 5: 智能客户端应用程序部署

注意 : 大型企业应用程序通常看起来好像由本模式中讨论的一个或多个模型组 成。例如，虽然扩展企业应用程序中的大多数业务组件都运行在应用程序服务器中，但是由于性能原因，可能有几个组件运行在 Web 场中，并且可能有一个或两个运行在浏览器中。

结果上下文

应用程序开发和系统基础结构团队之间的沟通，对于应用程序的成功部署至关重要。最终的部署规划具有下列优点：

• 将组件分配到级以满足两个团队的要求。
• 促进两个团队之间的通信，并详细订立两个团队同意遵守的合约。如果其中某个团队无法实现其承诺，那么两个团队必须聚集在一起并重新订立新的合约。

注意 : 除非公司文化认为应用程序和系统基础结构观点同等重要，否则应用 程序开发团队和系统基础结构团队之间的沟通将不会产生最优的部署规划。两个团队必须很灵活，并愿意达成妥协以使双方都能实现其要求。