ESB产品架构之我所见(三)_JAVA_编程开发_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 编程开发 > JAVA > ESB产品架构之我所见(三)

ESB产品架构之我所见(三)

 2010/12/11 11:31:56  guoshiguan  http://guoshiguan.javaeye.com  我要评论(0)
  • 摘要:1ESB内部视图从静态来看ESB系统,它主要由三部分组成(图5?1)lEndpoint:他的职责被分为两部分,一部分是接收响应用用户的请求,另一部分是请求服务的服务方lRouter:主要是消息的路由。当endpoint接收到一个请求后,会交由路由来选择相应的消息服务方,或都对消息进行一些处理。l基础组件:支持整个ESB,的共同组件。图5?1如果从动态的角度来看ESB系统,你会发现,在ESB的内部我们可以看成是一个个有组织的消息通道(图表5?2),用户在请求ESB时会选择一个相应的消息通道
  • 标签:ESB产品架构

?

1?????? ESB 内部视图

从静态来看 ESB 系统,它主要由三部分组成 ( 5 ? 1 )

l? Endpoint :他的职责被分为两部分,一部分是接收响应用用户的请求,另一部分是请求服务的服务方

l? Router :主要是消息的路由。当 endpoint 接收到一个请求后,会交由路由来选择相应的消息服务方,或都对消息进行一些处理。

l? 基础组件:支持整个 ESB ,的共同组件。

?


5 ?1

如果从动态的角度来看 ESB 系统,你会发现,在 ESB 的内部我们可以看成是一个个有组织的消息通道(图表 5 ?2 ),用户在请求 ESB 时会选择一个相应的消息通道。在这个消息通道中,会有很多的处理器他们根据处理器自己的职责对消息流进行相应的处理。


5 ?2

?

1.1???? 元素

?

1.1.1? 消息处理管道

消息处理管道是 ESB 架构的一个核心部分, ESB 的核心有消息处理器分为两部分,一部分是路由处理器,一部分是端点处理器。当然,我们的基础组件也会适时的在两部分的处理器中间,拦截加入多个基础组件处理器。例如,日志组件,会在各个部分加日志处理器,以记录 ESB 运行的日志

在(图表 5 ?2 )中只是一个简单的通道,在这个通道中没有分支,路由处理器也只有一个,在实际的使用过程中当然没有简单,在路由处理器可以有多个, Endpoint 也可以拥有多个。当整个通道的分支过于复杂的时候,建议还是把它看成一个业务流程,交他专业的 BPM 应用来做,这样不但可以减少 ESB 复杂度,而且可修改性也能有一个大的提高。 ??

在实际的开发过程中,我们可以使用责任链的模式( Chain of Responsibility Pattern 5 ?3 )。一条责任链就是一个通道,消息处理器就是责任链中的一个个 handler 。我们可以在使用配置组件,在 ESB 初始化的时候就初始化好了一个个的消息处理器。


5 ?3

????????

1.1.2? 消息对象

因为使用了消息通道,通道内的消息流必然是要有一个统一的消息对象来进行良好的定义,这个消息对象,不但带有消息的内容,还应该会有消息的状态,而且还有消息所处的通道的上下文。


MessageObject :消息的载体

Context :是一个 ESB 的上下文,所有的组件和配置都会注册到 Context 上下文中去

Session :主要是一请用户请求的一些信息。

?

1.1.3? Endpoint( 端点 )

Endpoint 可以分为两种,一种是集成在 ESB 内部,另一种是嵌入到使用 ESB 的应用系统中。

在理论上,使用第二种,可操作的范围要大一点,而且可以有一些别的操作比如,事务性端点等特性。而且,可以使用嵌入式的端点来达到 apache 那种反向代理的功能,这样做个好处,可以避免出现在水平扩展时使用反向代理时带来的单点故障的问题,可以在一定的程度上提高可用性。不过理想是美好的,但现实是很多时候我们也不可能在应用系统中嵌入一个端点。

???????? ESB 系统中我们可看到两类的端点 Inbound Endpoint Outbound Endpoint ,这两类的端点一类是接收用户的消息,一类是发送消息的服务方。

???????? 在典型的 endpoint 中可以分为 Transport Transformer 、和 Filter 这三个功能块,这些功能块会在下面的章节中进行阐述。

1.1.3.1 Transport

Transport 的最主要的功能是接收和发送数据,他是一个类似通讯协议适配器的功能。

5 ? 2 是一个典型结构的,他主要由三部分组成

l? Connector :主要职责是处理通讯协议的连接问题,这个连接可以是一个 TCP 连接也可以是 VM 内部的一个虚拟的连接

l? MessageRecerver :主要职责是通过 Connector 的连接,监听连接并获得用户请求的消息,并把数据组成一个 ESB 内部消息对象,并把这个消息对象交由 ESB 管道来进行处理。

l? MessageDispatcher :主要职责是把消息发送给消息的服务方,并接收消息服务方的反馈。它将被组成一个消息处理的节点,放入到管道中。


5 ? 3

1.1.3.2 Transformer

它的主要职责对不同的消息格式进于转换,使其成为一个 ESB 内能部能很好的识别的消息格式,它本身是一个消息处理器,可以初组织到消息入理管道中去。

现在比较通用的用法是,内部的消息格式是一个 soap 报文,并且这个报文应该是一个由 WSDL 定义的 SOAP 报文。这样做的好处在于, WebService 跨平台的能力让我们可以减少使用 transformer 来转换。

