.net中调用esb_ESB企业服务总线功能，需求和核心架构分析

作者：人月神话，新浪博客同名

简介：多年SOA规划建设，私有云PaaS平台架构设计经验，长期从事一线项目实践

对于ESB企业服务总线方面，我准备近期整理几篇文章进行分享。当前虽然在微服务架构下大家讨论更多的是微服务和API网关，但是对于传统业务系统，包括传统企业在进行IT架构转型过程中，为了兼容遗留IT系统，往往仍然需要采用ESB服务总线进行集成和适配。

ESB企业服务总线核心功能概述

ESB是企业服务总线(Enterprise Service Bus)的缩写，是中间件技术与Web Service等技术结合的产物，也是SOA系统中的核心基础设施。ESB就是一个服务的中介，形成服务使用者->ESB服务Proxy->服务提供者的生物链，中介的作用在不同应用中各有不同：

解耦中介 ：客户对实际服务提供者的身份、物理位置、传输协议和接口定义都是不知道也不关心的，交互集成代码提取到了业务逻辑之外，由ESB平台进行中央的宣告式定义。ESB平台实现协议转换 (WebService，Http，JMS...)，消息转换 (转换、充实、过滤)，消息路由 (同步/异步、发布/订阅、基于内容路由、分支与聚合...)。

服务中介 ：ESB平台作为中介提供服务交互中的基础服务。ESB平台实现SLA (可靠性保证，负载均衡，流量控制，缓存，事务控制，加密传输)，服务管理监控 (异常处理，服务调用及消息数据记录，系统及服务的状态监控，ESB配置管理)，统一安全管理 (这个有点理想主义)。

服务编排 ：多个服务进行编排形成新的服务。ESB支持一个直观的形式定义新组合服务的流程(工作流、BPEL 或 代码级编排)。

从上面可以看到ESB的基本功能仍然是数据传输，消息协议转化，路由三大核心功能。有这三大核心功能也可以看到在进行异构系统的整合时候往往根据需要ESB提供这些功能。没有ESB时候也可以实现SOA，比如借助SCA和BPEL来实现SOA，当时却很难实现消息协议转化和动态路由。

ESB在发展过程中有从原有的消息中间件转化为ESB产品的，这类消息中间件和数据总线产品在原有的EAI企业应用集成中应用比较多。而SOA根据强调了基于服务的集成，以Web Service服务为基本的管理单元。一个服务的定位是关于如何把业务逻辑表现成为一组相互独立的，自描述的且能互操作的实体。

对于SOA关注的是服务全生命周期，通过服务实现业务价值。而ESB关注的是服务中介和服务的集成，是SOA的基础设施。SOA有两个核心组件，一个是ESB，一个是BPEL，而ESB是基础设施，BPEL是业务流程驱动下服务的集成和整合。离开了SOA，ESB将失去它所连接的服务，而仅仅是一个总线，同时也将变得毫无价值。

Bobby做了一个比喻：路是没有任何价值的，除非你利用它把一个东西从一个地方移到另外一个地方。而离开SOA，ESB就像一个没人使用的道路。

做SOA的事情不要先上来建立一个大而全的ESB，相反是关注你的业务问题，找到用SOA的方法来解决业务上的需求，在解决这个问题的过程当中，你会看到一系列的业务服务。这些业务服务是会产生业务价值的。它可以灵活地组装，动态地解决你变化的业务需求。这是它的价值，只有这样才能使你的业务敏捷起来，随需应变起来。而在服务的组装过程中，你再去考虑利用ESB来把他们连接起来。

ESB 需要某种形式的服务路由目录(service routing directory)来路由服务请求。然而，SOA 可能还有单独的业务服务目录(business service directory)，其最基本的形式可能是设计时服务目录，用于在组织的整个开发活动中实现服务的重用。Web 服务远景在业务服务目录和服务路由目录的角色中都放置了一个 UDDI 目录，因而使得可以动态发现和调用服务。这样的目录可以视为 ESB 的一部分；然而，在这样的解决方案变得普遍之前，业务服务目录可能与 ESB 是分离的。

