]]>
--在编写代码之前确定好应用E序性能和可伸羃性的限制
旉Q?005-09-27
作者：(x)Peter Varhol
览ơ数Q?3527
本文关键字：(x)设计模式, 架构, 应用E序生命周期, 分布式系l? 中间?/strong>
应用E序开发的生命周期定义得非常好Q许多Y件开发小l都늅它的某种变体q行开发。首先，要定义需求，接下来定义对软g解决Ҏ(gu)的一l要求。然后，依靠架构师（或应用程序设计h员，随?zhn)怎么U呼Q的技能，定义应用E序所需实现的功能，q绘制原理图Q以构徏应用E序q将其映到企业基础架构?/p>
开发h员根据该原理图进行编码，直到包含了所有的功能Q而且大多数的bug都已l消除。最后，应用E序被交l测试h员，他们可能按照需求进行正式的试Q也可能只查找bug。但是，通过试q行的代码，他们通常都能扑ևbug和其他缺P然后其归纳、记录，q返回给开发h员从而解冟뀂针对一个Y件版本，q个往q过E可能要花几个月的时_(d)q取决于试组使用的质量标准?/p>
在传l的生命周期中存在着隐?zhn)。通常试人员是第一个对应用E序的Q意部分进行非功能需求（q些需求定义的不是具体的功能，而是响应性、当前用L(fng)数量或正常运行时_(d)试的。猜猜会(x)怎么P他们通常发现应用E序存在~陷Q或者不能达到要求的用户数量Q或者响应速度不够快而造成不便。所以应用程序又q回到开发阶D，q行分析QƈҎ(gu)些部分进行修改，但是修改的通常不是需要修改的部分。不怎样Q最后它部v了，用户只好凑合用；或者它被废弃，成ؓ(f)又一个失败的应用E序开发?/p>
应用E序其余的执行时间都花在哪里了呢Q答案是花在cd、JVM或是数据库的讉K上了。可以采用一些策略改q数据库讉KQ比如用邻接原?contiguity principle) 或其他算法在查询时取出或~存额外的数据。虽然这些策略有助于加速应用程序，但是其作用有限，而且它们q会(x)妨碍另一个重要目标：(x)可~性。性能和可伸羃性必d设计时考虑Q而不是到~码时才考虑?/p>
应用E序架构设计拙劣的另一个原因是Q由于较高的成本或技术上的限Ӟ被取消或是大q羃减的开发项目的比例一直居高不下（据调查表明，通常?0%?0%Q。许多因素造成了项目的p|或取消，最常见的是需求的变化。但是很多情况下Q不好的架构也是原因之一。业务需求可以也肯定?x)随旉改变Q因此Q何作x案的架构都必dq个因素考虑在内。灵zL强的架构未必能成功Q但是很可能?x)提高交付有用项目的几率?/p>
形势与以前不一样了Q过L可能通过巧妙地更Ҏ(gu)些代码而大大提升性能和可伸羃性，而今都是q行在虚拟机上的分布式应用程序，必须更改架构才能辑ֈ相同的效果。每个开发h员手中都只掌握了全部代码的一部分，而且做出了许多媄(jing)响了性能的决{?/p>
更改架构比更改代码更难，q有两个原因。首先，更改架构不是一容易理解的行ؓ(f)Q而它所需的技能也与更改代码所需的技能完全不同。其ơ，架构的更改必d应用E序生命周期的早期进行。如果等到后期的~码阶段对应用程序进行测试时才定义架构上的限Ӟ那么已完成的应用E序很难被挽救了?/p>
Z么会(x)有如此多不适当的应用程序架构呢Q这有很多原因：(x)
分布式系l还是比较新的事物。虽然ȝ来说其优点和局限性已lؓ(f)大家所知，但是要将q些一般性原理应用到特定的应用和基础架构中却很困难?br />因ؓ(f)q些pȝ比较斎ͼ所以有兌计和最?jng)_늚信息传播得还不够q，以至于企业的主要架构师还不曾体验q新的设计实c(din)?br />不同的应用服务器?qing)其他的中间件的性能和可伸羃性不同。此外，q些lg的调整要求也不同Q通常需要专门的知识或细心的研究?br />除了企业应用E序需求的多样性外Q通常架构师还被要求用对于应用程序来说不是最佳的基础架构和中间g。这不是因ؓ(f)架构师的能力或经验不够，而是因ؓ(f)他们受制于工作现实?/p>
构造目?/p>
最后一炚w要特别注意。架构师们被告知Q或者自p为，必须按照已经qA的中间g和基架构的参数工作。在许多情况下，q种U束像试图一个方形的木柱打入一个圆形的z一栗例如，企业中网l的最初设计目标可能是针对来自PC服务器的文gQ而不是针Ҏ(gu)自基于Linux的应用服务器的事务?/p>
在某些情况下Q这U不匚w是无法避免的。用次优的支持服务有时是迫不得已的。这里有一个折L(fng)问题。糟p的应用服务器、不合适的|络Q或其他的基架构lg可能促成不好的架构——至成为其借口?/p>
q就是ؓ(f)什么在为新的分布式应用E序定架构时只看应用程序是不够的。那些架构师能够将应用E序设计映射为基架构参数的开发方法，很有可能识别限制应用程序其不能达到预定目标的基础架构问题?/p>
定提议的架构可以应用于现有的基架构是一个好的开端，但是q不能够满针对特定的特性最优化该架构，或者重新配|基架构以更好地遵从服务层协议的需求。对于在~码开始之前确保能够很好地满性能和可伸羃性目标，架构师负有很大的责Q?/p>
在构建应用程序架构方面，有很多辅助程序。Sun Microsystems的模式和最?jng)_践Web站点提供了许多设计模式，其中大多数都是架构模式而不是编码模式，因此是一个很好的L(fng)。微软提供了其Web站点的应用程序架构部分，其中有大量的设计模式和其他的一些徏议。虽然其中许多模式用的都是微Y的技术，但是那些则普遍适用于Q何分布式应用E序?/p>
有哪些架构模式可用？q泛使用的模?视图-控制?Model-View-ControllerQMVC) 模式?qing)其很多变体是很好的代表Q另外还有安全性、n份验证和授权{主题。数据管理和讉K被作为在应用层之间传递数据的{略q行讨论。所有这些以?qing)其他模式对于设计分布式应用E序的最优性能和可伸羃性都是有用的模式?/p>
除了q些、其他来源的Q以?qing)咨询公司的服务Q似乎还~少一个ƈ非推荐特定品或解决Ҏ(gu)的最?jng)_늺要。问题是q样的集合将?x)随形势而不断变化，因ؓ(f)有如此多的因素媄(jing)响着分布式应用程序的最优化。但是，存在_多的不同来源和模式，可以为架构师提供有关在大多数q_和中间g下设计分布式应用E序q|应用程序组件的各种和方向?/p>
Ҏ(gu)构师q行良好的教育和培训也是因素中的一部分。例如，我还没有看到关于应用E序架构的大学课E（如果实存在请告诉我Q。大多数情况下，大学的课E都只重视对整个应用E序或单个应用程序组件的~码Q而一般都忽略了分布式应用E序。这U不好的局面必L变，q样才能培养出可以开发现实世界的分布式系l架构的专业人员?/p>
l架构师的徏?/p>
总而言之，从现在开始，软g开发小l和用户代表需要重视应用程序架构了Q要其看作是编码之前的一个关键步骤。虽然当今的IDE和应用程序框架ɾ~码变得L了，但是它们Ҏ(gu)构毫无帮助。我试着扑և解决的方法?/p>
我的计划是进行架构审查，在这个过E中所有涉众（包括用户Q都看到了关于新应用E序的提议架构的演示文稿Q包括ؓ(f)什么采用这U架构，该架构对哪些部分q行了最优化Q以?qing)进行了哪些折衷。当然了Q审查是由架构师L的，而且他或她的d是涉众怿Q该架构W合每个人的最大利益。自然会(x)有一些目标互相冲H，必须通过妥协才能解决Q但是最l结果是产生一个业务目标和技术目标都能最大程度地得到满的架构。要编码的应用E序可以实现它必d现的性能和可伸羃性要求的{略q有待不断地完善和发展?/p>
参考资?br />FTPOnline上的“The Business Perception of MDA”，由Java Pro的编辑撰写，2005q??日?/p>
原文出处
http://www.ftponline.com/javapro/2005_06/magazine/columns/objectenterprise/?sid=rssfeed_channelJava
作者简介?br />Peter Varhol是Compuware公司的技术专?
]]>