企业服务总线，即ESB全称为Enterprise Service Bus，指的是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。面向服务的体系结构已经逐渐成为IT集成的主流技术。面向服务的体系结构(service-oriented architecture，SOA)是一种软件系统设计方法，通过已经发布的和可发现的接口为终端用户应用程序或其它服务提供服务。关于SOA结构后面也会详细聊到。

较为典型的SOA定义有以下三个：

面向服务的体系结构SOA把IT架构分为组件层、Web服务层、业务流程层等。组件层包括各种应用组件，它们通常是技术相关的具体实现，各种具体的分布式组件技术(CORBA、COM/DCOM、J2EE)都可以用于实现组件层的应用组件。通常复杂的IT环境中的组件层都同时使用了多种分布式组件技术，而不同实现技术之间的互联性障碍给应用集成带来了极大的困难，进而形成了一个个信息孤岛。SOA引入了Web服务层来解决此种情况下的应用集成问题。Web服务是独立于各种分布式组件技术的，它使用标准的基于XML的服务描述语言(Web Service Description Language，WSDL)来定义和封装离散的业务功能，各种支持Web服务的分布式组件技术能够将其上的业务组件发布成Web服务并产生相应的WSDL文档，并且只需要依据WSDL描述的信息就能够调用Web服务，即WSDL所描述的业务功能。Web服务在系统集成方面得到了广泛的应用。在SOA中，需要进入系统集成环节的业务组件都被映射为Web服务，形成了Web服务层。业务流程层则处于Web服务层之上，通过对Web服务的流程编排来实现商业流程。业务流程层通过Web服务层能够调用到基于各种分布式组件技术实现的业务组件，实现了复杂IT系统环境的应用集成。

在SOA的组件层、Web服务层、业务流程层三层模型中，组件层使用具体的分布式组件技术实现业务功能，Web服务层则为组件层提供了一种技术无关的通用访问方式，屏蔽组件层具体技术之间的差异，突出业务逻辑的封装性。组件层中的业务组件和Web服务层的Web服务构成了企业IT架构的主要可重用部件，它们应该保持相对的稳定，业务流程层则通过对服务进行编排，来适应业务需求的变化。将组件层的业务组件映射为Web服务层的服务是成功实现SOA的关键步骤，目前对于特定的业务组件，业界广泛使用具体于分布式组件技术内建的支持Web服务的功能来实现组件与服务的映射。这种映射方法高度依赖于具体分布式组件技术本身，并且在使用和定制的过程中缺乏灵活性，当某个Web服务的实现需要多个分布式组件技术中的业务组件实现时，这种映射方法就会无法支持。

SOA模型如下：

单个服务结构如下：

SOA 只是一种概念和思想，需要借助于具体的技术和方法来实现它。从本质上来看， SOA 是用本地计算模型来实现一个分布式的计算应用，也有人称这种方法为“本地化设计，分布式工作”模型。CORBA、DCOM 和 EJB 等都属于这种解决方式，也就是说，SOA 最终可以基于这些标准来实现。从逻辑上和高层抽象来看，目前，实现 SOA 的方法也比较多，其中主流方式有 Web Service、企业服务总线（ESB）和服务注册表。

在一个复杂的企业计算环境中，如果服务提供者和服务请求者之间采用直接的端到端的交互，那么随着企业信息系统的增加和复杂度的提高，系统之间的关联会逐渐变得非常复杂，形成一个网状结构，这将带来昂贵的系统维护费用，同时也使得 IT 基础设施的复用变得困难重重。ESB 提供了一种基础设施，消除了服务请求者与服务提供者之间的直接连接，使得服务请求者与服务提供者之间进一步解耦。