标准的 ESB 功能

上面的许多功能既可以使用专有技术实现，也可以通过利用开放标准实现。然而，使用不同的技术来实现 ESB 可能会使它们的性能、可伸缩性和可靠性这些特性显著不同，同时 ESB 功能和所支持的开放标准也会有所不同。由于这些原因，再加上最近制订和正在兴起的一些相关标准，当今实现 ESB 的许多关键决策都涉及到成熟的专有技术和不成熟的开放标准之间的权衡。

支持 SOA 的最低功能的 ESB 实现

如果在前面确定的功能中只有一部分和大多数 SOA 场景相关，我们可能会问：实现 ESB 所需的一组最低功能由什么构成？为此，考虑最被普遍认同的 ESB 定义的原理：

• ESB 是一种逻辑体系结构组件，它提供与 SOA 的原则保持一致的集成基础架构。
• SOA 原则需要使用与实现无关的的接口、强调位置透明性和可互操作性的通信协议、相对粗粒度和封装可重用功能的服务定义。
• ESB 可以作为分布式的异构基础架构进行实现。
• ESB 提供了管理服务基础架构的方法和在分布式异构环境中进行操作的功能。

因此最低配置的 ESB 功能至少应该包括如下：

请注意这些最低功能并不需要使用特别的技术，比如 EAI 中间件、Web 服务、J2EE 或 XML。这些技术的使用非常接近也非常符合需求，但是不必强制要求使用它们。相反，最低功能几乎只需简单地使用 SOAP/HTTP 和 WSDL 就可以实现(当然不是所有的情况都这样)：

• URL 寻址和现有的 HTTP 和 DNS 基础架构提供了一个具有路由服务总线Bus。
• SOAP/HTTP 支持请求-响应(Request-Response)通信规范。
• HTTP 传输协议被广泛地使用。
• SOAP 和 WSDL 是开放、与实现无关的服务通信和连接模型。

然而，这些 SOAP/HTTP 和 WSDL 的基本应用只是点到点(point-to-point)的集成，并不能实现一些 ESB 需要的关键功能：

目前还没有用于控制服务寻址和命名的管理功能。服务名称通过每个适配器单独进行控制的，服务路由控制则分散在由服务客户端调用的地址、HTTP 基础架构和分配给适配器的服务名称之间。

虽然这种方法依赖于实现细节，但是它往往并不能使服务实现的替代变得简单；服务请求者代码(也可能是开发工具生成的)通常通过特定地址 的特定协议直接绑定到具体的服务提供者实现。如果想要用另一个服务实现来替代原来的服务实现，就需要修改应用程序代码并重新部署这些代码。

当然，在许多甚至是大多数情形中往往需要其他的功能，并且这种需要变得越来越常见。特别地，不管是现在还是以后，下面的需求类型可能会导致更复杂高级的技术的使用：

• 服务质量和服务级别功能。
• 高级 SOA 概念，例如服务编排、目录、转换等等。
• 按需操作环境需求，比如管理与自治功能以及基础架构智能功能。
• 跨越具有不同所有权的多个网络、多个协议以及多个域的真正意义上的异步操作。

当前API网关和OpenAPI平台和传统ESB对比

简单来说API网关就是将所有的微服务提供的API接口服务能力全部汇聚进来，统一接入进行管理，也正是通过统一拦截，就可以通过网关实现对API接口的安全，日志，限流熔断等共性需求。如果再简单说下，通过网关实现了几个关键能力。

• 内部的微服务对外部访问来说位置透明，外部应用只需和网关交互
• 统一拦截接口服务，实现安全，日志，限流熔断等需求

从这里，我们就可以看到API网关和传统架构里面的ESB总线是类似的，这些关键能力本身也是ESB服务总线的能力，但是ESB服务总线由于要考虑遗留系统的接入，因此增加了：

• 大量适配器实现对遗留系统的遗留接口适配，多协议转换能力
• 进行数据的复制映射，路由等能力

对于两者，我原来做过一个简单的对比，大家可以参考。

