谈轻量服务总线

标签: 随笔文章 | 发表时间:2013-05-04 19:44 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
上次谈数据集中化和拆分的时候谈到了轻量总线的问题,在这里再对轻量总线的思考做一个简单的说明。首先来看下对于一个ESB总线本身的模型简化,如下图:



在这种ESB总线模式下,通过inbound 和 outbound pipeline会做大量的的工作。包括访问控制,流程控制,协议转换和适配,日志logging等。这些插件本身是可插拔的配置,有些是对消息头信息的简单处理,有些是需要对消息体信息进行处理。除掉这部分内容,剩下的包括了服务代理,数据处理,服务轻量编排,路由功能等,这些也是核心的ESB功能。

从消费方发起一起服务请求调用,整个过程可以简化为首先是通过inbound pipeline进行访问控制,流量控制,进行协议的转换,对输入的信息进行log记录。然后进行实际处理环节,包括proxy service的解包,数据的处理和转换,路由分发;然后进入到提供方实际的服务调用,服务调用完成后对于返回的服务调用信息再进行相关的协议转换和日志记录处理,最终返回结果给服务消费方。

在这个过程中,可以看到整个服务调用数据流都需要在总线上运行和传输,一个是数据量本身很大,一个是每次数据适配和解析都可能是一次性能消耗。针对全新规划的系统建设可以看到,不会有太多的遗留系统适配和协议转换问题,在ESB总线上也不会处理太多的数据映射处理和转换工作。同时流量控制本身也不是必须的功能要求。因此对于简单的总线,其核心功能重点将放在代理服务,路由,日志记录,访问控制四个核心内容上。

对于上述四个核心内容的实现,基本可以参考上面的ESB总线模型进一步简化,那总线的瓶颈可能受到的最大影响就是日志记录这块,在这块初步的思路就是日志记录是接JMS+MQ,对于总线接收到的日志记录进行异步持久化处理,这样日志记录的瓶颈和性能问题可以减轻。

以上问题都考虑后,是否还可以对总线模型做简化,总线更加重要的是统一服务目录库(proxy service)的提供,服务鉴权和路由功能。如果仅仅考虑这些功能,那么整个消息流是否一定要走在服务总线上?基于这个思路,可以看到在轻量总线上可以进一步考虑控制流和消息流的进一步分离,如下图:



在这种场景下,消费方对服务的调用由原来的一次调用转换为两次,首先第一次调用传入相关的消费方系统,请求地址,和消息头信息。对于总线根据这些信息进行服务鉴权,流量控制,根据proxy找到具体的原始服务提供地址,在这个地方中还涉及到路由。这些内容都处理完成后,根据拿到的目标端信息和控制令牌等信息发起对目标端的直接调用。目标服务提供端也可能涉及到需要和总线交互进行相关的鉴权操作,完成后返回数据信息给服务消费方。

在整个过程中,服务总线上不承载具体的消息数据流,也不会对消息流进行协议转换或数据映射处理等。重点还是实现统一的服务目录库,对服务进行访问控制和鉴权,根据消息头参数对目标端进行路由等。由于不承载具体的消息数据流,服务总线将很轻,即使在大并发量和大数据量下也不会出现较大的瓶颈。这种总线模式将适合类似技术服务,DaaS数据库服务,数据服务等大量数据传输的场景。

在这种模式下,可能会出现一个新的问题,即对于服务消费方往往需要两次调用才能够实现。对于这个问题很简单,我们可以考虑实现了一个前置的轻量ESB服务代理包,在ESB服务代理包中对两次调用过程进行封装,以简化应用对服务的消费。

  青春就应该这样绽放   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

相关 [服务 总线] 推荐:

谈轻量服务总线

- - 人月神话的BLOG
上次谈数据集中化和拆分的时候谈到了轻量总线的问题,在这里再对轻量总线的思考做一个简单的说明. 首先来看下对于一个ESB总线本身的模型简化,如下图:. 在这种ESB总线模式下,通过inbound 和 outbound pipeline会做大量的的工作. 包括访问控制,流程控制,协议转换和适配,日志logging等.