企业服务总线(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连接框架定义了一系列构建，用于处理在集成不同系统时所涉及的通信、路由、服务交互等方面的任务。企业连接框架体系展示了使用该框架集成2个端对端的应用程序的连接方式。

支持群集物理部署来保证系统的高可用性，支持系统的长期稳定运行。

支持在达到系统性能指标峰值要求的同时，系统处理能力还能够留有足够的余量。

支持系统扩展部署和多个逻辑单元的分离部署。提供对系统的维护与参数配置的管理功能。

提供安全认证和授权机制，提供不可否认和机密性，支持安全标准。

以前的银行系统并不是很开放，存在系统之间集成的问题，无法快速对接外部场景，所以结构需要做出一些调整，建立开放生态，进而实现数据“业务化”。而银行数字化转型有以下三个最主要的特征：

快速实现以用户为中心的客户设计，意味着未来的内外部应用/服务之间的相互协作会越来越密切，包括后端业务系统、渠道系统以及外部生态之间。这要求银行能够快速进行内部服务的集成和整合，能快速对接外部场景，这样才能做到以用户体验为核心，为用户提供方便、快捷的服务。而数据驱动的迫切需求也将使银行越来越重视数据质量和数据价值，使数据“业务化”，通过数据让银行了解客户，为客户提供定制化服务，这些都是当前银行业科技发展的重要方向。正是如此，银行IT架构支撑体系有了新的能力要求：敏捷的服务集成、开放的API服务、智能的数据驱动。

关于ESB系统我们知道：ESB的最大优势在于SOA理念的落地，这实际上是从企业整体系统架构优化的角度出发，实现系统间的松耦合。即将服务系统的服务发布在ESB上提供给最终用户和其他消费者，也因此ESB被认为是纯粹的、具有通用性的技术架构，而它与传统综合前置系统最大的区别在于后者将“业务”和“技术”混杂在一起，这使得银行IT架构复杂、不清晰，牵一处而动全身；系统之间交互缺乏标准；软件复用程度低、运营和沟通成本高。企业服务总线系统的建设涉及银行服务治理，实现“业务”和“技术”的自由组合。

谈到服务集成，很多人可能会想到企业服务总线（ESB）。从单个系统来看，其内部服务之间的访问基本都是网状结构，服务与服务直接进行访问是顺畅有序的，似乎无需服务总线来支持内部服务。也许有人认为这是由于单个系统内部服务数量少，逻辑相对简单，所以网状结构没有问题。

然而，在互联网（INTERNET）上服务同样是网状结构，服务之间也是直接访问，没有人觉得在互联网上需要经过一个服务总线来避免网状结构。既然小到一个系统，大到整个互联网，服务间都是通过端到端的直接访问来实现服务集成，那为什么在企业级的IT架构规划中通过ESB实现服务集成到现在仍然被很多人认为是比较好的解决方案呢？

首先来看看ESB提出的背景：随着银行近二、三十年的发展，其IT建设从最早的一个综合业务系统开始到现在的上百个系统。随着系统数量的增加，系统间的相互访问越来越多、越来越密切，系统的建设难度和改造难度也越来越大。这就是我们经常说的牵一发而动全身，也是我们所“深恶痛绝”的网状架构的由来。

这个时候有人提出应该有个系统来解决系统间服务集成的问题，来屏蔽系统的变化对关联系统的影响，来统一管理系统间的关联关系。于是大前置及ESB就伴随着这个痛点应运而生。但为什么只有企业级架构规划中才会提出ESB的解决方案呢？其根本原因在于企业层面服务标准缺失或者滞后于IT系统建设。单个系统是由一个项目组来进行统一的设计和建设，其服务标准自然是统一的。互联网是伴随着HTTP协议问世的，其服务标准也是统一的。但银行众多IT系统的建设是各自先后完成的。

在很多年以前银行IT建设的初级阶段，银行尚没有考虑到在企业层面制定服务标准的想法。众多IT系统的服务有着各自的标准，从而导致服务间访问的难度和复杂度越来越大。由此很多银行纷纷启动并完成了ESB的建设。 2013年以来，银行业界掀起了ESB建设的高潮，包括浦发银行、汉口银行、泰隆银行、福建农信、乌鲁木齐、苏州银行、三峡银行、营口银行、邢台银行、湖北银行等先后启动了ESB项目。随着ESB技术与实施的成熟度越来越高，以及银行IT架构面临强大压力的形势，将会有更多的银行已不再守着传统的综合前置，转而向ESB抛出了橄榄枝。但其中不少完成了ESB建设的银行仍然忽视了服务标准的制定和落地，而仅仅关注在ESB的服务转接功能，认为已经从“网状架构”升级到了“总线架构”，服务集成已经不存在问题了。

实际上，如果没有服务标准或者服务标准没有落地，即使有了ESB，仅仅是把问题迁移到了ESB本身，服务集成的复杂度和难度没有真正解决。因此对于企业内部服务集成来说，ESB建设的最终目标应该是“消灭ESB”。通过ESB完成对全行各个应用系统间访问关系的梳理，根据制定的服务标准进行全面的服务治理。

通过服务治理使全行服务能够遵循统一的服务标准后，服务之间实现了便捷规范的直接访问，ESB也就失去了存在的意义。因此ESB是伴随着服务标准滞后于IT系统建设或缺乏服务标准而产生的，是“存量服务治理过程中的过渡方案”，而非银行进行服务治理的必经之路。相对于ESB，分布式微服务架构更适合银行进行服务治理，实现企业级SOA。服务集成的关键在于通过推进服务标准的全面落地，从而实现内部服务的“即插即用”。

总而言之，ESB系统目前带给银行业的价值是非常大的，是解决老旧银行系统间访问互联繁杂的不错方案，至少目前来说，ESB对于传统银行业来说是具有巨大建设意义的。

关于银行业分布式微服务的介绍，将会在后续博客中更新。