级别： 中级 Kris D. Hansen (kris.hansen@mac.com), 解决方案架构师, 自由作者
2008 年 1 月 29 日 设计应用程序架构需要了解应用程序的部署环境。您必须对哪些人将使用应用程序以及他们的使用方式加以假设。对于包含会带来不确定性和潜在变更因素的环境，本文讨论可帮助减少易变性对应用程序影响的方法和工具。
架构师角色还要求能够对将来的情况进行预测。这可能会很困难，因为这是针对给定需求设计正确的解决方案的一个重要方面。如果所有当前和将来的需求都得到了清楚而简洁的说明，预见将来的情况将更为容易一些，但很少有这种好事。您需要了解全局（现状和将来的情况），然后使用您的经验和判断力确定最佳的解决方案。
图 1. 变更因素以及能够对其加以缓解的体系结构工具和方法
对于较小的低投资应用程序，这种远见可能重要性要低一些。在这些情况下，投资的量很小，完全放弃应用程序所带来的后果很小。而对于开发大型的战略业务应用程序的情况，考虑将来的情况非常重要。如果在应用程序中投入了大量的资金，而这个应用程序几个月或几年之后由于业务环境中的变化而变得不相干，这样的结果并不好，在很多情况下都应该予以避免。
对于进行大量投资的情况，您需要清楚地了解基础业务战略和环境，以确定潜在的易变性的大小以及恰当的设计，从而消除与大规模变更关联的风险。
技能和能力
关于有效软件开发的很多研究都强调了解需求的重要性。大部分架构师都认为这对项目的成功极为重要。不过，在需要发生巨大变化的情况下，通过在了解潜在的原因和变更领域并针对变更进行设计方面进行额外的投资，可让难于更改的应用程序和针对更改进行了准备的应用程序之间的差别明显地表现出来。
易变环境与稳定环境的差别在于，其中的变更都是巨大而突然的。在大多数环境中，可以预期会发生较为缓和的变更，而且能够预见使用模式、资源需求和集成需求。如果不能进行合理的预测，而且有很多未知项，则可以针对不能预知的情况设计和定位应用程序。
存在很多易变源，而且快速的变更经常以意料之外的形式出现。此部分将讨论设计应用程序时要考虑的一些重大变更的示例。
行业影响因素
组织处于行业环境中。如果此环境发生更改，对组织的影响可能会非常大。这个领域您要考虑的问题包括：
- 在应用程序设计期间应该考虑此行业中的哪些宏观趋势？
- 我的组织的战略关系有哪些，这些关系可能会如何变化？
- 组织的战略是什么，应用程序将如何为其提供支持？
行业通常会遵循与发展和巩固关联的模式，在逐渐成熟的过程中会发生变化。如果您所在行业的很多公司最近都考虑了一些影响因素，可能也应该考虑这对于您的公司的可能性。如果行业成熟度不够，变化非常大，行业级的变更的可能性就越高。
预期发展或削减
如果您的组织正在快速发展，请针对这个趋势制定相应的计划。这似乎是基本要点，但非功能需求有时候被视为静态的。在高速发展的环境下，项目开始的时候确定的应用程序规模可能会在实现时重新调整。对于发展，务必了解发展的速度和以及以该发展速度为基础的项目用途和峰值需求。对于高速发展环境中的非功能需求，评估要特别保守。削减是要考虑的另一种情况。如果有些业务部门和产品类别呈现下滑趋势，请在应用程序设计期间对此予以考虑。公司务必了解与为下滑单位或产品线构建系统功能关联的成本/效益关系，因为此领域所带来的效益将会随着时间减少。
成功
成功可以推动系统的应用，而系统通常都是以保守的预计为基础设计的。设计应用程序时，制定成功计划和快速响应广泛的成功应用的方法是非常重要的一个考虑事项。这对于面向公众的基于 Internet 的应用程序尤为重要。对于内部应用程序，可能会随着系统的业务价值在组织内得到认可而广泛采用。这经常会由于新用户组访问系统而产生新需求，如果能够捕获和管理这些需求，将能够延长应用程序的寿命。
合并与收购
如果您的组织有通过收购实现发展的战略，请考虑新收购的实体将如何融入您的设计中。例如，有了考虑全面的数据模型后，就可以更为容易地将各种数据源迁移到您的应用程序中。在确实出现了合并和收购行为的环境中，拥有适应能力的应用程序还要包括考虑可能的集成场景。新收购的部分经常作为独立的业务单位运行，但在后端进行了集成，用于进行企业报告和其他用途。
工具和技术
应用程序灵活性是减少变更风险的方法。如果您确定应用程序以后存在易变性的潜在可能，则可以采用多种方法来建立应用程序灵活性。
务必注意，灵活性经常是需要付出代价的。您需要将增加的复杂性或工作所相关的好处与向设计中添加此元素所带来的成本进行权衡。另外，还要务必考虑所需的应用程序寿命。如果希望应用程序仅使用几个月或数年，可能要对额外的灵活性组件方面的投资予以重新考虑。
模型驱动的体系结构
基于系统的完整模型设计应用程序可以更为方便地了解和实现更改。此模型可以包括依赖关系和交互关系，以便了解重构期间决策的影响。可以采取多种方法处理模型驱动的体系结构（Model-Driven Architecture，MDA），包括全部或部分代码从模型生成的方法和将模型作为开发指南使用的方案。统一建模语言（Unified Modeling Language，UML）是描述应用程序的标准方法，是 MDA 开发方法不可或缺的部分。
有人预言，面向服务的体系结构（Service-Oriented Architecture，SOA）将导致 MDA 的灭亡。务必对 MDA 原理的范式应用与 MDA 的完整理论远景加以区别。SOA 改变了组织对开发应用程序的思维方式，而这对 MDA 的完整远景形成了挑战，但模型中的建模和驱动应用程序架构是开发能应对变更的应用程序的有效方式。
基于 Eclipse 的 IBM® Rational® Software Architect V7 就是将建模与开发联系起来的例子。Rational Software Architect 是 IBM Rational Application Developer 和 IBM Rational Software Modeler 的组合。Rational Software Modeler 能够方便地重构模型，然后将其导出为 UML 或可扩展标记语言（Extensible Markup Language，XML）元数据交换（Metadata Interchange，XMI）格式。
图 2. IBM Rational Modeler 7 正在执行模型重构
业务流程管理
将与您应用程序关联的业务流程管理外部化，可极大减少与流程变更相关的工作量。通过此设计元素，工作流路由和流程在应用程序外的业务流程管理（Business Process Management，BPM）工具中管理。BPM 工具通常可对流程的设计、执行和管理起到促进作用。通过此设计组件，可以方便地完成工作流变更（例如，对某个事务多添加一个审批者），而不会影响代码本身。组织中的必须遵循不断变化的法律法规要求的应用程序特别适合使用 BPM 工具。
业务规则引擎
通过将业务规则从代码中外部化并将其向用户提供，可以有效地构建能应对未来变化的应用程序。目前有多个组织提供规则引擎，还有定义第三方规则引擎接口的 Java™ Specification Request (JSR-94)。
通过实现规则引擎，可以由业务分析人员管理和实现业务规则的变更，从而避免编程来更改业务逻辑。
本体建模
本体 (Ontolog) 是实体及实体间的关系的描述。本体用于将复杂领域表示为模型，并会进行共享，以提高领域相关的一致性和集体知识。通过使用本体编辑器，能够采用可视的方式建模、定义和表示实体关系，然后将本体导出为 XML 或资源描述框架（Resource Description Framework，RDF），以供在应用程序中使用。在进行实体关系重大重构时，能够以可视的方式对其进行建模、验证，然后导入到应用程序中，在理想的情况下可以避免任何编程更改。
图 3. 浏览饼图的本体
参数化
通过在可能会出现变更的的地方为应用程序构建参数，可帮助避免对应用程序的各个部分进行重新开发。在可行的情况下，请考虑不将任何设置或值编码到应用程序中，而将其作为参数放置在数据库中，且仅能通过严格受限的管理用户界面进行访问。
发布与订阅
让您的应用程序将事件发布到服务总线中，并订阅其他事件，通过这样可以在应用程序集成活动方面为应用程序实现松散耦合。不要使用点对点 Java Message Service (JMS) 连接，而考虑使用订阅。通过这一方式，可提供一定的数据源抽象，在将来集成点增加的情况下可更为方便地管理集成。
企业服务总线
与前面所述的发布和订阅模式提供的抽象类似，企业服务总线（Enterprise Service Bus，ESB）也能对端点进行抽象，降低管理相互依赖性的复杂度。ESB 更进了一步，提供了多种协议工具和 SOA 标准。ESB 产品中经常包括存储库或目录服务，便于向基于 SOA 的集成方法过渡。
大部分 ESB 产品还具有传统的企业应用程序集成（Enterprise Application Integration，EAI）优势，如应用程序适配器和消息转换与充实支持。在您的集成战略中包括 ESB 可减少将来与新的未知的业务合作伙伴集成所需的工作。
面向服务的体系结构
使用 SOA 作为提高灵活性的方法这个话题本身可能就需要另外再写一篇文章进行讨论。到目前为止讨论的其他方法都能够与 SOA 方法一起工作，帮助处理集成和应用程序设计。
SOA 已经发展为了一个多层次的讨论。它是一种业务战略或新的思维方式，但也是设计和集成应用程序的一种方法。SOA 的精髓在于能够解决实际问题的松散耦合粗粒度服务。
将应用程序定义为服务的集合，可帮助进行重用和减少与添加新业务服务相关的变更影响。在管理服务重用相关的依赖关系方面需要新规程和治理，在考虑过渡到采用 SOA 方法进行开发和集成时您需要考虑这一点。
里程碑
易变环境的应用程序架构设计有两个方面：设计和实现后考虑事项。在设计阶段，要在预期会发生变更的领域选择体系结构方法和组件，而且功能需求中要求实现灵活性。对于实现后考虑事项，应用程序设计为能够响应非功能需求中的变更。
应用程序投入使用后，将对非功能需求相关的假设进行验证。在高速发展的环境或易变环境中，通常很难得出与负载和性能相关的评估。在此环境中，可伸缩性方面的规划非常重要！
在动态环境中，应用程序性能和使用率就是一个移动靶。上周运行情况良好的应用程序可能会在这周被大量的请求所吞没。
可以采取很多方式扩展功能和提高应用程序的性能。在设计和实现期间对此予以考虑，将会减少经常与非计划使用相关的工作和混乱。
垂直扩展
为了能够垂直地扩展，需要将应用程序部署到可在尽可能小地影响部署的情况下提高计算容量的平台上。现在市面上有高可伸缩性硬件，能够在不造成应用程序中断的情况下无缝地增加处理、内存和磁盘容量。较高版本的 IBM System i™ (iSeries®)、IBM System p™ (pSeries®)、IBM System x™ (xSeries®)、IBM BladeCenter® 和 IBM System z™ (zSeries®) 服务器都能够实现此功能。有些更高端的服务器允许以增量方式购买处理器，能够随着处理需求的增加进行购买和启用。
水平扩展
要以水平方式提高应用程序性能，您的设计需要能够包含进可参与工作负载的其他服务器。可以通过应用程序设计、服务器集群化、负载平衡、复制或所有这些方法的组合来实现此目标。如果应用程序是完全无状态的，其设计方案不会在应用服务器或数据层保留会话状态，每个连接实际上不包括会话的任何历史记录或上下文的新连接。读到这句话的开发人员可能会感到有些怕了。此外，无状态很难实现，可能会导致多次往返数据库来获取本来通常存储在会话上下文中的信息。不过，设计无状态应用程序的优势在于，可以非常容易地实现水平扩展。添加 Web 服务器、应用服务器和数据库服务器及其上的负载平衡都非常简单。如果预期会出现额外的负载，添加服务器可提高系统处理能力。有状态应用程序也可以水平扩展，而这通常涉及到在应用服务器集群中复制会话状态（这是大多数企业级应用服务器的一项功能，包括 IBM WebSphere® Application Server）。扩展有状态应用程序的好处并不明显，原因在于，增加了复杂性以及与状态或数据复制相关的性能影响。因为在可用性方面有其他改进，通常有必要进行水平扩展。
了解性能
管理易变环境中的应用程序的最重要的一个方面是要清楚地了解应用程序的性能表现。性能是一个较为模糊的问题。仅仅监视中央处理器（Central Processing Unit，CPU）和内存使用率并不够。了解应用程序在各个层次上的性能以及如何处理每类事务或存在延迟的地方，这是至关重要的一个方面。
应用程序的性能测试在实现过程中是非常关键的一步，特别是预期用户行为未知或预计会出现使用高峰时更要如此。性能测试的目的是为了在部署平台上验证性能水平是否达到预期值，另外还要了解应用程序在此环境中的性能状况。还要务必进行压力测试，以了解应用程序能够处理的上限、性能所处的水平以及超过最优负载所表现出的症状。了解应用程序在过载时的行为方式，可帮助您确定针对应用程序和硬件环境需要处理的问题。
您可以使用引导 Java Virtual Machine (JVM) 的诊断工具进行性能监视，并提供应用程序在 JVM 上执行时的内部视图。这些工具能够标识延迟源，确定应用程序和操作环境中的瓶颈源。还可以在生产环境中运行探测器来了解性能，但应对诊断的级别进行限制，以免影响性能。
制定可伸缩性计划
如果您预计可能需要对应用程序进行扩展，请创建可伸缩性计划。此步骤可节约确定哪些选项将最好地提高容量和改进性能的时间。此计划应该从适合您环境的角度确定性能里程碑（例如用户数量或每日处理的事务总量），并将这些阈值与能提高吞吐量的改进建立联系。有时候垂直扩展可能不再可行，或者可能需要进行大量的体系结构更改。在可伸缩性计划中包括这些内容，可以为要实现的措施提供足够的时间。
总结
预见将来的情况是十分困难的，但预见易变性却是可能的。这意味着需要考虑全局，并验证当前假设的边界。如果预见了不确定性，而且投资合理，则可以在应用程序设计期间进行决策，以减少以后变更对应用程序的影响。实现了应用程序后，需要了解可伸缩性选项，以确定采用哪个选项以及何时应用。此方法可帮助您的设计更长时间保持其适用性，并最终实现更高的成本效益。
参考资料 学习
获得产品和技术
讨论
关于作者  | 
| | Kris Hansen 是企业技术架构师和撰稿人，使用 IBM 技术已有 10 多年。他获得了七项 IBM 认证，包括 IBM 认证解决方案架构师 (IBM Certified Solutions Architect)、解决方案设计师 (Solutions Designer) 和解决方案技术专家 (Solutions Technologist)。Kris 是位于夏威夷檀香山的一家 IBM 业务合作伙伴的 VP/CTO，并带领他的团队完成了很多成功项目的体系结构、评估和交付工作。他最近返回了加拿大，为一家快速扩大的地区银行设计技术解决方案。 |
对本文的评价
| 
