【FCon】聚焦金融行业在数智化的全面革新,一线的金融数智化实践干货 了解详情
写点什么

JBoss Messaging 羽翼渐丰 支持集群和透明故障转移

  • 2007-03-31
  • 本文字数:4268 字

    阅读完需:约 14 分钟

6 月 17 日,极客时间《企业级 Agents 开发实战营》正式上线,10 周掌握企业级 Agents 从设计、开发到部署全流程。

数周以前 JBoss(已被 Red Hat 收购)发布了其 JMS 产品的最新版本, JBoss Messaging 1.2 。这个产品的面世已经有些时日了,它产生的目的是为了替代日近迟暮的 JBossMQ。这个发布版最终加入了产品级消息传送系统所需要的集群(Clustering)和透明故障转移(Transparent Failover)功能,因此对于 Red Hat 来说,这是一个非常重要的里程碑。

透明故障转移功能允许在连接的节点出现故障时,透明地将连接或者 Session 转移到另一个正常节点,而无须让应用程序显式地处理连接异常。另一个被加入的特性是分布式消息接收站(Distributed Destinations)。与 JBoss 的某些竞争者不同,JBoss Messaging 逻辑上完全支持在集群内部分布的队列(Queue)和主题(Topic)。

InfoQ 采访了 JBoss Messaging 项目领导人(Ovidiu Feodorov)和技术领导人(Tim Fox),深入了解这个最新发布版以及他们对 JMS 和 SOA 的总体看法。

InfoQ:首先祝贺 1.2.0 版本的发布。请二位向大家简单介绍一下自己,以及你们在 JBoss Messaging 团队里面承担的角色好吗?

Ovidiu:谢谢。我叫 Ovidiu Feodorov,是这个项目的创始人和领导人。自从 2004 年项目诞生以来,我一直在领导这个项目。这些年来,我们项目的代码行数从一无所有增长到接近 30 万行,并且经历了两次主要的通用版本(General Availability)发布。

我们是一个小型团队,到这次采访为止我们只有 3 个人,所以我认为我们并不能算一个合理“分层”的团队,拥有非常明确而不重合的角色和责任。整个团队看起来更像一个起步公司,所有人都在为推动项目前进而努力。因此,我参与代码编写,组织并参加设计会议,撰写文档,回答讨论组中的提问和支持请求,维护 Wiki,进行授课讲解,在必要时进行站上咨询,在用户会议和技术大会上推广 Messaging,做任何这么一个小团队需要我去做的事情。在这些角色中,最让我乐在其中的事情就是保证整个团队紧密配合,专注于我们的“使命”,也就是编写出全球最优秀的消息传送系统。

Tim:我的名字叫做 Tim Fox,加入 JBoss 约有 18 个月。在此期间,我把所有的精力都投入到了 Messaging 上。在加入 JBoss 以前,我是开源 JAIN SLEE 1.0(Telco 应用服务器)第一个实现的共同作者之一。目前我是项目的技术领导人,就是说我的责任是引导项目技术方向。本质上说,这意味着我需要去肩负审视技术实质的技术架构、设计和其他问题的责任。

InfoQ:你们认为这个发布版和以前的 JBoss Messaging 在可靠性和性能方面相比感觉如何?

Tim:大部分 1.2 版 codebase 是基于 1.0 版 codebase 开发的,因此我们是在一个已经于全世界许多生产系统中广泛使用的基础架构之上进行构建的。对于可靠性,我们一贯采取十分谨慎的态度,但我们在 JBM 1.2 中与 JBoss Transactions 的整合更进了一步,所以现在使用 JBM 进行任何 XA 事务性操作都会具有很高的持久性。也就是说,我们着重实现了 ACID 的“D” 属性(Durability,持久性)。

在性能方面,我们使用一个性能测试框架,它可以对所有与 JMS 1.1 兼容的系统进行测试。结果表明,JBM 的性能几乎在每一个方面都将 JBossMQ 远远甩在身后。

