谈谈开发应用程序的可升级性与执行性能之间的关系

Java框架灾难就是一个典型的例子。在一个流行的Java应用程序服务器上建立一个应用程序，并在那之上建立无数的框架。Spring、struts、faces与所有其它的Java术语。现在，运行一个无用的功能，如有意引起一个NullPointerException，并检查堆栈轨迹。在作为异常返回前，null值经历了80多个层次。我不是想讨论异常发生的位置，我希望指出的是，处理那个变更需要大量管理费用。在一小段Perl或PHP或Ruby脚本中进行处理，变更在遇到运行时间异常前只运行了几个函数。

这就是为何.NET和Java总不如本地代码快捷的原因：本地代码的编写者很少在OS和应用程序间建立许多层次。这些巨大的框架是如此“心不在焉”，在数据到达目的地前，它们在堆栈中保存50-150份数据。

这段内容有些跑题，但它证明了我的观点。

我们在一个为实现升级、稳健、互用性和未来发展的N层Web应用程序上见到完全相同的处理。我们假设一个客户端请求，在数据库中插入一个新记录：

• 负载平衡的HTTP服务器收到请求，对其进行解析，决定它需要进入哪个应用程序服务器群集。
• 应用程序群集收到请求，然后在演示层对其进行处理。它“了解”请求要插入一项记录，于是给商业逻辑层建立一个请求来处理它。
• 商业逻辑层收到请求，并需要检查保证没有其它请求试图插入一个复制的行（可能需要双击“submit”按钮）。于是它查看它自己的所有其它群集成员的一些共享内存系统，看它们是否在执行相同的操作。如果没有，它就在共享内存中发出一个通知“注意，我马上要做XYZ，请不要做这件事。”商业逻辑层为数据访问层建立一个插入行的SOAP请求。
• 数据访问层收到请求，打开它，弄清楚数据库层要使用哪个存储过程，并通过一个TCP/IP管道调用这个存储过程。
• 数据库收到请求，运行存储过程，并向请求方报告成功。
• 数据访问层收到状态，通过一个SOAP请求响应报告成功。
• 商业逻辑层收到成功通知，并向共享内存报告操作完成，可能还执行其它一些操作，再向演示层返回一个成功消息。
• 演示层选择一个“A-OK”消息并提交。

这实际上是一个省略消息队列等的精简版本。

你现在明白了可升级和稳健是如何侵蚀性能的了。毕竟，插入一个行就发生了8个事务。这与以前的ASP、JSP、PHP或Perl脚本大不相同，它们直接与数据库交互，发生在相同服务器的相同线程的相同进程中，一种占用很小的总体内存、堆栈空间，需要相当小的调用堆栈，不必担心服务器间的通信、网络反应时间等等；而另一种则拥有一个巨大的复杂网络。

可以这样说：如果处理得当，N层应用程序能够在需要的地方增加资源，达到很好的升级，它们运行稳健，并且能够达到99.999%的精确性。但所有这些得以复杂程度显著增加、每个请求需要大量资源为代价。就我所知，市场上存在的另外一个选项是一个大型主机环境，你得把它保存在同一个系统中。请小心做出选择！

文/Justin James

责任编辑：德东

查看本文国际来源