如果企业内在部分的系统使用 xml 作为消息的载体,那么建议使用 XSLT 来把 XML 的消息格式转换成 SOAP 的格式。这样做不管在性能上(减少 transformer ),而且 XSLT 本身是一个 xml ,对其修改也较方便,这对提升 ESB 的可修改性有一定的帮助。现在 XSLT 的普及,已经有大量的辅助的开发工具来提高 XSLT 开发效率。

?

1.1.3.3 Filter

它的主要职责是过滤一些消息,当消息进行转换后,我们可以通过已经可以知道消息载体中的具体内容。在般的使用场景是这样的,根据其中的一些数据,来判定是否要把消息送到下一个消息处理器进行处理。这个判定的过程,最好的做法是使用基础组件中的规则引擎来判定,这样会达到一个很好的可修改性。

1.1.4? 路由

在架构上,路由应该和 transformer 一样,只是一个消息的处理节点,他应该也要实现消息处理器的接口。这样,他才能成为消息通道的一部分。他最大的职责是,让消息找到正确的消费者

路由是可以联合工作的,例如,我可以先使用路由的分解器分解消息,再使用内容路由来决定各部分消息的走向,使用 filter 来对消息进行过滤。就这些,路由被一层一层的嵌套工作,这严得的增加了路由部分的复杂性,虽然,我们支持这种做,但应该说并不建议这么做,专业的事应该交给专门的系统来进行处理,这些处理应该属于流程的编排,那就交给 BPM 来做吧,原则上如果路由超过了三层的嵌套就最好放到 BPM 中去。

?

1.1.5? 基础组件

基础组件主要是为了保障整个 ESB 能更好的完成 ESB 的任务的组件,这些组件每一个都需要进行良好的设计,在这里,只是对一些组件进行一下必要的说明,在实际的使用中可能还会增加一些基础组件。

l? 日志组件:主要是记录 ESB 交易产生的日志,这些日志用来踪一支交易。

l? 流控组件:保障 ESB 内部不会因为交易量突然超过自己的承受能力而出现当机的分险。

l? 规则引擎:在一些比如 filter 或是内容路由时,可以增加可修改性。

l? 线程池:对 ESB 很重要,他是最基础的组件之一

l? 对象池:在 ESB 的实现中,有一些对象不是线程安全的,而实例化这种对象要消耗大量的资源,这时,我们就会使且对象池来提高性能。它是一个最基础的组件之一。

l? 消息队列:消息队列可以是内部的队列,也可以是外部的队列,这也是一个非常基础的组件之一。

l? 配置组件:因为 ESB 实际上是一个可以做水平扩展的系统,而且,还要接受企业域的控制,所以配置组件需要有很高的可修改性,最好能应用 JMX 来对配置进行管理。

l? 监控组件:这个组件实际上只是监控平台的一个客户端,他主要是为监控平台收集一些 ESB 内部的信息而存在。

l? SEDA 组件: (Staged Event-Driven Architecture) 的核心思想是把一个请求处理过程分成几个 Stag ,不同资源消耗的 Stag 使用不同数量的线程来处理, Stag 间使用事件驱动的异步通信模式。

1.2???? 场景

1.2.1? 简单同步处理

ESB 当中应该有很大一部分是简单的同步处理,在简单的中的流程图如下所示。这是一个最简单的流程,当然 ESB 框架会自动的在这些消息处理器中间加入一些,比如记录日志等,基础的消息处理组件。

?

5 ? 4

?

1.2.2? 简单异步处理

简单的异步处理,需要使用公共组件 SEDA SEDA 会把我们消息对象放入到消息队列中,然后直接就返回给请求方。接着 SEDA 的线程池会去处理队列中的消息对象,后面走的就和同步处理一样了,这种简单的异步处理,只适合没有返回消息的情况。

SEDA 的典型结构如下图所示,他实际上是有一个事件队列,如果是当这个消息是异步的时候,做完相应的报文转换后就会把消息放入到管道内的事件队列中。管道内会有一个线程池进行监听,取出队列内的消息传向下一部路由。也就是说,我们只是在简单同步的基础上,在 transport transformer 之问放入了一个 SEDA 的组件,这样就可以达到一个异步效果。

?


5 ? 5

1.2.3? 复杂的路由

复杂路由的场景是一个路由的一个嵌套,因为所有的路由都是一个 messageProcessor 。这就嵌套做好了一个必要的条件,这时路由很象是一个嵌套的路由树。

1.2.4? 内嵌式端点

有时我们会把端点内嵌到应用系统中,这样做有以下几个好处。

l? 端点的路由功能,可以减少反向代理器的这个单点故障

l? 减少应用系统的开发难度,我们对内嵌式的端点已经做好了一个良好的封装,应用系统可以很简单的使用他。

l? 可以拥有便如事务这样的特别的功能属性。

?

1.2.5? 异常处理

异常处理是每一个系统中必要的一个组成部分 ,ESB 当然也不例外。在 ESB 系统中我们会有一个专门的异常处理组件来对异常进行处理。我们会在管道中 cache 所有的异常,然后把异常抛给异常处理组件,异常处理组件,会根据上下文和异常的类型选择一个相应的异常处理通道对异常进行相应的处理。

1.2.5.1 交易保障通道

交易保障请求就是要保证消息的消费者一定要消费了消息,或许消息的消费者消费的时候可能会有异常,但我们一般还是会认为这个消息已经被消费掉了。只有在消息的消费者失去联接的时候,我们才会需要起用消息保障的通道,而这个消息保障通道会有一定的策略去重新的重新发送这个消息。

1.2.5.2 自定义异常通道

自定义的异常通道中,是一个可以根据用户自定义的一个特定的异常,这个异常很可能是一个用户的业务异常,而进行的一个特殊的通道。

?

  • 相关文章
发表评论
用户名: 匿名