Ovidiu:1.2.0 GA 是“带集群的版本”。1.0.0(以及随后的 1.0.x 系列)是一个完全和 JMS 1.1 兼容、不支持集群的消息代理,而 1.2 超越了 JMS 规范,并加入诸如容错和负载均衡等企业级能力,并保持其完整的 JMS 1.1 兼容性。

新的 1.2 消息传送代理包含完全分布式的消息接收站、动态负载均衡和透明故障转移功能、零单点故障和零单点瓶颈、完善且完全可配置的消息过期处理,以及 XA 事务恢复等机制。

此外,1.2 提供对可插拔传输层(Pluggable Transports)支持,也就是 HTTP 和 HTTPS。从技术角度准确说来,其实在 1.0.x 系列已经这项功能已经存在。不过直到 1.2 我们才完全激活和测试了 HTTP 与 HTTPS 支持,还加入一个新的性能“Bisocket”传输层来简化管理,并使我们处理防火墙更加容易。

回顾起来,现在我认为这个发布版更应定为 2.0,因为我们已经为它引入了很多新的功能。

InfoQ:你们认为这个发布版和以前的 JBoss Messaging 在可靠性和性能方面相比感觉如何?

Ovidiu:这个发布版其中一个主要改进是,它支持横向扩展性:我们可以无缝地为集群加入更多节点,使得消息的处理拓展到更多物理节点之上。在和单节点性能相关的部分,最初的 1.0 代码中进行过几次重构。我们从根本上改变了包含主要消息传递路径的核心通道机制。尽管 1.2.0 在性能方面可圈可点,它仍然存在许多优化的余地。这也是后续的 1.2.1、1 .2.2、2.0、3.0 等等所要做到的事情。

对于我们的性能框架,还有我们计划用于追踪跨版本性能度量改进的“性能测试”概念,我们相当引以为豪。功能测试所采用的是同一种方式,可以告诉你 API 的实现存在问题。如果我们破坏了实现,使它的性能低于比原来版本,那么性能测试将触发警钟。如果你希望了解我们测试框架背后的概念以及如何使用它,请看这里

在可靠性方面,这个“集群”版本 和1.0.x 系列存在根本性区别。对于1.0.x 代理,故障对于管理员来说意味着他必须重启服务器实例,然后客户端代码监测故障,查找新的连接工厂(Connection Factory),重新建立连接等等。在1.2 里就不同了,故障被透明地处理,客户端甚至觉察不到连接发生故障(除非客户端注册一个特殊监听器)并且被转移到另外一个备用节点上。

InfoQ:提到 JMS 和 JBoss(或者应该叫 Red Hat?),大多数人会想到 JBossMQ。尽管它很流行,但存在一些广为人知的缺陷,因此许多人不得不专向其它方案。这是不是 JBoss Messaging 诞生的原因?

Ovidiu:是的。回到 2004 年 4 月,JBoss Messaging 诞生以前,我在奥提汀参见了一个设计会议。会上我、JBoss 首席科学家 Adrian Brock、JGroup 创始人 Bela Ban 和 Ivelin Ivanov 讨论了“消息传送的局势”,并试图确定到底是为现有的 JBossMQ 打补丁,还是将其弃之一隅,并从头打造一个全新的实现。当时我在 JBoss 还算新人,“拍照设计(design by photography)”的火候还不到家,所以那次会议我没有留下记录。不过我可以让你看看另外一些好东西——2004 年 12 月在奥斯汀拍摄的设计图表,当时和 Adrian Brock 一起,我们对新设计进行了第一次评审。从以下地址可以找到这些照片: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingDesingMeeting20041203 。有兴趣的人可以通过这个地址了解到关于 JBoss Messaging 设计会议颇为完整的历史记录: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingDevelopmentMeetings

