第 3 章技术要求

技术要求分析以业务分析阶段所创建的业务要求文档为起点。需要以这些业务要求为基础，执行下列步骤：

使用案例还是设计阶段进行逻辑体系结构 设计的基础。逻辑体系机构和系统要求一起组成了部署方案，以后作为部署设计阶段的信息来源。

下图显示的是技术要求阶段与业务分析、逻辑设计及部署设计各阶段的相互关系。

与业务分析阶段一样，技术要求分析阶段也不存在可生成用量分析、使用案例和系统要求的魔方。进行技术要求分析要求对业务领域、业务目标及基础系统技术有了解。

用量分析

用量分析的任务是标识要设计的部署的各个用户及确定这些用户的使用模式。可通过收集到的用量分析信息对预期的负载情况有一个大致了解，随后将使用这些信息来确定性能要求和其他系统要求。在给使用案例指定加权时，用量分析信息同样有用，如使用案例中所述。

用量分析阶段的任务是：尽可能与用户面谈，对与使用模式有关的现有数据进行研究及与先前系统的制造者和管理员会谈。下表列出了进行用量分析时应考虑的主题。

表3-1 用量分析主题
主题	说明
用户数量及类型	确定部署必须支持的用户数量，并在必要时对用户进行分类。例如： “企业对客户”部署可能会有大量存取者，但可能只有少数用户会进行注册并参与商业交易。 “企业对员工”部署通常必须可以为每位员工提供服务，但有些员工可能需要从公司网外部进行存取。在“企业对员工”部署中，经理可能需要获得对某些区域的存取权限，而这种权限是不应提供给普通员工的。
活动和非活动用户	确定活动和非活动用户的使用模式和使用比率。活动用户是指登录系统并与系统组件进行交互的用户。非活动用户是指不登录的用户，或虽然登录但不与系统组件进行交互的用户。
管理用户	确定对部署系统进行存取，以对部署进行监控、更新和支持的用户。确定可能会对系统要求产生影响的任何特定管理使用模式，例如，从防火墙外对部署进行管理。
使用模式	确定各类用户如何存取系统，并提供预期用量目标。例如：是否存在因用量高而产生的高峰期？正常营业时间是什么？用户是否遍布全球？预计的用户连接持续时间是多少？
用户增长	确定用户群体规模是否固定，或部署是否预期有用户数量增长。如果预期用户群体会有增长，请尽量作出合理的增长预测。
用户事务	确定必须支持的用户事务类型。可将这些用户事务转化为使用案例。例如：用户将执行哪些任务？用户登录后是保持登录状态，还是通常会执行若干任务，然后注销？用户间是否会进行一些重要协作，而这种协作需要利用共用日历、召开 web 会议及部署内部 web 页才能实现？
用户研究和统计数据	利用现有用户研究和其他资源来确定用户行为模式。企业或行业组织往往都会进行一些用户研究，可以从中汲取有用的用户信息。现有应用程序的日志文件中可能会包含一些统计数据，这些数据在做系统估量时会用到。

使用案例

使用案例模拟典型的用户与要设计的部署间的交互，以最终用户的视角说明操作的完整流程。在设计中对整个一组使用案例给予优先考虑可确保设计不偏离提供预期功能这一中心。

每个使用案例均可包括用户行为的定量估计，随后可利用该估计结果来确定系统对性能、可用性及其他服务质量的要求。使用案例还是逻辑体系结构设计的起点，如第 4 章, “设计逻辑体系结构”中所述。

为使用案例指定相对加权，加权最高的使用案例代表最常见的用户任务，这是一种常见的做法。对使用案例加权有助于确定系统要求。

系统要求

系统要求说明的是，部署系统为满足通过业务分析而得出的业务要求而必须提供的服务质量。通常使用用量分析和使用案例，并结合业务要求来得出系统要求。

表3-2 影响部署设计的系统特性
系统特性	说明
可用性	一种对系统资源和服务可供最终用户使用比率的衡量指标，通常以系统的正常运行时间来表示。
潜在容量	在不增加资源的情况下，系统处理异常峰值负载用量的能力。
性能	对用户负载情况响应时间和等待时间的衡量指标。
可伸缩性	随时间推移为部署系统增加容量（和用户）的能力。可伸缩性通常涉及向系统添加资源，但不应要求对部署体系结构进行更改。
安全性	对系统及其用户的完整性进行说明的复杂因素组合。安全性包括用户的认证和授权以及信息的安全传输。
可维护性	对部署系统进行管理的容易度，其中包括监视系统、修复出现的故障及升级硬件和软件组件等任务。

影响部署设计的各系统特性间关联紧密。对一个系统特性的要求可能会影响到对其他系统特性的要求和设计。例如，提高安全性级别可能会影响到性能，而性能又会影响到可用性。增加服务器来解决可用性问题可能会影响到维护成本（可维护性）。

