ESB的伸缩性方案是在ESB上重复发布相同的服务，形成服务镜像。当请求到来时，压力稍小的服务会首先处理消息，从而起到平衡系统负载的作用。但是，由于ESB系统本身较之传统技术存在更大的性能开销，所以两者之间在性能上还存在一定差距。
传统的负载平衡系统是一个完整应用系统的镜像行为，而ESB则可以针对每个服务环节的具体负载，制定不同的平衡策略,这大大提高了系统实现伸缩的灵活度。
ESB技术从EAI衍生而来，并伴随
SOA的发展走过了相当长的路程，但它仍然面临一系列挑战，主要表现在性能、事务处理、兼容性三个方面。
挑战一: 性能低SOA由服务集成发展到软件服务化，又进一步发展到基于服务的高级开发，使软件系统增加了很多环节，软件内部形成了很多消耗。而随着
SOA应用规模的扩大，这些消耗将带来潜在的市场风险。如何将这些消耗降低到最小，成为开发商十分头痛的问题。笔者的团队曾经将一个基于传统技术Struts + Spring + Hibernate的Web应用，历经多次技术模型的改造，最终成功移植到ServiceMix3.1的ESB上，然后对两个系统做了平均响应速度的对比。在200个并发请求时，结果约为1比3。也就是说基于ESB的应用系统，性能仅达到常规技术的三分之一。进一步的分析结果和我们对ServiceMix3.1的技术掌握基本上是吻合的：其先进的技术理论所带来实际运行环境中各种的开销，均表现出瓶颈效应。
各方面力量都在不断地进行着提升
SOA性能的尝试，比如Xml的流式处理就是十分成功的一个例子。加之计算机硬件系统的发展，
SOA的性能问题正在得到解决。
挑战二: 事务处理难事务问题已经在.net和j2ee得到了很好的解决。这些容器型事务为单点应用提供了很好的开发模型。但是
SOA是一种多点应用模型，服务提供者之间关系更加松散，并且其技术实现几乎被忽略，所以容器型事务根本派不上用场，这就给大规模
SOA应用设置了巨大的障碍。到目前为止，
SOA只能通过事务协调方式提供一种手动回滚的模式来解决这个问题。但是，这对于习惯了容器型事务的开发者来说，简直就是刀耕火种。
事务问题的解决可能会体现在两个方面：一是通过更加智能化的开发辅助工具减轻开发者的负担；另一方面是在局部提供针对数据库的多阶段提交型的事务支持。但后者将限制服务提供者所采用的实现技术。
挑战三: 兼容性差随着软件系统规模的日趋扩张，平台、技术的兼容性问题已经成为构筑平等的商业环境的必要条件。比如：J2ee曾经是一个十分成功的标准，众多厂商推出了兼容的
应用服务器，这为企业提供了一个合理的商业环境，他们不必被绑定到某个特定的供应商，基于某个J2ee平台的应用系统付出很小的代价后，就可以移植到另一个兼容的平台上。
而ESB在这个问题上所面临的处境则十分尴尬，几乎每个厂商所提供的ESB都使用自己的标准，移植问题并不在他们的考虑范围之内。SUN曾经推出过JBI，但是并没有得到主流厂商的推崇，后来不了了之。
有人说，Web2.0和
SOA珠联璧合；也有人说，ESB是
SOA的基础与核心；还有人说，最重要的是找到快速切入
SOA的技术手段……实施
SOA是美好的憧憬，也是艰难的跋涉，就让道听途说的状况到此为止吧。12月20日，身处一线的
SOA资深专家将现场过招，详解案例，直面难题，你来不来？
敬请关注12月20日14时在北京理工大学国际教育交流大厦举办《巅峰访谈：整合异构，从ESB切入SOA》，机不可失，报名从速(疑难问题同步征集中)。http://www.51cto.com/actions/actions/ibmfangtan/index.html
（c112）
|
服 务 CIO 推 进 信 息 化 