回到原来 JBossMQ 对 Messaging 的问题上来,我们总结出,JBossMQ 存在两个最基本的局限性。其中之一就是,高可用性对于 JBossMQ 只是事后追想。SynderMQ 是 JBossMQ 所基于开源项目,本质上这是一个不支持集群的代理。另外一个局限与非集群代理本身的线程模型和总体设计有关,这也导致在某型高负载使用场景中的性能缺陷。

那时候,我们认为解决这些根本性问题或者给它们打补丁,要比一切从头开始麻烦得多,正是这个决定导致了 JBoss Messaging 的诞生。现在,整整三年过去了,我们经历了两次主要的 Messaging 发布。到底这个决定正确与否,还要由我们的用户来检验。

InfoQ:JBoss Messaging 和 JBossMQ 相比如何?

Ovidiu:JBoss Messaging 是一个从头开始设计的 JMS 代理,在设计之初就考虑了企业特性。最开始我们是基于这样一个假设来设计 Messaging 的:它是一个完全支持集群、负载平衡且高度有效的代理。如我前面所说,JBossMQ 从一开始就是个不支持集群的 JMS 代理,它的 HA 功能实际上是以 HA 单例机制(HA Singleton Mechanism)的形式“拧上”的。

一个 JBoss Messaging 接收站(不管是队列还是主题)可以存在于不同的地址空间,散步到多个虚拟机和物理主机上,提供无缝负载分布和透明故障转移,而所有的 JBossMQ 接收站都被装载同一个 VM 上。如果这个 VM 出现故障,HA 单例机制会在集群的另一个节点启动一个新的 JBossMQ 实例(每个集群只有一个),并重新在那个节点上重新创建所有接收站。这样客户端享受不到透明故障转移所带来的好处,它们必须自己侦测故障,然后重新建立连接。

从本质而言,JBossMQ 是一个“单点故障”,但由于代理可以从故障恢复而在一定程度得到缓和,同时它也是一个“单点瓶颈”,而 JBoss Messaging 则没有这些局限性。

InfoQ:你们认为 JMS 与 SOA 有多大的联系?特别在人们看起来更愿意选择 Web 服务作为部署平台的情况下?

Ovidiu:MOM(Message Oriented Middleware,面向消息的中间件)作为整合松耦合系统的方式,问世已经有很长一段时间了。从历史角度上说,存在文件传输、数据库、RPC 系统和 MOM 几种方式。近年来,Web 服务出现,加入了这支队伍。所有这些方案都有它们的优势和不足,要决定使用它们中一种或者几种方案的组合,常常需要周密细致的权衡。

在标准级别的互操作性,是 Web 服务所具备但消息传送系统所缺乏的。作为标准,JMS 所欠缺的是对互操作性的考虑。JMS 规范尚未规定到消息传输格式这个程度,因此,每个供应商可以自由地引入自定义格式,并按照自己认为最合适的方式来优化实现。这当然不是说我们不能去编写桥接程序,但问题在于它们不能现拿现用。尽管如此,在这个地平线上还存在一丝曙光。AMQP,一个由 Red Hat 和其它公司一起推动的全新消息传送协议,正是面向互操作性问题而来的。让我们拭目以待吧。

这就是说,Web 服务和 MOM 都有各自最为合适的使用场合和具体的应用领域。

InfoQ:你们刚才提到 Red Hat 参与的另一个消息传送协议,高级消息队列协议(Advanced Message Queuing Protocol,AMQP)。它和 JBoss Messaging 之间存不存在一定重合呢?

Ovidiu:JBoss Messaging 是消息传送代理的一个实现,而 AMPQ 是规范。如果哪个实现具有重要意义,那它最终总是会被扩展成规范的。在仔细考察了 AMQP 规范之后,我只能这么评价:规范引入的服务端模型和 JBoss Messaging 内部架构完全吻合。我们差不多可以这么说,JBoss Messaging 打算在 AMQP 最终定案之后(目前版本号还是 0.9)将其实现,并能和其它 AMQP 实现进行良好的互操作。

