ESB是什么？

企业服务总线，即ESB全称为Enterprise Service Bus，指的是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。

面向服务的体系结构已经逐渐成为IT集成的主流技术。面向服务的体系结构(service-oriented architecture，SOA)是一种软件系统设计方法，通过已经发布的和可发现的接口为终端用户应用程序或其它服务提供服务。

企业服务总线(EnterpriseServiceBus，ESB)是构建基于面向服务体系结构(SOA)解决方案时所使用基础架构的关键部分，是由中间件技术实现并支持SOA的一组基础架构功能。ESB支持异构环境中的服务、消息，以及基于事件的交互，并且具有适当的服务级别和可管理性。简而言之，ESB提供了连接企业内部及跨企业间新的和现有软件应用程序的功能，以一组丰富的功能启用管理和监控应用程序之间的交互。在SOA分层模型中，ESB用于组件层以及服务层之间，它能够通过多种通信协议连接并集成不同平台上的组件将其映射成服务层的服务。

作为SOA基础架构的关键部分，ESB的功能主要体现在通信、服务交互、应用集成、服务质量、安全性以及管理和监控等方面。在通信方面，ESB能够支持消息路由/寻址，支持多种通信技术、通信协议(如JMS、HTTP)，支持发布/订阅的通信模式，能够处理请求/响应、同步以及异步的消息传递方式，并且要求以可靠的方式传递消息。服务交互方面，ESB上所发布的服务是以当前标准的Web服务描述语言(WebServicesDescriptionLanguage)来定义Web服务的，并且ESB上通常配备有服务目录和发现机制。ESB的重要功能就是集成不同的系统，必须能够支持多种接入ESB的方式(例如将ESB、WebService、CORBA以及使用Socket等方式访问的遗留系统接入到ESB系统)，将接入的系统映射成Web服务。在集成不同系统的同时，必须考虑服务质量方面的问题，如事务性和消息传递的可靠性。对于关键的Web服务，ESB需要以加密的方式进行消息传递，并且必须验证访问者的权限。ESB软件作为SOA基础架构的一个复杂子系统，还必须配有相应的管理和监控功能，用于ESB软件自身的系统管理、日志记录、测量和监控等。目前国内外对企业服务总线的研究都比较积极，IBM的ISV、BEA的AquaLogicServiceBus、开源的Mule、Sun领导的JBI规范草案等，都是企业服务总线的具体实现。但是这些公司的ESB实现都更关注于对自有品牌产品的支持，对如何集成更多分布式组件技术考虑得不够。

国产ESB

伴随着数字化技术的发展，目前企业内的集成架构逐渐从早先的EAI、SOA向更加开放敏捷的微服务架构演进；同时国家对信创生态以及核心技术自主可控的不断推进，使得企业对集成平台体系有了更高的要求。

普元ESB新版本基于支撑单日亿级海量服务调用的高性能高可靠架构，对接企业混合式IT架构，全面支持微服务架构下与异构系统的无缝对接，以完整的信创生态保障核心技术的自主可控，融合低代码能力支持零编码快速集成，并以强大的监控与治理能力实现对集成架构透明化体系化管理，以完善的安全保障措施保证系统运行安全、操作合规，推动业务的持续发展与创新。

主要负责哪些功能呢？

ESB主要负责的功能是保证多个应用系统的服务接入，协议转换，提供可靠的消息传输，数据格式转换，基于内容路由等。

这些功能都是需要基于通信，保证系统之间的通信安全与可靠，所以ESB有了消息队列的全部功能。

ESB有哪些服务接入方式呢？

• RPC 远程过程调用（面向方法）

• SOAP 面向服务的架构（面向消息）

• REST 资源的状态转变（面向资源）

SOA面向服务架构就是基于ESB来完成的。各个系统之间可以是不同的开发公司，可以是不同的开发语言（技术选型丰富），然后通过ESB把所有系统都联系到一起。但是ESB是笨重的SOA架构。

