ESB的前世今生

序言

你可能是一家集团企业的CIO，为了维持企业业务正常运转，你已经部署了几个，十几个，甚至是几十个不同的IT系统。这些IT系统在运行初期，为提升企业的执行效率发挥了很大的作用，但随着业务内容的不断深入，你发觉这些业务系统之间是离散的，是孤立的，你希望将这些系统进行整合。更进一步的，你盼望有一种神奇的魔力，不仅能够有效整合遗留系统，新建的IT系统也能够在这种魔力下获得一体化的支持，而你所掌管的IT系统能真正做到随需应变，按需扩充。

你也可能是一家IT公司的CTO，你所带领的团队正在开发一种新的IT应用，你渴望用SOA理念来指导这个新应用的架构设计，但你又不知如何才能使SOA落地；你被灌输了太多的SCA、SDO、BPEL等等的标准与规范，但你却不知道这些标准与规范又该如何运用到具体的项目；你也同样希望有一种神奇的魔力，能够让你的团队多年积累下来的业务逻辑形成跨基础架构、跨技术平台的真正可重用的组件库，而这些组件库在流程编排下形成具体的功能模块，解决具体的业务场景。

那么，你找到问题的解决方案了吗？我有个主意，它叫ESB，它能让你的SOA真正落地。

真是这样的吗？别急，先让我们来了解一下ESB的前世今生......

企业集成软件的发展史

在企业信息化进程的最初，一个应用软件的使用范围可能仅限于某一个部门或某一种业务，由此而导致的情况是：一个大型的企业可能存在多个大小不一且支撑技术不同的应用软件系统，这些系统可能基于不同的编程语言，运行在不同的硬件上，有着不同的系统平台。但随着企业的壮大，业务的发展，部门和部门之间的关键路径和业务接口逐渐增多，各个应用软件之间的信息交互也越发频繁，同时，企业与上下游合作伙伴之间，数据共享、流程整合的需求也不断催生，在这样的背景下，企业应用集成软件应运而生。至今为止，企业集成软件的发展，可以分为三个阶段：

基于标准协议的代码定制

这是最初出现的集成软件。一个业务系统和另一个业务系统直接通话，业务接口采取定制代码的方式，通过一些标准的协议，例如Http、Ftp等，紧密的集成在一起。这种集成方式的缺陷不言而喻：缺乏可靠的数据传输保障；系统毫无弹性可言；数据交换时双方必须同时在线；部署模型是非常复杂混乱的网状结构等等。

基于消息的代码定制

基于消息的异步编程模型，则为企业集成提供了一种新颖的解决方案。传统的消息中间件，能够有效解决数据传输的可靠性、稳定性与安全性，并且，消息提供的异步编程模型，避免了集成双方必须同时在线的问题，于是，人们在原先方式中的数据载体由通过标准协议，换成基于消息，大大提高了数据的可靠性，以及部署上的分布性。但是缺点还是同样明显：路由逻辑和业务逻辑没有分离，系统基本没有扩展性，部署上还是网状结构等等。


集线器模式

集线器模式在基于消息的基础上，引入了“前置机-服务器”的概念，使用一种集线器/插头（hub-and-spoke）的架构，将消息路由信息的管理和维护从前置机迁移到了服务器上，巧妙的把集成逻辑和业务逻辑分离开来，大大增加了系统弹性。由于前置机和服务器之间不再直接通信，每个前置机只通过消息和服务器之间通信，将复杂的网状结构变成了简单的星型结构。

 

集线器模式在企业集成的过程中取得了很大的成功，但是集线器模式的模型自身存在不足：中央服务器的存在导致部署上无法分布开来，同时，中央服务器承担了太多的工作和责任，往往会带来压力瓶颈以及硬件投资上的巨额付出。随着基于集线器模式的EAI系统的广泛使用，更多的不足逐渐暴露出来：