ESB总线的功能需求分析

关于ESB总线的功能需求，在这里仅仅对核心功能需求进行整理如下：

服务目录和元数据管理

ESB总线平台管控应该提供完整的服务目录库，可以通过多个维度对服务目录进行浏览和查询，同时ESB服务总线需要通过数据存储对服务元数据、配置、策略进行统一管理，对于每次服务调用均需要产生服务实例日志信息。对于服务元数据本身包括了服务的编码，名称，类型，版本等基础信息，同时也包括了服务消息输入和消息输出的详细格式信息。

服务注册和服务接入

通过服务接入功能，将服务提供方系统开发的服务接入到服务总线上并发布出来，供其它业务系统调用，服务接入也即服务注册和服务封装功能，需要提供简单易用的服务接入操作功能界面，支持手工接入，也支持批量一键接入。

动态路由和静态路由

系统需要提供服务动态路或静态路由功能，对于静态路由主要是可以配置和定义静态路由表，服务消费基于路由表进行路由。对于动态路由即可以灵活的配置基于服务消费时候的消息输入参数进行动态的服务路由。

消息传输

需提供消息传输的基本功能：服务使用方先调用注册发布在服务共享平台上的服务并以消息形式传入服务调用请求，平台将接收到的调用请求转发给服务提供方，服务提供方完成操作后先将服务响应消息传递给平台，再由平台将服务响应转发给服务使用方，整个过程都是通过消息进行传输。

异步分发和消息发布订阅

在实际业务场景中，经常出现“一对多”的情况，ESB平台需要支持异步分发功能，只需在平台中配置异步分发服务，即可实现异步分发功能。同时也支持1对多的消息发布订阅功能。

协议和消息转换

对于已经上线稳定运行的重要功能，这些功能使用的数据交换协议可能有很多种，需解决不同的协议的对接，服务共享平台必须支持协议转换功能，服务共享平台需支持在大部分标准协议间进行转换，包括JMS、HTTP(S)、TCP、FTP、POP3/SMTP等。

为了统一控制及更好地进行日志管理，服务共享平台需要为每一次交易产生的日志编号，需要在消息流中插入一个唯一编号，此时需要用到消息转换功能。因此服务共享平台需要提供消息转换能力，支持在消息传输过程中对消息进行操纵及转换，包括消息元素新增、替换及删除。

遗留系统适配器

各业务系统开发的服务需要接入并发布到服务共享平台上，采用的技术可能是Webservice、HTTP、HTTPS、FTP等，服务共享平台必须提供各种标准适配器，能够将按业界开放标准开发的服务注册到平台上。所以平台必须提供各种标准适配器，可以将按照标准协议开发的服务适配接入到平台上，其中包括了数据库，FTP，MQ，JMS，大数据，平面文件，商用ERP套件等各种适配器。

服务请求过滤及流量控制

服务共享平台需要支持按预定义的规则对服务调用请求进行过滤，对于未允许使用服务的调用请求可以过滤，从而保证服务数据安全；平台还需要支持对服务进行流量控制，支持对服务分配流程配额，对于超出流量配额的调用进行限制，从而避免某些大流量调用影响整个平台。

开发工具及语言支持

服务共享平台必须支持cxf、axis、python soapbox、xfire、.net等服务开发框架、工具及语言，只需根据预先定义的服务契约进行开发，即可顺利接入平台。

服务监控和运行统计

服务共享平台必须支持服务监控，可以方便地监控到服务状态，通过详细的输入输出日志，可以快速定位到运行异常服务原因。服务运行统计包括了服务运行次数，运行时长，运行并发量，运行异常错误等多维度的服务运行统计数据信息。

ESB总线核心架构分析

基于对开源ESB产品的研究，以及对Oracle和Tibco的ESB总线产品的实施经验积累，对ESB总线的核心产品架构有了进一步的清晰认识，将ESB的核心架构整理为上图，上图中看到的内容也是作为一款完整的ESB服务总线产品所必须要具备的功能。