能否设计出既可满足业务要求，又能兼顾业务约束的系统的关键在于，了解各系统特性间的关联方式及必须作出的权衡。

以下各节将对影响部署设计的各种系统特性做更深入的探讨，并就确定系统要求时应考虑的因素提供相关指导。其中有一节专门探讨服务级别要求，它是一组用于创建服务级别协议的特殊系统要求。

可用性

可用性是定义部署系统正常运行时间 的一种方法，通常以系统可供用户存取的时间占总时间的百分比来表示。系统不可存取时间（停机时间）可能是因硬件、软件、网络故障或任何其他因素（如断电）所致，这些因素会使系统停机。在大多数情况下，不将计划的服务（维护和升级）时间视为停机时间。

通常以“九”的个数来衡量可达到的可用性。例如，99% 的可用性为两个九。指定更多的九会对部署的可用性设计产生很大影响。下表显示的是为某系统增加代表可用性的九后的结果，该系统以 24x7 方式全年不间断运行，运行时间共计 8,760 小时。

表3-3 全年运行（8,760 小时）系统的停机时间
九	可用性百分比	停机时间
两个	99%	88 小时
三个	99.9%	9 小时
四个	99.99%	45 分钟
五个	99.999%	5 分钟

容错系统

对可用性的要求达四个或五个九通常要求必须系统是一个容错系统。容错系统必须能够在硬件或软件出现故障时继续运行。通常，容错的实现手段是为提供关键服务的硬件（如 CPU、内存和网络设备）及软件配置冗余组件。

单一故障点 是指没有备用的冗余组件的硬件或软件组件。该组件出现故障会使系统无法继续提供服务。设计容错系统时，必须确定潜在的单一故障点并将其消除。

容错系统的实现和维护成本高昂，请确保先了解业务可用性要求的本质，然后再考虑能够满足这些要求的可用性解决方案的策略和成本。

Sun Cluster 3.1 4/04

Sun Cluster 3.1 4/04 软件可为要求具备高可用性容错系统的部署提供高可用性解决方案。Sun Cluster 3.1 4/04 将服务器、存储器及其他网络资源相结合，使系统用户能够快速完成故障转移，而几乎不用中断服务。

排定各类服务的可用性优先级

在用户看来，可用性更多牵涉到的往往是部署系统所提供的每项服务，而非整个系统的可用性。例如，如果即时消息传送服务不可用，通常情况下对其他服务的可用性几乎没有影响或无任何影响。不过，许多其他服务（如 Directory Server）所依存的服务的可用性则对系统有较大影响。

根据一组有序的优先级列出可用性需求会有帮助。下表按优先级顺序列出了不同服务类型的可用性。

表3-4 排定各类服务的可用性优先级
优先级	服务类型	说明
1	策略	运行所不可或缺的服务。例如，许多服务依存于 Directory Server。
2	关键任务	峰值负载时必须可用的服务。例如，被定义为关键任务的应用程序数据库服务。
3	必须可用	必须可用，但可以较低性能获得的服务。例如，在某些业务环境中，Messaging Server 可用性可能并不关键。
4	可延迟	在特定时间段内必须可用的服务。例如，在某些业务环境中，Instant Messaging 可用性可能并非不可或缺。
5	可选	可无限期延迟的服务。

有关用于实现可用性要求的各种设计策略的信息，请参阅可用性估量。

潜在容量

潜在容量是指在不增加资源的情况下，部署处理异常峰值负载用量的能力。通常不直接围绕潜在容量定义系统要求，但该系统特性是确定可用性、性能和可伸缩性要求的一个因素。

性能

确定性能要求是将业务要求的性能预期转化为系统要求的过程。业务要求通常以指定响应时间的非技术性术语来表示性能。例如，基于 web 存取的业务要求可能会做以下说明：

从该业务要求入手，对所有使用案例进行研究，以确定在系统级体现该要求的方式。请将用量分析阶段所确定的用户负载情况考虑在内。以术语指定负载情况下的响应时间 或响应时间加吞吐量 来表示每个使用案例的性能要求。可能还要指定容错数。

性能要求与可用性要求（故障转移对性能的影响）及潜在容量（可用于处理异常峰值负载的容量）关系密切。

可伸缩性

可伸缩性说明的是随时间推移为系统增加容量和用户的能力。可伸缩性通常要求增加资源，但不应要求对部署体系结构的设计进行更改，或因增加额外资源需要时间而中断服务。

与可用性一样，可伸缩性更多牵涉到的是系统所提供的各项服务，而非整个系统。不过，对于其他服务所依存的服务（如 Directory Server），可伸缩性的影响可能会波及整个系统。

不必在系统要求中指定可伸缩性要求，除非业务要求中对预测的部署增长做了明确说明。在部署设计阶段，即使不指定可伸缩性要求，部署体系结构也应将系统扩展考虑在内。

确定可伸缩性要求并不是一门精确的科学，进行系统增长估计是做一些可能无法达成的预测、估计和推测。以下是构建可伸缩系统的三个关键点。