1、  集成的各方之间，依然是一种紧密耦合的方式，一方所暴露的业务接口，只能在当前的集成环境下使用，无法提供可复用的业务价值。

2、  业务系统之间的协议都是基于消息的，有时候很难跨越企业的防火墙。

3、  当集成的需求越来越多的时候，不断添加的功能使得集成系统日趋庞大，缺乏灵活性且难于管理。

那么有没有一种更好的架构可以解决这些问题，并且能够在完成企业集成的同时，带来更大的业务价值？

当人们正在为集线器模式的企业集成架构所表现的不足寻求解决方案时，SOA的思想被提出来了。

划时代的体系思想：SOA

SOA（Service-Oriented Architecture），指的是面向服务的架构，意指将软件按照功能设计成一个个独立封装、支持异步处理的服务，这些服务用标准的方式定义接口，并可以通过标准的协议进行调用。重要的一点是，SOA所定义的接口和调用方式是独立于编程语言和运行平台的。

  

服务

 

SOA

       SOA的思想试图定义一个业界都“认可”、都“遵循”的法则，大家都使用同样的方法来进行互通互联，从而实现无界限的“联通”和最大可能的复用。

SOA是一个具有非常意义的体系思想，是所有软件人员的一个梦想：将中间层再进行抽象，通过一个跨技术架构的元数据和业务逻辑，也就是服务，使之成为可跨企业使用、能够长期积累、并不断丰富的企业业务库和信息资产。夸张一点说，如果所有软件开发都遵循SOA，那么世界软件业将会发生彻底的改变。

但是，SOA思想诞生时，它并不是一个技术标准，也没有相关规范。如何在技术体系上实现SOA？Web服务在这个恰当的时候恰当的出现了。Web服务使业务逻辑能够以标准化的接口（WSDL）提供，并可基于标准化传输方式（HTTP、Message等）、采用标准化协议（SOAP）进行调用。这为SOA的实现提供了可能。

 

向ESB发展

ESB（Enterprise Service Bus），企业服务总线，作为下一代的企业集成技术，巧妙的将总线集成和SOA思想结合起来。ESB 是一项允许开发人员集成异构系统的技术，同时ESB不再面向定制出来的业务接口，它面向的是公共服务。ESB为服务提供者和服务消费者之间的集成提供了一个平台，相对集线器模式的集成系统，具有更有效、更灵活的内部体系结构。

ESB是面向服务的，而服务是基于标准的，例如Web服务，这使得ESB具有屏蔽异构系统平台差异的能力。由于服务本身的独立封装、可以随意插拔，各式各样不同的服务可随时注册到总线中，形成面向服务的组件库，所以，ESB天然就具备很好的扩展性。同时ESB采用了轻量级的分布式体系，可以将更多的处理逻辑分配到多个的端点上，中央服务器不复存在，业务逻辑处理能力及系统压力可灵活调配。

 

ESB是服务提供者和服务消费者之间的桥梁，同时也是服务提供者和服务消费者之间的中介代理，可以提供多种不同的增值服务，带来更多的业务价值。

ESB支持数据处理流程，这些数据处理流程可以是一些简单的路由规则，也可以是功能强大的流程引擎，例如BPEL。这些流程的作用域在逻辑上可以是一个部门内，也可以是多个伙伴企业之间，而在物理拓扑上，可以是跨区、跨国、跨洲，甚至可以是休斯敦和阿波罗飞船之间。

ESB支持数据转换，它已经屏蔽了异构系统之间的平台差别，同时还能屏蔽异构系统之间的同种语义的数据差别，就象翻译能把中文翻译成英文一样，ESB可以把一个系统的业务数据根据规则翻译成另一个系统能够识别的业务数据。

 

几种集成方式之间的比较

      

 

       从图中可以看到，ESB处于最右上方，一个 ESB 架构形成了一个消息集线器和集成服务的互通网格，具有一个彻底分布的集成网络的功能性和智能性。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-419063/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14789789/viewspace-419063/