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

想建立一个可升级的应用程序吗？我也是。我心中一直担心我们为提高可升级给应用程序（特别是Web应用程序）增加的全部层次……嗯，它们伤害到应用程序的性能。

在客户端、演示层、商业逻辑层、数据访问层和数据库之间建立会话，是一种日益常见的模式。这样做有一定意义。为了每个层次将来发展的互用性的复用性，我们最终通过XML、SOAP或类似的工具（还有人记得CORBA吗？）来实现这一目的。这些全都有一定道理。让我们在这上面增加更多层次。

毕竟，如果应用程序拥有了足够多的用户，我们就需要在这些层次间建立某种状态共享，因此我们在每个层次上增加群集技术。总之，由于所有这些并行请求彼此交互，我们需要能够维持状态，在会话和应用程序层……在服务器之间锁定。让我们面对这个问题。

如果我们正考虑建立一个足够大的系统，必须担心能够增加商业逻辑处理服务器而不必增加演示逻辑服务器（它们以不同的速度升级），那么这个应用程序的规模和重要性就足以需要某种冗余、故障恢复、负载平衡和更多功能。这意味着利用共享“材料”建立群集。

现在我们建立了这种畸形结构，追踪一个错误涉及两个三个XML事务、（至少）三个逻辑服务器（它们可能全都处在相同的硬件上）、和一个大型监控软件。

集成了支付宝的淘宝旅行客户端 真是混乱！很容易说：“嘿，让我们把应用程序逻辑、演示逻辑和数据访问逻辑全部放在相同的层次，如果系统出现故障，那么会话就会丢失。”但是如今客户在购买合同中要求99.999%的精确性、SLA和性能标准。因此我们的应用程序需要速度快捷、具有可升级性、并且运行稳健。而“可升级性”和“稳健”又与“快捷”相对立。