谈ESB服务总线改进

- - 人月神话的BLOG
对于消息中间件部分进行单独剥离,即讲服务设计和ESB协议转换和适配部分同消息中间件分离,对于消息中间件部分初步考虑采用RabbitMQ或zeroMQ来实现,其中zeroMQ由于用c语言实现,相当来说更加轻量和高性能. 但是RabbitMQ本身更适合做一个企业级的消息系统,其在集群,持久化,高可用性和分布式可扩展性方面往往更加有优势.

服务禁语

- tiancaicai - 白板报
前几天在一个公交汽车站拍到了一张规定,里面规定了服务禁语和礼貌用语,看了大乐. 3、乘车高峰车厢内拥挤时,禁语:“快往里走,站在前面又没有钞票检. ”文明语:“请尽量往里走,照顾没有上车的乘客”. 4、车子抛锚,禁语:“车子抛锚没有办法,人都要生毛病的,车子坏了也正常. ”文明语:“对不起,车子出现故障修一下,请大家理解.

服务熔断

- - CSDN博客推荐文章
服务熔断也称服务隔离,来自于Michael Nygard 的《Release It》中的CircuitBreaker应用模式,Martin Fowler在博文 CircuitBreaker中对此设计进行了比较详细说明. 本文认为服务熔断是服务降级的措施. 服务熔断对服务提供了proxy,防止服务不可能时,出现串联故障(cascading failure),导致雪崩效应.

面向服务与微服务架构

- - CSDN博客推荐文章
最近阅读了 Martin Fowler 和 James Lewis 合著的一篇文章  Microservices, 文中主要描述和探讨了最近流行起来的一种服务架构模式——微服务,和我最近几年工作的实践比较相关感觉深受启发. 本文吸收了部分原文观点,结合自身实践经验来探讨下服务架构模式的演化. 面向服务架构 SOA 思想概念的提出已不是什么新鲜事,大概在10年前就有不少相关书籍介绍过.

经理服务生

- netcasper - 坏脾气的小肥
2007年的时候,我和内容团队一起去报道上海车展,累得够呛,写稿子到凌晨一两点,早上八点钟又要爬起来去现场或更新早班. 有天上午,编辑都挤在大会议室里忙活着整理、发布、撰稿,而我搞完了竞品检查/数据分析/计划修订,一时间闲着,就打算去买些零食给大家. 环顾四周,没人有空,只好自己下楼,嘿咻嘿咻拎了两三百块钱的零食上来.

Kernel.org恢复服务

- Adam - Solidot
kernel.org 王者归来 写道 "Linux内核官网在八月份遭入侵,之后于9月11日linux.com linux.org kernel.org LinuxFoundation.org皆无法访问,进行安全维护. 经过紧张的修复,kernel.org终于恢复服务. LinuxFoundation.org也可以正常访问.

谈领域服务

- - 人月神话的BLOG
对于跨系统和模块间的SOA服务识别和分析我前面文章谈的比较多,这块的SOA服务重点是实现跨系统和模块的业务交互和协同,而对于领域服务而言则更加关心的是对于单个系统或模块,其应该如何抽象领域对象并将其能力以粗粒度服务方式保留给应用层用. 在领域建模中的整体思路中,我们做两个层面的理解,其一是领域模型层重点是隔离传统的数据表并抽象为领域对象;而对于领域服务层重点是则将应用层和领域模型层解耦,模型层提供的能力是以领域服务的方式暴露到应用层使用的.

DNS服务-详解

- - 操作系统 - ITeye博客
DNS(Domain Name System)域名系统,在TCP/IP网络中有非常重要的地位,能够提供域名与IP地址的解析服务. <1> 客户机提交域名解析请求,并将该请求发送给本地的域名服务器. <2> 当本地的域名服务器收到请求后,就先查询本地的缓存. 如果有查询的DNS信息记录,则直接返回查询的结果.