表3-5 可伸缩性方面应予考虑的一些因素
主题	说明
用量分析	通过研究现有数据了解当前（或预测）用户群体的使用模式。如果缺少现时数据，可对行业数据或市场估计进行分析。
以合理的最大标度为目标进行设计	设计时以能够满足已知和潜在需求的最大必需标度为目标。这往往是根据现有用户负载的性能评估和对未来负载的合理预期而作出的 24 个月估计。估计周期的长短在很大程度上取决于预测的可靠性。
设置合适的重大事件点	以渐增方式实现部署设计来满足短期要求，同时设立缓冲区来应对意外增长。设置增加系统资源的重大事件点。例如：资本获得如每季度或每年硬件研制周期例如，一到六个星期缓冲区（10% 到 100%，具体取决于增长预期）
融入新兴技术	了解新兴技术（如速度更快的 CPU 和 Web 服务器），及该技术会对基础体系结构的性能产生怎样的影响。

安全性要求

安全性是指会对系统及其用户的完整性（包括用户事务及相关数据的完整性）产生影响的系统特性。与其他系统要求一样，业务要求、用量分析和使用案例会推动针对安全性要求的分析。

进行验证、授权、身份认证管理及在整个企业范围内贯彻可靠安全性惯例实施策略，可保障事务安全及确保存储在站点的数据不受损害。

验证

验证是指用户如何向系统表明身份及系统如何向用户表明自身身份。验证是系统完整性的一个关键节，它能够防止系统受到未授权存取。

应了解用户要求，以为部署选择最佳验证方案。例如，“企业对客户”部署可允许用户使用用户名/ 口令组合进行注册，这些用户凭借信任的证书授权机构（如 VeriSign）所颁发的服务器证书，通过安全传输来验证销售系统。

而“企业对员工”部署可从现有用户群体中置备员工。在公司防火墙内，允许对已知安全位置进行存取。在防火墙以外，对安全位置的存取则通过代理来实现，代理会在公司防火墙内执行验证和重定向操作。

授权

授权是对已验证用户拥有特定权限的认可。例如，拥有管理员授权的用户可以存取普通用户无法存取的部署系统的某些节。

授权在实现单点登录 (SSO) 的部署中也发挥着作用。某部署的已验证用户只需登录一次，便可使用多项服务。

身份认证管理


注	在系统要求分析阶段，通常对影响基础结构（例如，防火墙软件和网络设计）完整性的安全性要求不予考虑。但这些安全性问题会在部署设计阶段产生影响。

部署系统必须提供一种途径来添加、修改或删除存取系统服务的用户。身份认证管理可由授权管理员执行或由用户自己借助委派管理 接口来完成，具体采用何种方式取决于实际需要。大中型企业部署应考虑采用委派管理设计。采用委派管理可提高客户满意度及降低系统管理成本。

可维护性要求

可维护性是指对部署系统进行管理的容易度，其中包括监视系统、修复出现的故障及升级硬件和软件组件等任务。

表3-6 可维护性要求主题
主题	说明
停机时间计划	确定必须使特定服务完全或部分不可用的维护任务。某些维护和升级任务可在用户不知不觉中完成，而要执行其他类似任务则必须中断服务。尽可能与用户一起为要求停机的维护活动制订计划，使用户能够为停机时间作出准备。
使用模式	确定部署的使用模式，以确定可执行维护任务的时段。例如，在通常于正常营业时间内出现用量高峰的系统中，适合在傍晚或周末执行维护任务。对于在地域上分散的系统而言，确定这些时段的难度可能更大。
可用性	可维护性往往是可用性设计思想的反映，因为最大限度缩短维护和升级停机时间策略是围绕可用性策略来制订的。要求具有高可用性的系统的维护、升级和检修期较短。处理可用性要求的策略会影响到对维护和升级的处理方式。例如，在地域上分散的系统中，维护方式可能取决于维护期内将工作负载发送到远程服务器的能力。要求具有高可用性的系统可能还需要采用更为复杂的解决方案，使系统重新启动可以自动进行，而几乎不需要人为介入。
诊断和监视	定期运行诊断和监视工具来确定故障区域，可以提高系统的稳定性。这样可防患于未然，有助于根据可用性策略来平衡工作负载及改进维护和停机计划。

服务级别要求

服务级别要求 是一组系统要求，用于指定必须提供客户支持的一些情况。服务级别要求是服务级别协议的基础，通常在项目核准阶段签署该协议。

与系统要求一样，服务级别要求源自业务要求，并代表着对客户的一种担保，即部署必须达到的整体系统质量。由于服务级别协议是与客户间签订的一份合同，因此在服务级别要求的具体规定上不应有模糊之处。服务级别要求对要求的测试条件及不合要求的构成条件均有明确规定。

上一页目录索引下一页
Sun Java Enterprise System 部署规划白皮书