首先整个架构体系里面分为三个组件或子系统，即偏开发态的设计器，偏运行态的ESB核心引擎和SOA治理管控平台三个方面的内容。以上三者组合和集成形成一款完整的ESB服务总线产品。对于三者之间的关系可以简单的描述为：

ESB总线引擎和服务运行环境

首先对于ESB总线引擎是一个完全相对独立的内容，即常说的ESB的Server端，一个完整的ESB引擎一般都会集成消息中间件的能力。类似ServiceMix的ESB可以看到核心是基于OSGI运行框架下的ActiveMQ+CXF组件来实现基础核心功能。没有设计器和管控平台，引擎也可以独立部署和运行，即可以自己写代码或写配置文件，将开发好的服务包部署到ESB引擎环境里面。

一个ESB引擎本身也需要部署在application server里面，即引擎可以部署在类似weblogic,jboss或tomcat等各种中间件容器中。而对于很多开源的ESB可以看到引擎本身已经集成了更加轻量的Jetty作为服务运行容器。对于单独的引擎应该是不需要DB数据库的，即ESB服务运行的log日志审计可以存储在服务端的log日志文件中，只有当安装了管控平台后，我们可以在server上部署代理，准实时的将运行日志信息采集和存储或db数据库。

ESB设计器和服务开发环境

其次是ESB设计器，设计器是属于开发和设计态的一个内容，重点则是对http，rest，已经服务+DB，消息等各种内容进行集成。当前类似talend和mule等都提供了很强大的服务设计器能力。即我们常说的服务代理，http和soap服务集成，数据库适配，路由，消息集成和适配，分支和条件判断，异常处理，任务作业，组合服务等都是设计器需要支撑的核心能力。

设计器设计完成后的内容可以导出为部署包，对于部署包则可以部署到ESB服务引擎中。当前的做法主要有两种，一种是在设计器中本身就提供连接到服务器进行远程和自动部署的能力，另外一种做法则是在SOA管控平台里面提供服务部署和管控的能力。

设计器往往是给服务开发和设计人员使用，目的是为了简化服务的开发和封装，提升开发效率，一个开放的架构模式最好的方式就是脱离了设计器仍然可以通过其他手工方式进行服务的开发和封装，而不是被设计器绑定。而对于设计器本身的输出，一种是转化为了普通的java代码，还有一种方式是设计器的输出为xml配置文件。可以看到对于xml配置文件这种方式更加方便和解耦，在设计器产生部署包或测试运行的时候，设计器端首先是读取xml配置文件的内容再动态生成和部署服务。

SOA管理治理-覆盖SOA全生命周期

最后一个内容是SOA管控平台，主要的作用是实现服务的全生命周期管理，包括服务的元数据管理，服务目录库，服务的申请，服务的开通和鉴权，服务运行日志审计和监控，服务运行分析，服务预警，服务SLA等各种功能。即SOA管控平台提升了对ESB引擎本身的管控和治理能力。

管控平台本身也是相对独立的内容，可以看到对于管控平台和ESB引擎本身是彻底解耦的，即如果实施了管控平台，则只需要在ESB引擎上启动管控代理和相关的配置参数，在这种模式下ESB引擎本身运行态的运行信息即可以准实时的采集到管控平台中进行存储和统计分析。

当然，对于管控平台产品的服务权限管控，服务动态路由设置，服务流量控制等内容，也会影响到ESB引擎在运行态的运行。而通常ESB总线的做法则是对于log日志，安全，流量控制等都是ESB总线的inbound和outbound上的可插拔式的拦截器，通过这种组件动态装载和配置启用的模式来彻底实现管控平台和ESB引擎的解耦。

对于ESB总线产品本身也应该是符合SOA架构的，即需要实现组件化和服务化，实现服务组件本身的动态加载和热部署，当前类似servicemix在这点上的做法是值得借鉴的，即基于karaf+osgi模式来实现一个组件化的运行框架和环境，极大的方便后了整个运行态的动态管控能力。

---

欢迎关注@人月聊IT 分享SOA，微服务，DevOps平台规划和建设。