1、章10章 完成计划阶段计划阶段包括了解决方案的体系结构和设计的大部分内容。通过该阶段，可以制定实现解决方案的开发和部署的计划，以及与任务和资源紧密相关的进度安排。这些计划可以帮助项目团队合理地安排后续阶段的工作。在本章中，你将学习项目团队为了完成项目计划阶段所要执行的任务和计划。学习完本章后，将能够： 创建计划和说明书，将设计中所考虑的内容与解决方案相结合 为项目的后续阶段创建计划和策略 为解决方案增添管理功能创建计划 为解决方案创建技术说明书10.1 整合设计的考虑事项在计划阶段，存在几个影响应用程序设计的因素。这些因素中有的是不可调整并受资源限制的，如：时间、资金、人力。而其他因素，如：可
2、采用的技术、知识、以及技能等，则是是动态的，且在整个的开发生命周期中不断变化。虽然这些因素会在某种程度上影响应用程序的设计，但业务问题规定了应用程序为满足解决方案所必须具有的能力。在本课中，将学习解决方案所具有的能力及其应考虑的事项。还将学习设计中须考虑的因素如：可扩展性、可用性、可靠性、性能、互操作性、全球化和本地化等。同时，还要学习将上述考虑因素整合到解决方案中所用到的技术。学习完本课后，将能够 ： 为可扩展性设计解决方案 为可用性设计解决方案 为可靠性设计解决方案 为性能设计解决方案 为互操作性设计解决方案 为解决方案设计本地化和全球化的说明书10.1.1 可扩展性的设计方法第 10 章
3、 完成计划阶段294图 10-1 可扩展性的设计方法图 10-2 可扩展性的设计方法可扩展性定义为增加资源以提高服务容量的能力。在一个可扩展的应用程序中，可以通过添加资源来管理额外的需求而不用调整应用程序本身。一个可扩展的应用程序要求在实现应用程序的硬件和软件之间维持一种平衡。应该为软件或硬件添加资源以增强应用程序的可扩展性。添加这些资源可能会带来好处，但也可能会第 10 章 完成计划阶段 295没有效果甚至产生负作用，表现为资源的添加并没有显著地提高服务容量。例如，如果你所编写的应用程序是用来实现同步方法调用的，或是用检索大型数据集的方式来响应用户请求的，那么在此应用程序中通过实现负载平衡所
4、带来的效果将微乎其微。 章1章 常用方法提高可扩展性有两种最常用的方法： 纵向扩展（Scaling up）。这种方法通过改善现有服务器的处理硬件来实现可扩展性。纵向扩展包括：增加更多的内存、更多或更快的处理器、或将应用程序移植到功能更强大的计算机上。将 该方法运用于 应用程序的最主要的目的是：增加 应用程序可用的硬件资源。特别是，可以扩展应用程序而无需改动源代码。而且，管理的 难易程度也不会明显变更。但是，在达到 计算机实际处理能力的最大值以后，纵向扩展所带来的好处会逐渐减小 横向扩展（Scaling out ）是指将处理负载分配给多台服务器。尽管是通过多台计算机来实现横向扩展，但最 终用户
5、在使用时却感觉不出与以前的机器配置的区 别。再次声明，软件与硬件之间的平衡是很重要的。应用程序在服务器上运行，但却不需要知道该服务器的信息。这也就是所 谓的位置透明（location transparency）。横向扩展同时也提高了应用程序的容错能力章2章 可扩展性的设计良好的设计是高可扩展性应用程序的基础。计划阶段对于应用程序的可扩展性至关重要。上面的图示说明了设计、代码调整、产品调整、以及硬件调整在应用程序可扩展性中所起的作用。设计对应用程序可扩展性的影响要大于其他三种因素的影响。越到金字塔的上层，各种因素的影响就会越小。金字塔说明了采用有效设计与增加硬件资源相比，可以更好地提高应用程序的
6、可扩展性。可扩展性的设计应遵循下列指导方针： 合理设计进程使其不需要等待。除非必要，否 则进程的等待 时间不应太长 。进程可分为同步进程和异步进程。同步进程必须等待另一个进程完成后才能 继续运行。 这类进程必须等待另一个进程完全成功或失败后才能执行其他操作。 对于以同步进程方式运行的应用程序而言，将会遇到资源瓶颈。 这些瓶颈不仅影响应用程序的性能还会影响其可扩展性。因此 实现可扩 展性的一个方式就是采用异步 进程。在采用了异步 进程的应用程序中，需要长时间运行的操作可以被安排在以后由一个 单独的进程来完成 有效地管理会话状态。Microsoft ASP.NET 极大地增强了会话状态的管理。因为
7、可以选择将会话状态存储在本地（这只在 ASP 中可选用）、或存 储在远程状态服务器上、或存储在运行 Microsoft SQL Server的计算机上，所以你的应用程序可以很容易的横向扩展到多台服务器上第 10 章 完成计划阶段296 合理设计进程，以避免进程争夺资源。 导致可扩展性出 问题的最大原因之一就在于对内存、处理器周期、带宽、或数据 库连接等资源的竞争。合理 计划你的资源使用从而尽可能的减少这类问题 资源使用顺序应该是占用资源数量最多的先使用，占用最少的后使用 使用 Microsoft ADO.NET 离线体系结构的功能最大化数据库连接资源的可用性 尽可能迟地获取资源，尽可能早地 释
8、放资源。一个 进程使用 资源的时间越短，则其他进程获取该资源的时间越早。 虽然 Microsoft .NET Framework 的垃圾搜集功能显著提高了资源释放的能力，但我 们仍应该将进程密集（ process-intensive）资源，比如数据库连接，设计成使用后可马上释放的形式 尽管你仍然可以单独使用组件，但 .NET 程序集（可以被分组和部署的一个或多个文件）还提供了两种方法来提高资源的使用：1. 可以在多客户端应用程序可利用的几个文件中描述资源。2. 由于.NET Framework 支持并行（side-by-side ）执行，因此一个程序集的多个版本可以共存在同一台计算机上 合理设
9、计进程以实现可互换性。如果两个或更多的操作能够以任意的顺序执行并仍能够得到相同的结果， 则称这 些操作是可互换的。一般的，不参与事 务处理的操作都是可互换的。比如，一个繁忙的 电子商务站点在不断更新其产品的详细目录时，可能会遇到争夺记录锁定的问题。为了防止这种争夺，每次目录的增减都应记录在一个单独的目录事务处理表中。数据库会周期性向这个表中添加每个 产品的相关纪录，然后在目录中根据净变值（net change）更新产品纪录注意：ADO.NET 的体系结构是建立在脱机并且基于消息的数据访问基础之上的。数据能够以可扩展标记语言 XML（XML : Extensible Markup Languag
10、e）文档形式进行传送和保存，因此那些可以解析 XML 的应用程序也就可以访问这 些数据。因此，所有的 应用程序将不再需要保留数据连接。 为可交换性设计应用程序元素。可交互的组件被设计成可以释放其资源，将资源放入由资源管理器管理的池中，并在新的客户端要使用时重新初始化 该资源。然而，最好是使用 XML Web 服务。可以使 应用程序的一部分跨 进程使用，并且为了更好地提高可扩展性，也可以跨计算机使用。合理设计组件使得在客户端之间不会保留一种特定客户端状态。另外，你 设计的 组件应该支持聚合且不会被绑定到特定线程上。有效地使用会话状态管理并尽可能地使用 ADO.NET 脱机数据对象。 分隔资源和活
11、动。通过分隔活动与资源可以尽可能减少它们之间的关系。这将有助于避免瓶颈风险。分隔行 为还有助于减 轻如处理器、带宽等关键资源的负载。比如，使用安全套接层（SSL， Secure Sockets Layer）可以提供安全的 连接，但是会明 显地增加开销。因此只有对那些安全层 次要求很高的网页才应该决定使用 SSL 并使用专用的Web 服务器来处理 SSL 会话10.1.2 可用性设计方法第 10 章 完成计划阶段 297虽然所有的应用程序都至少在某些时候可用，但对基于 Web 应用程序和执行关键任务的企业级应用程序而言，必须要求这些程序在所有时间都能够提供服务。如果你的企业级应用程序要求一天 2
12、4 小时，一周 7 天地运行，你需要设计一个高可用性的应用程序。软硬件性能的提高可以增加高可用性应用程序的质量。章1章 可用性定义与计划运行时间相比，可用性是一种测量标准，用来衡量处理服务请求时，应用程序的可用频率。同时，可用性还考虑了应用程序由于修复而不能使用所带来的修复时间。注意：可用性不解决业务延续性问题 ，如 备份和可选站点。章2章 可用性计算表 10-1 说明了用于计算可用性的度量单位表 10-1名 称 计 算 定 义平均无故障工作时间（MTBF ）小时/故障数 应用程序在发生故障前运行的平均时间长度平均修复时间（MTTR） 修复时间/故障数 应用程序在发生故障后进行修复和恢复服务的
13、平均时间长度可用性的计算公式如下：可用性= (MTBF / (MTBF + MTTR) 100例如，Adventure Works Cycles 应用程序的可用性要求是网站必须一天 24 小时，一周 7天都可用。如果你假设连续 1000 小时为一个检测点，而在此期间出现了两个持续一小时的故障，则其可用性为：(1000 / 2) / (1000 / 2) + 1) 100 = (500 / 501) 100 = .998 100 = 99.8%描述可用性的一种比较流行的方式是以“9”表示，如 3 个 9 说明 99.9的可用性。然而这种测量方式经常会使人产生误解。需要进行数学运算才会发现 3 个
14、 9（99.9%）表示在一年中，服务中断会达到 8.5 个小时。更进一步，4 个 9（99.99%）表示在一年中服务中断会到达1 个小时，而 5 个 9（99.999% ）则表示每年的服务中断有五分钟。 第 10 章 完成计划阶段298章3章 计划可用性级别为了确定适合于应用程序的可用性级别，你必须回答一些问题，包括： 应用程序的客户是谁？他们对该应用程序的期望是什么 多长的停机时间是可接受的 内部公司的进程是否依赖于该服务 应用程序开发的进度和预算是什么章4章 用于可用性的技术可用性设计包括：在软硬件故障导致服务错误、故障、或数据破坏之前，对这些故障进行预期、检测，并将其解决，从而最小化停机
15、时间。为了确保可用性，应该为应用程序服务和数据提供多个通道。应该只能使用那些已经过测试并证明有效的进程（不论是自动化的还是基于人工的），这些进程在应用程序生命周期中起支持作用。除了无法预知的停机时间之外，计划内的停机时间也必须降低。计划内的停机时间可以包括：维护变更、操作系统升级、备份、或其他一些需要临时将应用程序从服务中移除的活动。应用程序的可用性还依赖于它的可靠性。要想设计一个高可用性和高可靠性的应用程序，需要有一个可靠的基础，包括：良好的应用程序设计、严格的测试、以及严谨的论证。一些用于可用性设计的技术，包括： 减少计划内的停机时间。 为了避免停机时间，可使用滚动升级（rolling u
16、pgrade）。比如，为了更新一个群集服务器上的某个组件，可以将该服务器的 资源组移到另一台服务器，然后将该服务器离线，更新组件，更新完成后再使服务器上线。而在此期间，其他服务器会处理工作负载，从而实现应用程序无停机时间。你可以在横向扩展应用程序中使用这种策略 通过使用群集减少非计划的停机时间。群集是一种用以创建高可用性应用程序的技术。一个群集包含有多台计算机，这些计算机在物理上连成网络，并通过群集软件在逻辑上相互连通。通 过使用群集化，一个多服务器 Web 站点可以在不中断服务的前提下经受住故障。当主动服务 器失效时，工作负载会自动移到被动服务器上，当前的客户进程也会转到这些服务器，同时失效
17、的应用服务会自 动重新启动。如果是 资源发生失效，那么客户在连接到这 些服务器群集时可能会感觉 到一些延时，但服 务仍将会完成。群集软件可以为专门设计为 有群集支持并被分配到群集中的 应用程序、文件和打印服务、数据 库、以及消息系统提供故障转移支持。 使用网络负载平衡。网络负载平衡(NLB ，Network load balancing)用来将通信量平均分配给所有可用的服务器。 NLB 也有助于提高应用程序的可用性：如果一个服 务器失效，你可使用 NLB 重定义群集，并将通信量引导给其他服务器。NLB 特别适合于某第 10 章 完成计划阶段 299些电子商务应用程序，这些应 用程序通过使用事务
18、将外部客 户端与数据服务器相连。当客户通信量增加时，可以通 过在一个单独的群集中将服 务器增加到 32 台以横向扩展 Web 服务器场（Web server farm）。NLB 可自动侦测 服务器故障并将客户通信量重新引导到其他的服务器上，从而在所有 时段都能保持持 续的、不 间断的客户端服务 使用独立磁盘冗余阵列（RAID）存储数据。 RAID 使用多个硬盘将数据存储在多个地方。如果一个磁盘失效，应用程序将会转移到数据镜像上并继续运行。你可以替换失效的硬盘而无需停止应用程序 隔离执行关键任务的应用程序。应用程序会稳定地执行任务并请求如网络通信、数据访问、或处理线程等资源。每一个对这些资源的请
19、求都会影响共享相同资源的应用程序的性能和可用性。如果应用程序在相同的服 务器上共享 这些服务， 则这些服务器的工作负载和吞吐量特征可能会发生不利的改变。因此建议执 行关键任务的应用程序使用专用设施和专有网络 使用队列。队列可以使应用程序通过发送和接收异步消息与其他应用程序通信。队列保证消息的发送，而不管当前是否存在必要的连接（比如，移动应用程序）。队列可以将应用程序的故障点移除。同 时， 队列还是对硬件需求很大的高峰工作负载进行管理的解决方案。另外，通过增加成功消息 传送的通道， 应 用程序也能增加成功消息和即时消息完成的机会10.1.3 可靠性设计的方法应用程序的可靠性是指其提供精确结果的能
20、力。可靠性和可用性紧密相关。可靠性衡量应用程序无差错运行并产生预期结果的时间长短，而可用性则用来衡量处理所有请求的能力，以及以在对访问应用程序产生最小损失的情况下从失效中恢复的能力。用户会绕过不可靠的Web 站点，这会导致收入损失并减少以后的销售额。而且，对损坏数据的修复也会增加应用程序的故障成本。因为故障点一般会隐藏在整个应用程序之中，所以不可靠的应用程序也难以维护或改进。章1章 应用程序失效的原因应用程序是硬件、操作系统服务、软件组件，以及人工处理的集合，它们共同提供了预先指定的业务服务。整个应用程序的可靠性依赖于各个组件的可靠性。因为应用程序中所有的组件都是相互关联的，因此某一个组件的故
21、障可能会影响到其他组件的可靠性。应用程序的故障可能有很多原因，包括： 错误的代码 不充分的测试 变更管理问题 操作错误 缺少实时的监测和分析第 10 章 完成计划阶段300 缺少软件工程质量处理 与外界服务和应用程序的交互 改变运行条件，如使用层次或工作负载变更 特殊事件，比如安全故障和广播 风暴 硬件故障（磁盘、控制器、网络设备、服务器、电源、内存、及 CPU） 环境问题（能源故障、冷却、火灾、洪水、灰尘、以及自然灾害）章2章 可靠性设计为了设计可靠性，需要分析应用程序所期望的使用模式，创建可靠性纲要，并创建适合于该纲要的解决方案。必须分析如何提供特殊的服务、评估故障场景、并设计备用方案。另
22、外，还必须考虑应用程序与其他应用程序的交互。对从未开发过的应用程序来说，确定其可靠性问题和解决方案是很困难的。然而，你可以先分析目前在组织机构中正在运行的应用程序。该分析可以发现故障的频率和分布、产生的根本原因、以及对现有应用程序可能的改进。可以使用这一信息来设计一个可靠的解决方案。可靠的解决方案确保无错数据输入、数据转换、状态管理，以及无中断地从任何故障状态下恢复。创建高可靠性的应用程序依赖于整个软件开发生命周期，从计划阶段到开发、测试、部署、和稳定阶段。下列的任务有助于创建一个可靠的应用程序。 将可靠性需求写入说明书 使用好的基础设施体系结构型 将管理信息包含在应用程序中 使用冗余 使用质
23、量开发工具 使用应用程序提供的可靠性检查 实现错误处理 实现适度降级（适度降级是指为你的应用程序添加功能的过程，所添加的功能可以实现你的应用程序与早期技术兼容通常是指浏览器。）10.1.4 性能设计的方法应用程序性能是由诸如事务处理能力和资源使用等标准来定义的。一个用户可能会按照应用程序的响应时间来定义应用程序的性能。章1章 性能目标和度量标准在设计性能之前，需要确定应用程序的性能目标和衡量性能的度量标准。为了确定性能目标，需要回答如下问题：第 10 章 完成计划阶段 301 业务目标是什么？例如，如果解决方案的业务目标是每周处理更多的订单，则你可能首先要预先确定一个收入增长的数量，并将该预期
24、数字转换为 每个功能区域的性能目标 解决方案的关键功能是什么？确定关键功能可以让你按优先级划分解决方案的设计。你应该降低低优先级功能的性能，以维持或提高较高优先 级功能的性能 不同种类用户，或者不同用户组的功能需求是什么？你可以按照组织机构和解决方案最终用户的不同期望来创建纲要。因为存在不同的期望，所以应用程序性能需求也不尽相同。需要确定每个功能区域和性能目标的关系。例如，数据 库储存客户所下订单的所有信息。从客户的角度来 说， 应用程序应该能迅速的更新数据库。组织希望解决方案能迅速存储地有效的数据。因此，解决方案的性能目标就是确保对数据库进行快速的插入和更新。创建纲要有助于 为解决方案划分和
25、开 发精确的测试注意：出于测试的目的，必须以一种在 测试方法中可测试的方式来表达性能目 标。需要确定 应用程序的性能测量标准。例如，快速插入和更新数据库的性能目标可以根据每秒事务量来衡量。章2章 性能设计必须在项目组进入开发阶段之前定义性能需求。为了定义一个好的性能需求，必须确定项目约束，决定应用程序将要执行的服务，并指定应用程序的负载。 确定约束。项目约束包括预算、日程、基础设施、开发工具或技术的选择。例如，你可能需要按照特定的日期部署应用程序。也许需要使用特定的开 发工具，因 为团队可能只精通这种开发工具。不 应该设计 和开发处理器密集的应 用程序，因 为客户端计算机没有足够的硬件资源。需
26、要在约束范围之内设计符合性能目 标的应用程序。可以 调整项目中不受约束的部分以决定如何才能提高性能，而不是去改 变项目的某些部分来提高性能。例如，团队能否通 过培训从而可以使用其他的工具来创建组件？能否通过改变数据访问的技术来改进数据访问 确定功能。 应用程序的功能应与其用例和使用场景相符合。可以确定那些会影响应用程序性能的使用场景，同 时对 每一个场景，指定用户的行为和应用程序的响应，包括对数据库和其他系统服务的访问。另外，需要确定每个功能使用的频率。这些信息有助于创建衡量性能的测试，该性能与实际中所使用的应 用程序的性能要尽可能相似 指定负载。可以根据将要使用应用程序的客户端的数量来确定该
27、应用程序的负载。另外，可以分析整个运行时期负载 的变化。例如，在一年的某些特定 时期一个电子商务站点的请求数量将会很大。可以使用负载作为衡量应用程序性能的度量 标准10.1.5 互操作性的设计方法第 10 章 完成计划阶段302互操作性是指应用程序能在不同的计算环境中成功运行的能力。将这种能力加入到解决方案中的设计可能会增加设计的成本和工作量，但这些成本会从以下的益处中得到补偿： 减少操作的成本和复杂性。在可预见的未来，客 户可能 继续在混合环境中工作。不同应用程序在相同环境中共同运行的能力可以减少开发和支持异构基础设施的成本 更易于部署。客户可能具有利用特定应用程序和平台进行交付的业务需求。
28、可互操作的应用程序使组织机构可以继续使用不同的应用程序解决其特定需求 更好的投资收益。一般来说，客 户会将很多不同的应 用程序安装在他们的工作环境中，并逐步将它们移植到新的工作平台。因此，新的应用程序必须能和以前的应用程序进行交互。另外，现有的应用程序 应该是具有 Web 导向（Web-aware）的，并可以从公司内部网或 Internet 访问如 IBM 大型机等环境所承载的应用程序。这种能力扩展了现有应用程序的功能并保护了组织机构所作的投资章1章 互操作性设计为了集成不同的应用程序，需要考虑以下几种互操作性的类型： 网络互操作性。是指多个供应商系统可以互相进行通信而不必使用公共协议的能力。
29、以前的应用程序是在一些已预先定义的协议基础上进行设计的，这些协议包括：TCP/IP、IPX/SPX、或 SNA。诸如 HTTP、XML、SOAP、WSDL，以及使用 Internet 的Web 服务等技 术和标准的实现，使得你的应用程序可以独立于编程语言、平台、以及设备 数据互操作性。是指应用程序访问和使用存储在结构化或非结构化存储系统中数据的能力，如数据库、文件系统、以及 电子邮件储存等存储系统。企业级应用程序常常要求在不同数据源和多个应用程序之间共享数据。已发布的数据交 换标准，如 级连样式表单（cascading style sheet）、ODBC、和 XML，可以对 Microsoft
30、 基于 Windows 的数据源和不基于 Windows 的数据源都能进行数据访问 应用程序互操作性。指的是用来确保新的 n 层（n-tier）应用程序和现有应用程序、业务逻辑、以及数据之间互操作性的基 础设施。当你在创建 n-tier 应用程序时，它 们将需要和广泛的现有应用程序共同工作。使应用程序具有互操作性的一种方法是使用公共语言规范（CLS， Common Language Specification）。CLS 是一种标准，它现在已适用于二十多种不同的语言，所有遵循该标准的语言都可以创 建服务的互操作性通过在 Microsoft .NET-connected 应用程序中实现互操作性，你可以访问和使用那些传统的，还没有准备移植到.NET-connected 解决方案中活动服务器页面（ASP， Active Server Pages）和组件对象模型（COM，Component Object Model）应用程 序。另外，XML 的创建使应用程序更易于交 换数据且不再需要为数据交换的每个类型和实例创建转换代码 管理互操作性。是指用户账户管理、性能 监控、以及在组织机构中调整不同应用程序
