（转载）ESB的前世今生（上）

序言

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

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

 

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

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

企业集成软件的发展史

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

 

基于标准协议的代码定制

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

基于消息的代码定制

 

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

<?XML:NAMESPACE PREFIX = V ?>
集线器模式

 

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

 

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

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

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

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

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