开发人员根据该原理图进行编码，直到包含了所有的功能，而且大多数的bug都已经消除。最后，应用程序被交给测试人员，他们可能按照需求进行正式的测试，也可能只查找bug。但是，通过测试运行的代码，他们通常都能找出bug和其他缺陷，然后将其归纳、记录，并返回给开发人员从而解决。针对一个软件版本，这个往返过程可能要花几个月的时间，这取决于测试小组使用的质量标准。

　　在传统的生命周期中存在着隐患。通常测试人员是第一个对应用程序的任意部分进行非功能需求（这些需求定义的不是具体的功能，而是响应性、当前用户的数量或正常运行时间）测试的。猜猜会怎么样？他们通常发现应用程序存在缺陷，或者不能达到要求的用户数量，或者响应速度不够快而造成不便。所以应用程序又返回到开发阶段，进行分析，并对某些部分进行修改，但是修改的通常不是需要修改的部分。不管怎样，最后它部署了，用户就只好凑合使用；或者它被废弃，成为又一个失败的应用程序开发。

　　应用程序其余的执行时间都花在哪里了呢？答案是花在类库、JVM或是数据库的访问上了。可以采用一些策略改进数据库访问，比如使用邻接原理(contiguity principle) 或其他算法在查询时取出或缓存额外的数据。虽然这些策略有助于加速应用程序，但是其作用有限，而且它们还会妨碍另一个重要目标：可伸缩性。性能和可伸缩性必须在设计时考虑，而不是到编码时才考虑。

　　应用程序架构设计拙劣的另一个原因是，由于较高的成本或技术上的限制，被取消或是大幅缩减的开发项目的比例一直居高不下（据调查表明，通常是30%到70%）。许多因素造成了项目的失败或取消，最常见的是需求的变化。但是很多情况下，不好的架构也是原因之一。业务需求可以也肯定会随时间改变，因此任何作为解决方案的架构都必须将这个因素考虑在内。灵活性强的架构未必能成功，但是很可能会提高交付有用项目的几率。

　　形势与以前不一样了，过去有可能通过巧妙地更改某些代码而大大提升性能和可伸缩性，而今都是运行在虚拟机上的分布式应用程序，必须更改架构才能达到相同的效果。每个开发人员手中都只掌握了全部代码的一小部分，而且做出了许多影响了性能的决策。

　　更改架构比更改代码更难，这有两个原因。首先，更改架构不是一项容易理解的行为，而它所需的技能也与更改代码所需的技能完全不同。其次，架构的更改必须在应用程序生命周期的早期进行。如果等到后期的编码阶段对应用程序进行测试时才定义架构上的限制，那么已完成的应用程序就很难被挽救了。

　　为什么会有如此多不适当的应用程序架构呢？这有很多原因：
分布式系统还是比较新的事物。虽然总的来说其优点和局限性已经为大家所知，但是要将这些一般性原理应用到特定的应用和基础架构中却很困难。
因为这些系统比较新，所以有关设计和最佳实践的信息传播得还不够广，以至于企业的主要架构师还不曾体验过新的设计实践。
不同的应用服务器及其他的中间件的性能和可伸缩性不同。此外，这些组件的调整要求也不同，通常需要专门的知识或细心的研究。
除了企业应用程序需求的多样性外，通常架构师还被要求使用对于应用程序来说不是最佳的基础架构和中间件。这不是因为架构师的能力或经验不够，而是因为他们受制于工作现实。

构造目标

　　最后一点需要特别注意。架构师们被告知，或者自己认为，必须按照已经就绪的中间件和基础架构的参数工作。在许多情况下，这种约束就像试图将一个方形的木柱打入一个圆形的洞一样。例如，企业中网络的最初设计目标可能是针对来自PC服务器的文件，而不是针对来自基于Linux的应用服务器的事务。

　　在某些情况下，这种不匹配是无法避免的。使用次优的支持服务有时是迫不得已的。这里有一个折衷的问题。糟糕的应用服务器、不合适的网络，或其他的基础架构组件可能促成不好的架构——至少成为其借口。

　　这就是为什么在为新的分布式应用程序确定架构时只看应用程序是不够的。那些使架构师能够将应用程序设计映射为基础架构参数的开发方法，就很有可能识别限制应用程序使其不能达到预定目标的基础架构问题。

　　确定提议的架构可以应用于现有的基础架构是一个好的开端，但是并不能够满足针对特定的特性最优化该架构，或者重新配置基础架构以更好地遵从服务层协议的需求。对于在编码开始之前确保能够很好地满足性能和可伸缩性目标，架构师负有很大的责任。

　　在构建应用程序架构方面，有很多辅助程序。Sun Microsystems的模式和最佳实践Web站点提供了许多设计模式，其中大多数都是架构模式而不是编码模式，因此是一个很好的起点。微软提供了其Web站点的应用程序架构部分，其中有大量的设计模式和其他的一些建议。虽然其中许多模式使用的都是微软的技术，但是那些建议则普遍适用于任何分布式应用程序。

　　有哪些架构模式可用？广泛使用的模型-视图-控制器(Model-View-Controller，MVC) 模式及其很多变体是很好的代表，另外还有安全性、身份验证和授权等主题。数据管理和访问被作为在应用层之间传递数据的策略进行讨论。所有这些以及其他模式对于设计分布式应用程序的最优性能和可伸缩性都是有用的模式。

　　除了这些建议、其他来源的建议，以及咨询公司的服务，似乎还缺少一个并非推荐特定产品或解决方案的最佳实践纲要。问题是这样的集合将会随形势而不断变化，因为有如此多的因素影响着分布式应用程序的最优化。但是，存在足够多的不同来源和模式，可以为架构师提供有关在大多数平台和中间件下设计分布式应用程序并配置应用程序组件的各种建议和方向。

　　对架构师进行良好的教育和培训也是因素中的一部分。例如，我还没有看到关于应用程序架构的大学课程（如果确实存在请告诉我）。大多数情况下，大学的课程都只重视对整个应用程序或单个应用程序组件的编码，而一般都忽略了分布式应用程序。这种不好的局面必须改变，这样才能培养出可以开发现实世界的分布式系统架构的专业人员。

给架构师的建议

　　总而言之，从现在开始，软件开发小组和用户代表需要重视应用程序架构了，要将其看作是编码之前的一个关键步骤。虽然当今的IDE和应用程序框架使编码变得轻松了，但是它们对架构毫无帮助。我将试着找出解决的方法。

　　我的计划是进行架构审查，在这个过程中所有涉众（包括用户）都看到了关于新应用程序的提议架构的演示文稿，包括为什么采用这种架构，该架构对哪些部分进行了最优化，以及进行了哪些折衷。当然了，审查是由架构师主持的，而且他或她的任务是使涉众相信，该架构符合每个人的最大利益。自然会有一些目标互相冲突，必须通过妥协才能解决，但是最终结果是产生一个业务目标和技术目标都能最大程度地得到满足的架构。使要编码的应用程序可以实现它必须实现的性能和可伸缩性要求的策略还有待不断地完善和发展。

参考资料
FTPOnline上的“The Business Perception of MDA”，由Java Pro的编辑撰写，2005年4月6日。

原文出处

http://www.ftponline.com/javapro/2005_06/magazine/columns/objectenterprise/?sid=rssfeed_channelJava

 作者简介 
Peter Varhol是Compuware公司的技术专家.