精华内容
下载资源
问答
  • 企业服务总线

    千次阅读 2015-07-01 13:07:44
    - 使用者如何快速而可靠地调用服务,而网络实际上很慢且不可靠对于这两个问题,有一个相当简单的答案,即采用称为企业服务总线 (ESB) 的方法。ESB 处理使用者和提供者之间的所有复杂问题,从而使得服务调用对于两者...

    why使用esb(Enterprise Service Bus)

    SOA 模型:服务使用者调用服务提供者出现的问题:
    - 使用者如何找到它需要调用的服务的提供者
    - 使用者如何快速而可靠地调用服务,而网络实际上很慢且不可靠

    对于这两个问题,有一个相当简单的答案,即采用称为企业服务总线 (ESB) 的方法。ESB 处理使用者和提供者之间的所有复杂问题,从而使得服务调用对于两者都比较简单。ESB 不仅使应用程序(或其各个部分)可以更加容易地调用服务,而且还帮助它们转换数据和广播事件通知。ESB 的设计体现了许多已为大家接受的设计模式和标准规范。

    调用服务

    调用服务的通信选择:同步或异步
    同步与异步调用
    使用者可以同步或异步实现服务调用。从使用者的观点来看,这两种方式的不同之处在于:
    同步——使用者通过单个线程调用服务;该线程发送请求,在服务运行时阻塞,并且等待响应。

    如果使用者在服务运行的过程中阻塞时崩溃了,当它重新启动时,将无法重新连接到正在进行的调用,所以响应丢失了。使用者必须重复调用过程,并且期望这次不会崩溃。

    异步——使用者通过两个线程调用服务;一个线程发送请求,而另一个单独的线程接收响应。

    如果使用者在发送了请求之后等待响应时崩溃了,当它重新启动时,可以继续等待响应,所以响应不会丢失。

    崩溃恢复不是同步和异步调用之间的唯一不同,但是如果您尝试确定某个调用采用哪一种方式,请考虑每一种调用如何处理崩溃恢复,这通常可以给您一个很好的答案。

    同步直接调用

    考虑一个简单的用于获取股票报价的 Web 服务:使用者传入股票代号,然后取回股票的当前价格。此服务可能由多个不同的代理公司提供,每个公司都有一个不同的 Internet URL。获取 Web 服务的 URL 是一个先有鸡还是先有蛋的问题。如果使用者知道端点的位置,它就可以询问服务其地址是什么,但是使用者需要知道地址才能询问地址。

    为了解决这个问题,统一描述、发现和集成(Universal Description Discovery and Integration,UDDI)描述了一种 Web 服务,它是一个类似于电话簿的目录,用于查找其他的 Web 服务。其思想就是,将 UDDI 部署到一个使用者已经知道的知名地址,然后使用者就可以使用 UDDI 来查找其他的 Web 服务。
    对于股票报价服务,使用者知道 UDDI 服务的地址,而 UDDI 服务又知道股票报价服务的地址
    同步直接服务调用 Web 服务:
    这里写图片描述
    这里写图片描述

    同步代理调用

    直接调用方法的不足之处在于,使用者必须知道提供者的端点的 URI 才能调用服务。它使用 UDDI 作为查找 URI 的目录。如果提供者更改其端点的 URI,它必须向 UDDI 服务器注册,这样 UDDI 就有新的 URI,然后使用者必须重新查询 UDDI 以获得新的 URI。事实上,这意味着每次使用者需要调用服务时,它都必须查询 UDDI 以找到端点 URI,并从中进行选择。这导致使用者把许多时间浪费在重复查找 UDDI 和选择提供者这样的工作上。这种方法还使得使用者必须以某种方式从看起来不可区分的列表中选择提供者。

    同步企业服务总线
    这里写图片描述
    同步代理服务调用:
    这里写图片描述
    代理的地址是稳定的,所以使用者不必重复地查询 UDDI,每个服务调用只需查询一次。更确切地说,使用者只需查询 UDDI 一次,然后就可以安全地缓存代理的地址,并且重复地使用它来调用服务。这大大地降低了调用服务的开销。

    异步代理调用

    同步方法的不足之处在于,在执行服务时使用者必须阻塞——在服务运行时线程必须阻塞。如果服务花很长时间执行,使用者可能会在接收到响应之前放弃。当使用者发出请求时,如果没有一个服务提供者正在运行或者它们都过载,则使用者将无法等待。如上所述,如果使用者在阻塞时崩溃,则即使它重新启动,响应也会丢失,因而必须重新进行调用。

    调用服务的时候如果发生阻塞,调用者无法接收到返回值会一直等待,解决方法就是使用者可以使用一个线程来发送请求,而使用另一个线程来接收响应。

    异步企业服务总线:
    这里写图片描述
    这里写图片描述

    使用者以请求队列中的消息的形式发送 SOAP 请求
    提供者接收到消息之后再以应答队列中的消息的形式发送 SOAP 响应

    消息总线

    异步企业服务总线的基础是已为大家接受的模式,称为消息总线 (Message Bus),如参考资料中列出的 Enterprise Integration Patterns 一书所述。消息总线是消息通道(也称为队列或主题)的集合,通常配置为请求-应答通道对。每一对都表示使用者可以通过总线调用的服务。调用方将请求消息放在服务的请求队列中,然后(异步)侦听应答队列中的结果。(调用方知道哪个结果对于特定的请求是正确的,因为它有正确的关联标识符。)

    展开全文
  • ESB企业服务总线解决方案
  • ESB企业服务总线

    2020-03-25 14:24:15
    所有的企业服务都挂接到该总线上对外公布,企业服务总线负责管理服务目录,解析服务请求者的请求、消息格式,并对服务提供者进行寻址,转发服务请求。它就是服务的请求者和服务的提供者之间的一个中间件,就是对服务...

    ESB(Enterprise Service Bus)是一种消息和服务集成的中间件平台,是一个集中式的服务总线。它类似于计算机中的总线,通过总线将各种硬件连接到一起。

    所有的企业服务都挂接到该总线上对外公布,企业服务总线负责管理服务目录,解析服务请求者的请求、消息格式,并对服务提供者进行寻址,转发服务请求。它就是服务的请求者和服务的提供者之间的一个中间件,就是对服务使用者屏蔽服务提供方的技术实现方式。如果没有这个总线,那么服务的请求者则必须自己知道它所需要的服务的地址,并要知道相应的服务调用方法,消息格式,这样的调用是点到点的,不利于服务的统一管理,不利于不同格式的服务的集成。


    ESB可以说是搭建SOA架构所必须实现的核心功能组件。它的主要功能和职责是服务注册,消息解析,验证,服务路由转换,请求的传递,服务目录管理。ESB使用SOAP消息格式,支持HTTP(S)、JMS、MQ、FTP、SMTP等传输协议。

    应用可以调用ESB服务,也可向ESB注册服务供其他应用使用

    ESBæ»çº¿åè½åå¼æ¾å¹³å°

    Open API即开放平台。所谓开放API是网站的服务商将自己的网站服务封装成一系列API开放出去,供第三方开发者使用 

    对于企业内部的服务,往往由于服务接口对需求规范要求严格,往往有会采用SOAP WebService方式来实现完整的服务契约设计。即服务接口本身就对服务的调用规范进行了强约束。
    而对于开放平台往往采用http协议,传输的对象也 是大的json串,对于json串格式的定义往往只有通过文档约定

    https://www.open-open.com/lib/view/open1450271370485.html

    展开全文
  • 企业服务总线ESB是什么

    万次阅读 2018-01-17 18:25:14
    在探讨信息系统的SOA架构概念时,一个非常重要的概念是:企业服务总线(ESB)。可以说,企业服务总线也是SOA的核心构成部分。要真正实现应用架构完善的SOA结构,简化SOA构件间的关系,就一定要建设好信息系统的企业级...

     在探讨信息系统的SOA架构概念时,一个非常重要的概念是:企业服务总线(ESB)。可以说,企业服务总线也是SOA的核心构成部分。要真正实现应用架构完善的SOA结构,简化SOA构件间的关系,就一定要建设好信息系统的企业级服务总线。

      一、ESB企业服务总线的概念

      二、建立银行的企业服务总线

      三、银行服务总线的标准功能

      四、企业服务总线的架构

      一、ESB企业服务总线的概念

      (一)总线的概念

      在世界的各种类事物里,总需要相互联系和沟通。这些事物包括人与人之间,组织与组织之间,物理设备之间,应用程序与应用程序之间。

      在没有总线的概念前,这些联系与沟通是自然发展建立起来的,一开始通常都呈现为点对点模式:

      点对点的连接方式在连接对象比较少的时候,确实是一种简单和高效的连接方式。但其最大的问题是,当连接对象多的时候,连接路径会以指数方式剧增。连接路径数与连接对象数之间的关系是:

      具体数字看下表:

      可见,点对点的连接方式有以下明显的缺陷:

      如果连接对象比较多,连接路径会非常多。连接拓扑图是一个复杂的多对多的网状结构。

      如果连接对象各自的连接方式有差异,如:对于程序的连接,如果沟通的语言、文字、格式、方法等有差异,则每一个连接方都要同时支持和维护多种连接方式。

      当某一个连接对象的连接方式发生变化,会引起其他所有与之连接的连接方有所变化。

      基于以上几点,在多点互连的情况下,点对点连接方式成本高,可用性和可维护性低。显然不是一个好的连接方式。

      随着技术的发展,另外一种连接方式开始逐步取代点对点的连接方式。这就是总线连接方式:

      与点对点连接方式最大的区别是,总线连接方式把多对多的连接方式变成一对一的方式。所有连接方均与总线连接,然后通过总线再连接到需要连接的对方。这样,无论连接对象有多少,其连接路径数与连接方的数量永远一样。整个连接拓扑图是一个简单的星形结构。

      不同连接对象如果连接方式有差异,可以通过总线完全屏蔽掉,做到对连接对象透明,无需各个连接对象关心。

      总线的连接方式最早在许多硬件设计上得到广泛的使用。如处理芯片数据总线,网络节点的交换机,大型计算机系统处理器与外围存储设备连接的集线器等。通过总线结构,把原来复杂的网状结构变成简单的星形结构,极大提高了硬件的可靠性和可用性。

      (二)服务总线

      随着计算机信息系统的发展,信息系统也越来越庞大、越来越复杂。总线的概念也引入到信息系统的架构建设上。跟随SOA的概念,信息系统的总线通常叫服务总线。其战略层的总线称之为企业服务总线(ESB)。

      关于企业服务总线的概念,业界有许多定义,但一些基本定义是一致的,归纳如下:

      企业服务总线是一个具有标准接口、实现了互连、通信、服务路由,支持实现SOA(Service Oriented Architecture,面向服务架构)的企业级信息系统基础平台。它提供消息驱动、事件驱动和文本导向的处理模式,支持基于内容的服务路由。SOA架构将各应用服务器(包括异构的服务器)上的各种服务连接到服务总线上,支持分布式的存储及分布式的处理、异步处理。为信息系统的真正松耦合提供了架构保障。简化了企业整个信息系统的复杂性,提高了信息系统架构的灵活性,降低企业内部信息共享的成本。

      (三)企业服务总线的功能

      通常认为,企业级服务总线需要具备如下功能:

      1、 服务统一管理

      为整个系统提供一个统一的、标准的、可靠的、可扩展的服务管理平台。

      2、集成服务

      提供基础的服务与定制的服务;支持集成服务模式;支持服务的分解,服务调度和路由,服务封装,服务组合。

      3、公用服务

      提供内置的各种公用服务。例如,认证服务,日志服务等。

      一些厂家提供的企业服务总线产品,还会包括如下一些功能:

      4、服务协议转换

      通过把不同的通信协议转换成标准的报文,屏蔽异构系统的底层技术差异。

      5、服务监控

      提供服务等级管理及流量管理。提供多角度的服务实时监控、报警与交易分析报表。

      6、安全体系

      提供多种安全机制并支持和第三方安全系统的有效集成,提供有效的安全监控机制。

      (四)ESB产品

      企业服务总线是一个相对新的概念,其产品也是一些较新的产品。从目前的应用案例看,能称得上成熟、完善、通用、成功的案例不多。不同的企业服务总线产品,其功能会有所侧重,使用环境也会有所限定。据了解,目前有如下定位为企业服务总线的产品:

      1、IBM

      IBM的相关产品有:WESB、WMB、WDP。

      2、Oracle

      Oracle的相关产品有:OSB、ESB。

      3、Microsoft

      微软的ESB功能是通过一组产品实现。包括BizTalk、.Net等。

      4、开源

      还有一些开源产品,如:Jboss ESB、Mule ESB、ServiceMix/FUSE ESB、Synapse/WSO2 ESB等。

      Jboss ESB架构图

      二、建立银行的企业服务总线

      企业服务总线无论在概念上还是在产品上,到目前为止,还处在成熟阶段。还没有普遍成功的案例。但金融信息系统的发展,切实需要我们实践这个概念。我们可以外购某个相对成熟的产品,通过大量的客户化形成自己的企业服务总线。另外,从发展新一代信息系统的角度,我们可以探讨如何建设自己的企业服务总线。

      假设,我们的事务处理应用系统有两大部分:渠道系统和业务处理系统。渠道系统又有两大类:柜台终端和自助终端,各自有自己的前置服务器。业务系统分为三大系统:个人系统、卡系统、法人系统,各自也是配置在不同的服务器上。每一类渠道都可以访问任一个业务系统,三个业务系统间也会有业务关联。在没有建立总线结构时,它们之间的逻辑连接如下图:

      从图-3可以看出,我们的应用系统被划分为两个层次:渠道层与业务处理层,分别用两个方框来表示。这两层共包含了五个子系统,分别用五个圆圈来表示。这种架构就是前面所说的点对点连接的架构。关系复杂且维护成本高。根据服务总线的概念,我们需要将其改造成为总线架构如下图:

      从图-4可见,应用系统在渠道层与业务处理层中增加了一层、被划分为三层。这一层就是为了实现服务总线而划分出来的。

      从服务总线的定义可知,服务总线承担的功能比较多。在服务总线里,我们可以把相关功能再进行细分。例如把企业服务总线功能中的一些辅助功能如:服务协议转换、服务认证、服务等级管理、服务流量管理等功能分拆到渠道整合去。功能进一步分拆后的服务总线如下图(图-5):

      从图-5可以看出,此时的服务总线包含了两部分,一部分是与各不同的渠道连接,接受各种各样的服务申请。另一部分与业务处理连接,根据接收到的服务申请,进行服务交付。

      从图-3变换成图-5,表面上好像变化不大,但从概念上说,是有了一个质的变化。

      从宏观上,我们把面对过程的计算机处理变成面向服务的计算机处理。图-5中的每一个圆圈,代表的是一种服务,其软件构成是一个服务构件。其中包括了:

      柜台渠道服务

      自助渠道服务

      渠道整合服务

      服务交付服务

      个人业务服务

      卡业务服务

      法人业务服务

      所有这些服务,他们之间的关系是服务申请方和服务提供方的关系。每一个服务构件,一方面接受处于服务流程上游的服务构件的服务申请,为其服务;另一方面,可以向处于服务流程下游的服务构件提出服务申请,要求其为自己服务。

      以上几个构件构成整个应用系统的几大应用板块层次:

      渠道层

      渠道整合层

      服务交付层

      业务处理层

      其中,作为企业服务总线的渠道整合与服务交付,一个对外、一个对内,实现服务总线的一系列功能。在应用系统架构划分时,可以将其划分为同一个层次,也可以把渠道整合与渠道划分为同一个层次。

      在企业服务总线的具体设计上,要注意以下几点:

      (一)渠道整合

      从总线的概念看,渠道整合应该是服务总线的一部分。建立渠道整合服务层,有几个作用。一是如上所述,把一些属于服务总线的辅助功能从服务交付构件剥离,使服务交付构件功能更为单一。二是屏蔽各种各样渠道的物理差异,使服务交付构件仅面对一个服务对象。第三点是最重要的一点,把从各渠道传递上来的服务申请信息,转换成标准的有限的服务要求信息。

      (二)标准服务接口

      从服务总线的概念可知,服务总线提供的是一种统一和标准的服务管理。为了能够做到这一点,服务交付层应该使用统一和标准的协议和报文。

      图-5中红色的连线,使用的就是标准的协议和报文。

      三、银行服务总线的标准功能

      银行信息系统的企业级服务总线只提供有关客户服务的管理功能,如:服务分析、服务分拆、服务转发、服务流程控制、服务路由控制、服务结果返回等,不提供客户服务本身的服务功能。也就是说,所有业务功能全部交给其他业务处理服务去实现。

      1、服务分析

      通常,应用系统的客户通过应用系统的各种人机交互界面,向应用系统提交服务要求。该服务要求通过系统的各种渠道送到系统的渠道整合层。渠道整合层把客户各种各样的服务要求整合为标准的服务申请报文,送到服务交付层。这些标准报文的头部通常都有相应的服务交易代码或功能代码。服务交付层通过对交易代码的分析,就能知道本服务申请的具体服务要求。

      2、服务分拆与转发

      服务交付层知道了客户服务要求的具体内容后,要把服务交给后面的具体服务构件去完成具体的服务。客户服务的构成有许多类型,有简单的服务,有复杂的服务。所谓简单服务,就是一个服务构件就能完成的服务。对于这种服务,服务交付层直接把服务要求转给相应的服务构件去完成。但对于大多数的服务要求,都不是简单服务,其服务需要通过若干个服务构件甚至一些系统外的信息系统共同服务才能完成。这时,服务交付层要把一个客户服务要求拆分为若干个子服务。把子服务有序地分别转发给相应的服务构件去完成。

      3、服务流程控制

      对于复杂服务,一方面,服务交付层要把服务分解成若干个子服务,要按一定的顺序,把这些子服务交给相应的服务构件。由于各子服务之间通常有一定的因果关系。前一个服务的输出往往是下一个服务的输入,所以,服务总线通常还要把上一流程的某些处理结果打包给下一流程。

      另一方面,服务交付层还要控制整个服务流程的走向。因为复杂服务流程比较长,每一个服务环节都会出现一些影响后续服务流程的结果。这些结果包括一些正常的流程选择条件和非正常事件。对于流程选择条件,服务总线根据不同的条件选择不同的流程,让服务正常持续下去。而对于出现的非正常事件,服务流程将不能正常完成。这些事件有些是由于提交的服务要求没有完全符合业务规则,如密码不符或余额不足等;另外也可能是环境的原因,如网络问题等。当某一个服务环节出了意外,整个服务流程也许不能完整走下去。需要转到另外的错误处理流程。

      4、服务路由控制

      服务交付层要把各子服务转发给各服务构件,要知道服务构件的物理位置。根据SOA松耦合的概念,松耦合既包含了软件模块之间的松耦合,还包含了软件与硬件之间、与地理位置的松耦合。应用系统的架构不强求规定哪一项服务配置在哪种机器里,也不强求规定该机器是在本地还是在远程。服务交付层通过解析服务配置表,找到相应构件的名称和位置,把子服务转发给该服务构件。

      5、服务结果打包与最终返回

      除了服务转换间的信息打包外,当所有的子服务返回的结果均为正确时,服务交付层把服务最终结果整理打包返回渠道整合层。相反,只要有某个子服务出现意外,服务交付层马上中断正常的服务流程,根据不同的意外情况,向渠道整合层返回不同的错误代码。

      四、企业服务总线的架构

      (一)宏观架构

      如上所述,建立了上述的服务总线后,解决了信息系统各应用大板块之间的松耦合,实现了宏观的总线架构。下一步,总线结构还可以在大板块内进一步展开。

      随着我们信息系统的各业务处理系统不断发展,其处理不光覆盖了核心银行业务,还包括了客户管理业务、代理业务、内部管理业务等。所有这些业务可以分类组成若干个大的业务板块。其中有一些板块,不光里头包含了许多业务。且板块内部的各种业务相互间关系比较密切,与板块外部业务的关系相对松散。对于这些大的业务板块,如核心银行板块,我们可以在板块内建立总线结构:

      在图-6里,对于核心银行应用,与图-5相比,服务交付由一层变为两层:服务交付与核心银行交付。这种变化,对于包括核心银行里原来的各个服务以及其他所有服务来说,完全是透明的。假设有一个客户服务是代发工资。在图-5的服务交付对应配置表里,配置了两个子服务,先是法人系统的工资转出服务,下一个是个人系统的工资转入服务。但在图-6里,服务交付对应配置表里只配置了一个核心银行服务,先把服务转发给核心银行交付。而在核心银行交付的对应配置表里,配置了两个子服务:法人、个人服务。从这个例子,可以看出服务总线的灵活与方便。

      在图-6里,从概念来说,渠道整合、服务交付以及各板块的交付合在一起,构成整个企业级服务总线。但在物理配置上,各业务板块的服务交付应该靠近各业务板块,或者与各业务板块配置在同一个服务器里。因为在板块内设置服务交付的前提是我们认为该板块内的各种应用是关系密切的,它们之间会有比较多的交互。把板块的服务交付配置在板块内,可以提高效率,减少开销。当然,如果板块内部的应用关系并不密切,我们就未必需要要设置两层的交付。

      多层的服务总线架构与多层的网络架构概念完全一样。众所周知,比较大的网络体系通常会采取三层架构:核心层、汇聚层、接入层,各层通过其节点交换机:核心交换机、汇聚交换机、接入交换机完成多层的数据传递与交换。相对于银行信息系统,如果采取两层的服务总线结构,服务交付相当于核心交换机;核心银行服务交付相当于接入交换机。通过系统的两层总线,完成服务的交付与流程的控制。

      (二)服务交付层的内部架构

      服务交付层的基本架构是由一组结构大致相同的程序组成。这一组程序我们可以把它称之为服务交易引擎。其中每一个程序通常对应一类客户服务,对应一类交易。并对应与该类服务相关的一组子服务、一组程序。而每一组流程相似的交易通常对应一个标准报文。

      服务交付层还有一组与交易相对应的配置表。配置表的内容有完成该交易所需要的各子服务名、子服务物理路由、子服务后续流程条件码、条件码对应后续服务等信息。交易引擎就是通过检索配置表,解释其中内容,以确定交易的具体服务内容。并确定服务构件名、服务构件路由、服务流程、服务返回内容等。

      通过建立完善的企业服务总线,整个信息系统形成一个以服务总线为中心、逐层往外扩展的的星型网络。分散的渠道把各种服务要求分层汇集到渠道整合,服务交付又分层地把服务分解为各子服务,再分发到各个具体的应用,然后汇集各个子服务的处理结果,原路返回服务的提交处。

      ESB注册试用

      LinkESB由厦门明延科技研发,公司十年专注企业服务总线, 我们致力于打造企业共享服务平台提供商,打造企业上下游的生态圈。传统的企业信息化都是围绕内部人员展开,是一个封闭的系统,而未来的企业信息化,不仅服务企业内部,还要保证上下游企业互联互通,同时客户通过手机可以及时查到到业务的进展。我们的解决方案

      1. 业务上以用户为中心

      2. 技术上以服务为中心

      3. 决策上以数据为中心

      解决方案图

      LinkESB自2007年经过多年的行业沉淀,研发了国内外先进的企业服务平台套件,先后应用于海南省电信、海航集团、厦门国际银行、厦门建发股份、夏商集团等大型企业的IT建设中,以及评众联与坤龙云海等全国性的行业互联网平台的应用。综合对比国内外ESB产商,厦门明延科技的LinkESB在各种行业项目中应用最为广泛,值得依赖!

      你是不是万事具备,就差一个程序员了?

      错!

      你其实差的是一整套解决方案

      了解LinkESB企业服务总线请联系我们,我们拥有全套互联网平台建设经验:平台规划+技术服务架构+开发平台+实施方案+运营思路。

      打开LinkESB网站,一分钟注册开发者账号开始试用吧!



    http://news.chinabyte.com/480/14198980.shtml


    展开全文
  • ESB 企业服务总线

    万次阅读 2013-08-24 10:36:41
    整理的OSChina 第 38 期高手问答 —— ESB 企业服务总线,嘉宾为@肖俊_David 。 @肖俊_David 恒拓开源架构师,热衷于JAVA开发,有多年的企业级开发经验。曾参和设计和开发基于FuseESB 企业级服务总线系统,对...

    整理的OSChina 第 38 期高手问答 —— ESB 企业服务总线,嘉宾为@肖俊_David 。

    @肖俊_David 恒拓开源架构师,热衷于JAVA开发,有多年的企业级开发经验。曾参和设计和开发基于FuseESB 企业级服务总线系统,对FuseESB企业级服务总线以及内嵌的Camel/ActiveMQ 有深刻的理解。

    ESB 全称为Enterprise Service Bus,即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。ESB的出现改变了传统的软件架构,可以提供比传统中间件产品更为廉价的解决方案,同时它还可以消除不同应用之间的技术差异,让不同的应用服务器协调运作,实现了不同服务之间的通信与整合。从功能上看,ESB提供了事件驱动和文档导向的处理模式,以及分布式的运行管理机制,它支持基于内容的路由和过滤,具备了复杂数据的传输能力,并可以提供一系列的标准接口。

    ESB 相关的开源软件:http://www.oschina.net/project/tag/333/esb

    主要有价值的问题整理如下:

    1、先简单介绍下 ESB 的应用场景吧,相信很多人还是不太了解 。

    肖:一般用在企业内部业务系统比较多,相互之间调用比较复杂,接口的维护花费比较大,并且不同的系统采用了不同的开发平台、传输协议、数据格式等,这种情况下就需要考虑使用ESB了 。

    2、这么庞大的一个系统,设计时候遇到的难题及解决方法是什么?在系统性能上从那些方面优化?

    肖:主要体现在各业务系统数据的整合/ESB路由的安全/流量控制等方面。 性能方面是这些方面的优化:负载均衡/应用服务器集群/缓存/数据库的读写分离/Restful WS/WS接口数据的压缩/消息的异步传输/。具体可以参考此文档http://www.oschina.net/doc/593。

    3、对于大并发的实时交易的系统,选用ESB作为数据总线,其性能如何?在线人数100万,并发1000左右的交易,基于WS与ESB进行对接,中间不介入MQ 。

    肖:根据我们对Fuse ESB的性能测试情况,直接访问WS与通过ESB来访问WS,性能影响不大,当然具体的性能损耗,还与你采用的ESB产品有关!我们目前做的项目,部署了两台ESB,前面通过LVS做负载均衡,调用WS的TPS可以达到 600-800左右。

    4、ESB的具体应用及其担任的角色是什么呢?

    肖:中介、路由转发、格式转换、协议转换、安全控制。

    追问:您好,针对于您说的路由转发,可否再阐述下,

    肖:就是说路由转发的机制,可以是业务人员定义的,由业务人员来定制转发的流程。

    5、ActiveMQ 比较适合哪些企业应用场景?能否举个例子简单说明下,体现使用了ActiveMQ的价值。

    肖:ActiveMQ主要优势体现在消息的异步/推送上, 提供了多种语言的客户端。它可以用于异构系统的整合,如我需要向其它系统推送一个消息,只需要把消息发送到MQ服务器,便可以去做其它事情,MQ服务器来保证其它系统数据的接收;另外,系统包含大量的业务日志数据,也可以考虑使用MQ来异步处理。

    追问:MQ服务器一般采取哪些部署方案呢?对于处理大量业务日志,单台MQ服务器是否足够?

    肖:看机器性能, 我这边性能测试 4核/4G内存/linux,MQ的收发大概可以到5000条/秒。如果有高可用的需求,需要做MQ集群。

    追问:你是说先把日志内容发给MQ,再由MQ发送给日志系统? 

    肖:是的。

    6.请问实际的安全问题是怎么处理的,给点思路,谢谢。

    肖:在ESB的路由程序中,加入安全认证机制。如用户名/密码认证,访问控制认证等。MQ的安全认证,可以通过安全插件来实现。

    追问:谢谢哈,那我还想了解下路由程序的大概作用,是不是就是处理请求,使其匹配业务逻辑的那种? 

    肖:具体可以参考此文档,第二个案例 http://www.oschina.net/doc/593 。

    7.能不能介绍下现在主流的esb产品. 包括商业和开源的?

    能不能重点介绍下fuse产品,要是直接部署使用的话,有什么要注意的. 

    fuse好像是基于osgi的.话说osgi好像比较难搞呀.

    个人能不能提供咨询服务?

    肖:商业主要有 IBM/ORACLE ESB,高达6/700W 的单机许可费。开源的有ServiceMix/Fuse/JBOSS/Mule 等ESB产品。 ServiceMix/Fuse ESB 4.X以后是基于OSGI架构的,提供了很好的扩展性,上手是有点难度。目前很多产品都在往OSGI靠拢,如JBOSS AS 7。 谈不上咨询,大家互相交流学习。

    8.如果所有的服务接口都接入ESB,ESB怎么保证安全服务,如果ESB挂掉,那所有的应用系统也无法服务了,加一些缓存集群是否能彻底解决这样的问题,可否做到我调用一台机器时那台机器挂了,直接将服务切到另一台机?

    肖:可以部署多台ESB集群,在ESB前面可以通过F5/LVS等来做负载均衡,若是LVS,可以通过心跳来检测当前ESB的服务状态,若是一台出现宕机情况,可以把请求转发到其它ESB 。

    9.问个具体点的问题,我做了个实验项目,架构是这样的:webapp+serviceMix,需要在webapp端控制路由的部署和启停。

    部署就是将bundle放到相应的文件夹下了,命令通信还没实现,找了资料(http://svn.apache.org/repos/asf/karaf/trunk/client/src/main/java/org/apache/karaf/client/Main.java)是用ssh实现的,

    不知道除了这个还有没有其他更好的方法。另外,部署不知道还有没有其他方法。

    肖:这种是通过远程SSH,来管理ESB控制台,控制bundle的启动和运行。你可以参考下 Karaf的 webconsole是如何做的bundle管理。

    追问:谢谢,借此机会多问一下,想请问下除了用ssh远程管理esb外,还有没有其他方案可以让web与esb结合,比如在webapp中集成karaf和camel可行不?另外apache ode已经与新版本jboss esb不兼容了,你们是如何做webservice编排的?多谢了~

    肖:ESB 部署bundle,bundle集成Camel,服务编排用Camel 的 EIP 。

    追问:谢谢,个人认为Camel EIP不太适合做服务编排,虽然有java DSL,还是没有BPEL合适。现在在用bpel-g 。

    肖:bpel是基于SOAP协议的,会占用大量带宽。

    10、想问一下开源的esb选择哪个比较好,现在在openESB和WSO2 esb中犹豫,希望得到您的指导。

    肖:这两种ESB我还未使用过:),建议你用主流ESB。

    11、ESB能够提供什么服务,能够帮助解决问题1中的这些问题?为什么要使用ESB?如果不使用,其实没什么问题,对不对?它最大吸引力在哪里?

    肖:1、多系统之间的互相调用会造成网状结构错综复杂 。

          2、接入ESB后,服务都集中在一处调用,原系统如果是以ws公开的服务,经过esb包装之后,可以公开称多种协议适配各种客户系统调用 。

          3、ESB可以统一的进行日志、安全和权限以及SLA治理,很方便进行控制。

          4、ESB作为众多系统的入口,还可以很方便的在一处实现跨系统的流程整合和编排 。

    12、除了 Redhat 和 JBoss 的文档,还有什么好的 Fuse ESB 学习资料吗?

    肖:很多,Fuse ESB集成了很多开源项目,如Karaf/CXF/ActiveMQ/OSGI等,这些你都需要有所了解,去他们的官方有文档,书籍方面 你可以参考 Open Source ESBs In Action不过版本有点老了。

    13、在医院的药品管理系统、挂号系统、医生/护士工作站、财务等各种his系统当中esb可以扮演什么角色?或者说他适用这种环境吗?有木有类似的项目?哈哈,我是业余前端,问得不好还请见谅。

    肖:可以适用,接口都可以接入ESB。

    14、activimq用topic还是queue?对于客户端向ESB发送数据需要返回值的情况,对于activimq 有什么好的解决方法没?

    肖:目前好像还没好的办法,可以创建一个返回队列来实现 JMSReplyTo 。

    other:既然对于请求需要有返回值,这属于RPC的范畴了。可以基于 Camel 做 RPC。

    15、esb对性能是不是有很大影响,刚用,发现速度会差一半.

    肖:看不同的ESB产品 ,Fuse ESB我们做性能测试,性能损耗是很小的。

    16、另外想咨询:
           1、在设计数据变更推送的机制,我们目前是在数据表上加触发器有字段更新写到中间表记录,然后一个定时任务去扫描这个中间表,然后形成特定的发送记录。
           2、ActiveMQ 在大量消息下性能是否可靠?
           3、ESB接入多个系统后,是直接访问源系统的数据库,还是在中间库做一份镜像?如果是直接访问数据库,事务控制等应该怎么做?如果是中间库,如何保证数据的实时性呢?
    肖:大量消息下,消息的可靠性是没问题的,MQ做了大量的工作保证消息的可靠性,如消息存储在文件/客户端的确认机制等,性能上要根据实际的场景调优MQ的性能。 我们是把其它业务系统的核心数据抽取到本地库中,通过Kettle ETL+quartz定时抽取。如果实时性比较高,可以考虑数据库复制,触发器等。

    17、现在项目是不是已经整合到JBoss ESB中了呢?相关的文档都需要从JBoss上下载吗?

    肖:http://www.jboss.org/products/fuse http://fusesource.com/products/enterprise-servicemix/

    18、想问下在ESB中,在多个系统交互时,如何控制数据的一致性呢?遇到异常如何回滚呢?

    肖:事务的补偿机制。

    追问:ESB中有实现事物补偿的么?那些资料可以参考呢?

    19、现在的 ServiceMix 支持部署 WAR 应用了吗?

    肖:支持。

    追问:这个回复过于简单了。OSGI-4.3引入了WAR支持。WAR首先被转换成一个bundle(WAB),然后启动。在这个过程中,很容易出现类库冲突,导致启动失败。详情请参考osgi.cmpn-4.3.0.pdf("OSGi Service Platform Service Compendium")中的"Web Applications Specification"章节 。

    另外,OSGI也有自己的适用场景,如果没有模块化需求,不应该引入OSGI。单纯的WAR项目就没有必要改造成OSGI项目。

    肖:除了 OSGi,模块化还有什么别的选择?SOA? 

    话说 Spring 不支持 OSGi 的原因是什么呢?Hibernate也是用Gradle构建,照样在努力地向 OSGi 靠拢。

    追问:应该是吧。我认为,OSGI 也可以认为是广义上的 SOA . Spring 支持 OSGI 的啊,你是不是看错了?

    肖:InfoQ 上等过 SpringSource 打算放弃支持 OSGi 的新闻。

    在最新的版本里面已经移除了 OSGi 的 manifest 文件,我是从 Maven 官方库里面下的 。

    追问: 你这么一说我也记起来了。之前 Spring 是支持 OSGI 的,动态模块还是 spring 搞出来的。放弃支持是他们的决定吧,我觉得OSGI的复杂性应该是其中的重要因素。

    20、消息能支持多大呢?能否支持10M以上文件推送?

    肖:你指的MQ?

    追问:对, ESB 一般不包括MQ这样的消息中间件吗? 

    肖:可以试试 MQ的BlobMessage;或者把文件拆分然后分组发送。对于太大的文件不建议使用MQ来传输。

    21、关于分布式日志采集,一般说可以采用ActiveMQ/MetaQ等实现。我的疑问是:网络写速度比不上本地文件系统写,实践中怎么解决这个问题?

    肖:分布式日志采集,这里没看懂。是对分布式系统的日志采集?

    22、为什么不把部分接口服务以RESTful方式暴露,看你里面全是webservice。

    肖:是Restful风格的WS。

    23、ESB和RPC(比如Dubbo/Corba/ICE)等适用场景,能介绍一下吗?谢谢。

    肖:ESB和RPC是完全不同的两个概念,PRC是点对点的消息传递,ESB是所有的服务接口都接入到ESB,通过它来转发 。

    24、正好我也是在做ESB,我想请教您,对于Mule ESB 有所了解吗? 或者您是否能提供一点你选用Fuse ESB方案的考虑吗?

    肖:这个是我们ESB技术选型的一部分资料:

    Mule ESB拥有了不错的用户量,且比较容易上手,但其由于其企业版是商业产品,相需要收费,且架构本身并没有成为规范,因此,若在没有源码的情况下大规模使用,一旦出问题,可能需要专业技术团队的支持。另外,Mule之前是没有自己的消息中间件的,且不支持热部署,收购Mule MQ之后才真正成为一个正式成熟的ESB。 

    Fuse ESB很好的支持了JBI规范,其下产品均是由Apache下的著名开源项目组合而成。其中若干框架均已为开源世界广泛应用,比如Apache Camel和Apache ServiceMix,尤其是其中的Apache ActiveMQ和Apache CXF,且ServiceMix 4之后基于OSGi架构,更能迎合企业动态化、模块化的需求。此外,Fuse有丰富的文档支持,加上其主要框架为大多开源人士所熟知,技术上可控性强,风险较小。

    25、问题如下:

           1、同步接口调用,怎么处理?有一些需求要同步返回调用结果。

           2、想涉及一些支付业务的服务,事务怎么处理? 

           如:下订单业务,首先要调用“商品模块服务”查询库存,然后才能决定下单业务是否可以继续,如果库存充足,则要:    
           1)调用“商品模块服务”锁库 。
           2)调用“订单模块服务”保存订单。
           他们之间的事务怎么保证?能否给些思路。

    肖:ESB 只是做了路由转发功能,除了MQ,大部分都是同步的。Camel内部也做了一些事务的保障机制, 若是中间牵扯到了 多系统流程服务的编排,最好定义好发生异常后事务的补偿机制。

    26、能不能多讲一下ESB的应用场景和不适合的应用场景。

    肖:涉及到多系统整合或者服务流程整合,就要考虑是否需要上ESB。

    27、FuseESB 稳定版本是哪个版本?下载时候是 6.0 版本包,怎么官方文档是  7.1 ,还没搞明白。

    肖:7.1是没被收购之前的,现在被redhat收购,改名叫 Jboss Fuse。 

    28、将各种异构的子系统整合,由一个统一的中间件调度服务的架构就可以称作ESB吗?

    肖:这个是ESB的核心功能,还包括服务编排/消息增强/协议转换/格式转换/安全控制/服务质量等。

    29、ESB怎么保证消息的可靠传递?

    肖:如果是JMS消息,ESB中的MQ会持久化该消息到文件或者数据库。若是其它协议的消息,发生异常或者其它自定义状况,ESB会捕获到该状况然后经过处理告诉客户端。

    30、您好,能否比较几种常见的ESB产品(集),mule esb/cordys/Jboss esb/open esb ? 它们分别的适用场合是什么?特别是您对Cordys的看法?

    肖:ESB的功能都差不多,你要更详细的比较:可以去看看 Forrester研究公司(http://www.forrester.com),在2011年第二季度对“企业级服务总线”做了一个详尽的研究报告,比较了IBM、Oracle、Progress Software、Software AG、Tibco、FuseSource、MuleSoft、Red Hat和WSO2等诸多商业和开源厂商的ESB产品。

    31、ESB 对企业部门之间的信息孤岛的破解,是否有帮助,如果有的话,处理策略是什么?

    肖:造成信息孤岛的原因主要是系统之间通讯不畅,把各系统对外的接口都统一连到ESB即可,避免各系统的相互调用造成复杂的网状结构。

    other:n*n 和 1*n ,这种在系统庞大的企业中,是非常有价值的。

    jack:谈到ESB两大主流是Mule和Camel。Mule用户多一点。不过Camel接口更多,而且迭代速度更快。试过Camel+karaf发现对数据库支持这块osgi略差一些。于是采用Camel+spring。使用下来各方面都很出色,推荐此方案。

    32、请问ActiveMQ用的什么版本?怎么整合的?如何保证数据消费的可靠性,有没有出现丢消息或者假死的问题?

    肖:Fuse ESB默认就集成ActiveMQ,未出现你说的现象,不过如果发的太快,收的太慢会出现你说的情况,可以在接收端增加负载来解决 。

    33、esb如何解决多系统的数据一致性问题?例如在转账这种需要跨数据库事务的场合下怎么搞定?

    肖:可以定义流程发生状况的补偿机制,一旦服务流程流转中出现问题,所有执行过的活动都按特定的逻辑进行补偿 。


    展开全文
  • 几种ESB(企业服务总线)介绍

    万次阅读 2018-07-16 19:24:45
    ESB(Enterprise Service Bus,即企业服务总线)是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。 企业服务总线ESB就是一种可以提供可靠的、有...
  • AdroitLogic已宣布将以开源形式发布“ UltraESB”企业服务总线(ESB),声称这将使UltraESB成为首个支持使用Java非阻塞IO和内存映射文件对请求进行零拷贝代理的开源ESB。 他们还将发布SoapBox的源代码,SoapBox是...
  • 本文作为ESB系列文章的第一篇,介绍了面向服务的体系结构(service-oriented architecture,SOA)和企业服务总线(Enterprise Service Bus,ESB)的基本知识,ESB的技术沿革,以及ESB与SOA之间的关系。
  • 企业服务总线应用解决方案系列的前面三篇文章中,作者对ESB的技术特征,ESB在WAS6 SIBus上的实现,以及在WBI MB5上的实现分别作了较为详细的论述,相信大家都对ESB已经有了一定程度的理解。总而言之,ESB是SOA体系...
  • 企业服务总线ESB

    千次阅读 2017-02-23 13:30:54
    企业服务总线(Enterprise service bus). 以往企业已经实现了很多服务, 构成了面向服务的架构,也就是我们常说的SOA. 服务的参与双方都必须建立1对1 的联系,让我们回顾一下SOA架构有哪些基本的要求: SOA在相对较粗...
  • ESB 企业服务总线基本内容概述

    千次阅读 热门讨论 2016-10-09 15:26:18
    ESB全称为Enterprise Service Bus,即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。整个架构体系里面分为三个组件或子系统,...
  • ESB-企业服务总线

    万次阅读 2017-05-18 13:53:08
    ESB全称为Enterprise Service Bus,即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。ESB的出现改变了传统的软件架构,可以...
  • ESB即企业服务总线

    千次阅读 2018-08-13 10:10:06
    ESB全称为Enterprise Service Bus,即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。  ESB的出现改变了传统的软件架构,可以...
  • 企业服务总线 1. 关于SOA 2. ESB简介 3. ESB的适用场景及要素 4. SOA和ESB产品 5. WebMethods介绍 6. 案例说明
  • ESB是Enterprise Service Bus的简称,中文翻译为企业服务总线企业服务总线是一个实现系统间集成和互联互通的重要技术架构,可以理解为是一种消息和服务集成的中间件平台。 这个技术是为了解决什么问题呢? 系统...
  • 企业服务总线ESB 基于企业服务总线解决IT集成 改进应用之间的集成(企业服务总线ESB)已成为企业IT的重要方向 派拉ESB模块划分 管理平台 监控平台 运行平台 派拉基于ESB实施的整体优势 行业需求的深刻...
  • 企业服务总线项目集成标准

    千次阅读 2016-11-25 21:33:47
    企业服务总线(Enterprise Service Bus,缩写 ESB),是SOA面向服务架构的骨干,在完成服务的接入、服务间的通信和交互基础上,提供安全性、可靠性、 高性能的服务能力保障。采用 SOA 架构,基于ESB总线进行企业异构...
  • 企业服务总线Enterprise service bus介绍

    千次阅读 2013-06-28 10:27:35
    企业服务总线(Enterprise service bus). 以往企业已经实现了很多服务, 构成了面向服务的架构,也就是我们常说的SOA. 服务的参与双方都必须建立1对1 的联系,让我们回顾一下SOA架构有哪些基本的要求: SOA在相对较粗...
  • 顾名思义,企业服务总线(ESB)就是一条企业架构的总线,所有的企业服务都挂接到该总线上对外公布,企业服务总线负责管理服务目录,解析服务请求者的请求方法、消息格式,并对服务提供者进行寻址,转发服务请求。...
  • 企业服务总线(ESB) 定义 MQ(Message Queue)消息队列。 把要传输的数据放在队列中,通过消息传递队列发送和接收消息数据,实现数据的传递。 ESB(Enterprise Service Bus) 是一个集中式的服务...
  • 通过企业服务总线连接SOA服务

    千次阅读 2008-08-26 13:43:00
    由于众多原因,企业服务总线 (ESB) 是任何企业级 SOA 必不可少的一部分。随着实施面向服务结构体系 (SOA) 这一观念的日渐普及,企业发现自己的服务组合规模日益增大。如果不遵循正确的体系结构模式,则很难有效地...
  • ESB企业服务总线 --- ESB概述

    千次阅读 2017-06-20 15:37:55
    ESB企业服务总线 --- ESB概述
  • 企业服务总线(ESB)

    2014-04-02 16:13:22
    自己感觉很多的疑惑,经过交流,群里的两位大神给了两个名词,一个就是企业服务总线,貌似是这么回事,先查查资料,给自己普及知识了。  介绍  ESB全称为Enterprise Service Bus,即企业服务总线。它是传统...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 35,496
精华内容 14,198
关键字:

企业服务总线