Tim:AMQP 的确是个非常有意思的新协议。毫无疑问,我们将不断关注它的进展。我相信它的根本原则是值得信赖的,在目前 JMS 解决方案间尚不存在传输格式兼容性的问题上尤为如此。目前规范仍然处于完善阶段,尚未涵盖 XA 事务,也缺乏 JMS 和 AMQP 之间的明确映射,来确保在 AMQP 基础上开发的 JMS 解决方案间的互操作性。但我相信这些问题都在解决之中。我认为,AMQP 进入黄金期还为时尚早,但几乎可以肯定,大约一年之后它将大放异彩。

2007-03-31 23:301316
用户头像

发布了 117 篇内容, 共 15.1 次阅读, 收获喜欢 0 次。

关注

评论

发布
暂无评论
发现更多内容

华秋慕尼黑上海电子展圆满收官,数字化赋能智能制造!

华秋电子

不懂代码也不用怕!10款无代码网站搭建平台

高端章鱼哥

前端 工具 开发工具 设计师

开鸿智谷与华秋达成生态共创合作,共同打造硬件生态

华秋电子

低代码和无代码平台可以加速应用程序现代化

这我可不懂

软件开发 低代码 无代码 应用程序

点云标注中的隐私保护和数据安全问题

来自四九城儿

直播预告 | 博睿学院:让Arthas带你玩转jvm

博睿数据

JVM 可观测性 智能运维 博睿数据 博睿学院

点云标注在自动驾驶中的实践应用与挑战

来自四九城儿

实现大文件远程传输、备份和共享的小秘诀

镭速

大文件远程传输

aspera替代方案:可靠和高效的企业文件传输工具

镭速

aspera替代方案 企业文件传输工具

在《比特与瓦特》的交点,藏着未来能源的一些真相

脑极体

新能源

深开鸿与华秋达成生态共创合作,共同打造硬件生态

华秋电子

软通动力与华秋达成生态共创合作,共同推动物联网硬件创新

华秋电子

先楫半导体与华秋达成生态共创合作,共建技术生态社区

华秋电子

在云计算环境中,保护Java应用程序可用的有效措施和工具

高端章鱼哥

Java 云计算

有哪些好用的远程传输大文件的软件

镭速

远程传输大文件

IBM收购数据可观测性厂商 Databand.ai

乘云 DataBuff

如何使用API网关和OPA实现RBAC

这我可不懂

API rbac OPA

低代码技术分享官丨BPMN 2.0简介

inBuilder低代码平台

流程 低代码平台

HashData:让大模型“飞入寻常百姓家”

酷克数据HashData

LeetCode题解:2618. 检查是否是类的对象实例,迭代和递归

Lee Chen

JavaScript LeetCode

向量检索在大模型应用场景的技术和实践

Baidu AICLOUD

向量检索 大模型

MES1.0.0正式发布|万界星空推出免费的MES系统

万界星空科技

开源 MES系统 制造业生产管理系统

软件测试 | Java语言的特点

测吧(北京)科技有限公司

测试

软件测试/测试开发丨Linux常用命令之性能统计

测试人

Python Linux 程序员 性能 软件测试

润和软件与华秋达成生态共创合作,共同推动物联网硬件创新

华秋电子

将DAST集成到CI/CD管道中的优势和实施步骤

互联网工科生

CI/CD DAST web 服务

软件测试/测试开发丨Python 数据类 dataclass 学习笔记

测试人

Python 软件测试 dataclass

开发微信公众号本地调试+-+cpolar内网穿透

程思扬

微信公众号 网络穿透

应对突发流量,如何快速为自建 K8s 添加云上弹性能力

阿里巴巴云原生

阿里云 Kubernetes 云原生

国内市场知名的数据可视化工具

2D3D前端可视化开发

数据分析 数据可视化 商业智能 数据可视化工具 可视化大屏

JBoss Messaging羽翼渐丰 支持集群和透明故障转移_Java_Floyd Marinescu_InfoQ精选文章