SOA架构风格中用到的ESB和Java中常用的dubbo服务的区别

一、概述

1、什么是ESB

ESB（Enterprise service bus）-----企业服务总线的简写。
就是企业数据总线的意思，他的核心功能就是兼容各种协议接口，可以将数据在各种协议之间进行流转，并且可以针对数据格式进行编排转换。（格式转换、协议转换、代理、编排、安全控制、监控、不支持高并发，类似于路由器维护着一张路由表进行路由转发）。它是实现soa架构风格中的一个重要组成单元。

把ESB从webservice的角度去理解，webservice是使用SOAP、XML、UUID、WSDL相结合的方式来解决不同应用间通信的，属于一种系统与系统直接的直接关联，而ESB则可以看作一个中转站，用于接收上一层发送的信息，然后处理并转发到下一层。而这样做的好处是： 若多个系统间通讯时，使用传统的webservice，将可能会出现如下情况。

     

　　而是用ESB的方式，则会更加的清晰：

　　

　　并且，由于两个系统之间不需要直接进行交互，也避免了因为两个系统之间的接口不一致而需要在两个系统之中进行协调的尴尬，在ESB中A系统传输的内容可以和B系统所接收的内容形式上不一致，但可以通过ESB中间的逻辑进行修改赋值，这样一来两个系统只需要关注自身的业务和暴露的接口就可以了，而不用去考虑接收信息或发送信息的系统。

代表性的项目有：JBOSS ESB,Mule,Camel 以及一些其他的esb项目

2、什么是服务注册，dubbo又是什么

就是将所有的服务接口（很多时候是hession协议的接口）,注册到一个中心的分布式服务集群上（你可以考虑成apache的zookeeper服务实现的效果）。各个业务系统直接访问分布式服务查找需要调用的接口位置，进而调用。（注册目录服务、监控、负载均衡、安全控制、分布式强健壮、适用于高并发）

代表性开源项目有：阿里的dubbo，淘宝的HSF(现在不知道是否继续开源了)

dubbo最初是阿里的一个Java远程调用框架（阿里贡献出来给开源社区了，现在是apache dubbo），不是什么“注册服务管理”，dubbo支持使用zookeeper或者redis做注册中心，所以你也可以认为dubbo包含了注册服务管理的功能（主要强调注册、管理功能较弱）、但又不仅仅是服务注册管理。

二、双方特点

1、ESB的特点

ESB一般采用集中式转发请求，适合大量异构系统集成，并且压力不大的情况，但集中式转发也是有优势的，比如调用方用http协议，提供方用rmi协议，转发就可以转换协议，对双方都透明。另外，在总线上还可以执行流程引擎，做服务编排，比如A和B两个服务经常一起调，就可以编排成服务C，而不用再单独启一个服务去做。还有，安全，流控，做起来也更方便。
支持groovy类型的脚本语言，在总线上可以给数据格式做转换

2、服务注册管理 及dubbo的特点

采用的是分布式调用，注册中心只记录地址信息，然后直连调用，适合并发及压力比较大的情况。
对于网站应用，大多是垂直业务，直接从数据库拉数据展示。

dubbo不是ESB那种试图管天管地啥都要管的东西，dubbo的目的很明确，就是提供一个java应用之间的、高效的远程调用框架。

dubbo的注册中心，只是提供一个注册和查找服务的地方，查找到之后，A系统就直接调用B系统的服务了，中间并没有一个统一的数据通道之类的东西。

至于什么java应用和.net应用之间怎么交互，XML转换为Json、或者Json转XML，dubbo说：我从来就没想过这些啊！

三、应用场景

1、ESB

 
esb最常见的场景是，把系统里的集成逻辑，单拉出来， 放到esb容器里来部署，并跟应用系统适配。 这样让应用系统变得只有自己的业务逻辑，简单、轻薄。
劣势：在所有的服务上增加了一个总线作为沟通的渠道。对于较大的并发量会将瓶颈推到ESB总线上。很多时候ESB总线都采用MQ类的消息服务器来异步处理缓解压力

2、服务注册

淘宝和阿里的各个业务系统提供了很多的接口，这个时候需要统一管理提供个各子业务系统使用，让各个子业务系统可以通过注册中心很快找到对应的服务
劣势：服务编排和协议转换还是靠各个业务子系统了

四、综述

1、两类开源项目侧重点不同，ESB侧重任务的编排，性能问题可通过异构的方式来进行规避。无法支持特别大的并发。同一个网段的模式下，总线模式（ESB）相比P2P模式的要差。但是总线模式相比P2P模式，他即是服务注册和发现机制。又是服务提供者。所以，在跨网段服务访问上，Dubbo这种注册模式是不能互通的。但是ESB是可以的（部署在两个网络的边界上），作为两边服务的Exchanger/网关机制，这是ESB模式不能被替换的优点

2、服务注册侧重服务的治理，将各个服务颗粒化，各个子业务系统在程序逻辑上完成业务的编排。但是比较实用较大的并发量，因为dubbo类的只是存放服务地址。有zookeeper类的分布式通讯框架，能保证单点的失败不影响整个系统的业务调用，因为业务接口都是在各个提供服务的子系统中。