现在流行的是轻量级SOA架构，也就是微服务架构，在以后会越来越流行，运用会更加广泛，这是趋势，毕竟新技术总是会淘汰旧技术。新的技术总会有更加有优势的一面。

ESB开发工具

主流还是以eclipse插件为主。

开发工具的下载，可以参考开源的esb，直接通过源码编译，运行。

地址

https://svn.wso2.org/repos/wso2/tags/tools/ide/eclipse/developer-studio/3.5.0/esb/

服务编排平台与ESB有什么区别?

这个可以说是我们经常被问到的问题，因为现在像IBM和Oracle等的ESB产品也支持Restful API的调用与编排，也可以通过图形化的方式进行拖拽然后进行服务逻辑重组，但是仔细来看这两种平台有相似性也有很大的差异，我们体现在以下一些方面。

1. 首先服务编排平台本身一定要是基于微服务架构开发的且前后端分离的系统，可以分布式部署可以完全融入到企业已有的微服务架构中，编排的后的API服务可以立即部署到微服务架构中并与网关、注册中心、DevOps进行打通，而传统的ESB不行，传统的ESB都是基于SOA架构为基础的CS结构或B/S的单体系统基本上与微服务没有什么关系，其内部组件高度耦合，服务编排平台可以做到真正的敏捷集成和快速发布。

2. 服务编排平台本身的所有能力又可以作为API服务对外进行能力输出，而传统的ESB却很难做的到其能力只能有限对外发布。

3. 服务编排平台一般追求更高的流程执行和调度性能所以更注重轻量级，易用等特点，而传统的ESB由于架构复杂性能往往存在瓶颈，同时显得非常笨重使用起来普遍感觉很难入门。

4. 服务编排平台更注重API服务的编排特别是微服务的API如(Restful，WebService，Dubbo，gRPC等)，而传统ESB往往会引入一大堆与微服务没有关系的功能如：FTP、SMTP、MQTT、JDBC、EXCEL、数据库链接、大文件传送等，甚至把ETL的部分功能混杂进了ESB中。

5. 服务编排平台更注重编排后服务的事务性控制能力，往往会提供最终一致性事务控制能力，断点续跑能力、故障转移等功能，同时讲究数据在运行过程中的可恢复性，而ESB在这方面显然是比较弱的。

6. 服务编排平台一般作为企业所有开发人员、子公司、第三方开发商或者最终业务人员的统一服务编排平台，而传统ESB往往是给那些企业里面的专业集成人员所使用的，因为ESB使用复杂而且有些是基于C/S架构的没有提供一个集成门户给第三方开发商或子公司的开发人员去编排。

7. 传统ESB软件往往功能做的非常复杂会把一些算法、逻辑进行混排，所以使用难度不少，而服务编排平台会把大部分逻辑放入到API中。

8. 同时传统ESB还把微服务架构中的API网关、API接口管理的能力也进行了混入，所以看看ESB是不是什么都想做（API网关，服务编排、ETL数据交换、API文档管理、文件传送），而在微服务架构中一般API网关是独立的模块， API网关就是一个独立的模块只负责数据的路由和透传追求的是性能，而服务编排平台则专门负责服务的编排追求的是快速的编排，而ETL则专门负责数据的清洗、转换和加载追求的是大批量的数据传送和清洗能力。

9. 我们有时也认为服务编排平台是一个轻量级只注重服务编排的ESB中间件产品，因为服务编排平台也与ESB产品一样具有中心化节点的架构，构建的同样是企业的服务总线。

10.传统ESB产品和服务编排平台侧重点不一样，如果企业对于文件传送、其他协议的转换没有什么特别要求可以直接使用微服务编排平台+API网关来构建企业服务总线，只需要把相关协议统一到Restful接口规范即可(把FTP功能发布为API，邮件发送发布为API等)，如果企业已经购买了ESB产品的情况下可以采取共存的方案。

从下面的图可以很清晰的看出两者的区别：