谈轻量服务总线

标签: IT咨询 | 发表时间:2013-09-15 10:26 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
经过大半年的产品研发,公司的轻量服务总线ESB产品终于成型,该产品是SOA咨询实施团队经过6年在大型电信行业SOA最近咨询和实施实践最终浓缩出来的一个轻量型产品。在大型SOA项目实施中,即使采用了类似oracle soa套件等重型产品,仍然看到很多功能往往在实际的实施中并没有用到,而这个产品正式基于实际SOA实施的重点最终抽象和浓缩出来的一个轻量ESB产品,完全可以满足大多数企业内部服务共享平台和esb服务总线的需要。

企业内部为何要用类似ESB总线的中间件产品

这个前面已经解释过很多次,ESB产品使用主要是解决企业内业务系统点对点集成到总线式集成的一个重要转变,真正实现所有服务集成的集中管控。服务总线一方面解决跨业务系统的接口集成问题,一方面解决底层平台层或数据层能力的服务共享问题。

当前产品有哪些适配器,支持哪些服务和协议的接入

根据SOA实施的经验,在轻量ESB产品中,我们重点是实现http协议的接入(包括soap webserice和restful webservice),实现JMS消息接入和协议转换,实现了文件适配器,实现了大数据的类似oralce odi的数据集成适配器。

当前产品主要功能如何

当前产品完全是围绕一套实践多年的SOA咨询和实施方法论展开,覆盖了SOA全生命周期的管理。包括了服务识别,服务定义,服务概要设计,服务注册和服务接入,服务开通和控制,服务自动化测试,服务监控,服务统计分析报告全面功能。同时在该过程中尽量实现了整个服务接入的自动化过程,可以实现在服务规范和服务契约确定后快速的服务封装和接入。

同时在基本功能的基础上增加了基于消息的发布订阅机制,实现了大文件和大数据的集成,实现了原有类似oracle soa产品化套件也较难以管控的服务流量控制。完全的服务自动化测试,自动化部署等诸多功能,真正大幅的提升了服务实施的效率。

当前产品和业界大型商用soa产品的主要区别

该轻量esb产品完全基于开源的数据库,开源的中间件来实现。数据库我们采用了mysql的集群架构,中间件采用了开源的jboss中间件产品。物理部署上完全的去IOE,同时通过集群架构实现了高可用性。对于数据库和中间件集群都可以实现水平线性扩展能力。

对于产品功能上,可以讲是商用soa产品核心功能的一个浓缩,实现我们在SOA实施中真正最关心的功能,而不是将产品过渡设计和复杂化。比如类似复杂的bpel编排不实现,类似socket或其它EAI中间件的适配不考虑,将重心真正转移到服务集成和服务能力的提供上。

在进行性能测试的对比中,在大型商用产品采用小型机架构,我们自己的产品采用x86服务器的架构下,单点500,单点1000并发分别进行了测试。服务响应的时间和性能略比oracle soa 11g套件慢10-20%左右,整个性能基本能够满足要求,不过还有进一步性能优化的空间和余地。

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

相关 [服务 总线] 推荐:

谈轻量服务总线

- - 人月神话的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信息记录,则直接返回查询的结果.