一款消息队列的客户端框架——启明信息车联网MQ演进实践分享

简介: 一款消息队列的客户端框架——启明信息车联网MQ演进实践分享 分享人:阿里云MVP曾宪宇,2014开始 就职于启明信息,负责车联网平台的架构和建设,坐标吉林长春。 分享内容:结合主流MQ,介绍一款基于Java的开源消息队列客户端框架。

分享人:阿里云MVP曾宪宇,2014开始 就职于启明信息,负责车联网平台的架构和建设,坐标吉林长春。
分享内容:结合主流MQ,介绍一款基于Java的开源消息队列客户端框架。

在不同阶段,如何选择合适的MQ?

image
这几年随着物联网的发展,对消息中间件的应用越来越广泛,像ActiveMQ、RabbitMQ、阿里的RocketMQ、Kafka、雅虎的Pulsar等这些开源消息中间件,在不同的行业和系统中都担任着重要的角色。关于这些MQ的资料,也很容易搜索到,但有很多将它们之间进行对比。在此说一下我的个人看法,因为每一款MQ专注的地方和发展路径以及它的优势都不一样,所以没有绝对的可比性。我们的系统要使用这些中间件,一定是为了解决某些问题,所以就要选择最适合的。
image
下面介绍我们在使用消息中间件的演进历程,可能很多数公司都有相似之处。
主要分了三个阶段,而每个阶段的诉求都不一样,所以要使用不同的MQ:
第一阶段:需要一个与平台无关并且能够支持多协议的MQ,因为是异构系统,而且上下游不同的技术栈,上游是C++,下游是Java系统,所以中间使用ActiveMQ进行异步通讯。
第二阶段:建设车辆网IOT,因为高并发量和数据量,需要一个高吞吐中间件,此时ActiveMQ就不合适了,并且Kafka和大数据生态组件结合的比较好,像Strom/Spark/Flink一些流计算框架对Kafka支持也比较好。其实做物联网(IOT)的小伙伴应该比较清楚,从终端设备采集上来的数据质量其实是很差的,可能是因为强弱电或者网络的一些关系,会照成部分数据的丢失和不准确,基本上是在数据接入之后,甚至落地之后,通过一些算法和模型来提高数据质量,其实考验IOT中间件最重要的不是数据的可靠性,而是数据的接入能力和处理能力,所以Kafka是当时一个不错的选择。
第三阶段:我们的部分业务想移植到共有云上,需要一个款面向云原生,具备自动化能够弹性伸缩的MQ,对Kafka比较了解的同学应该知道,Kafka的Topic和Partition不建议太多,过多的磁盘IO会严重影响broker端的写入性能,而且又因为broker是和存储绑定在一起,扩展和减少kafka集群需要对分区rebalance,这些,其实是很头疼的,而 RocketMQ是把数据都顺序写入了一个文件(commit log),很好的解决了这些问题,而且当时公司也更倾向于阿里云,不过这部分业务因为一些原因搁置了。
image
在MQ演进的过程中,就会面临一个问题和思考:如果能让应用快速切入,想要在不改动业务代码的情况下,可以在不同的消息中间件间切换,也就是说需要一个公共的API,这就是消息队列客户端框架初衷和想要解决的问题。

消息队列客户端框架实践分享

image
这款消息队列客户端框架,开源在GitHub上。
项目主页:http://www.darkphoenixs.org/message-queue-client-framework/
Maven的中央仓库也可以下载,目前最新版本1.5.8

<dependency>
    <groupId>org.darkphoenixs</groupId>
    <artifactId>messagequeue-framework</artifactId>
    <version>x.x.x</version>
</dependency>

(说到开源框架,一般都有一个响亮或者洋气的名字,但是作者本身比较词穷,所以这个框架的名字就叫做消息队列客户端框架:Message Queue Client Framework)
image
这个框架设计之初非常简单,就抽象出这么几个接口:

  • Producer:通过send方法发送消息
  • Consumer:通过receive方法接收消息
  • Encoder和Decoder:定制消息序列化和反序列化

这样一个最基本的生产消费模式就出现了,基于这些接口用户就可以根据自己的业务开发完成消息的收发功能了。
具体代码示例可以参考:https://github.com/DarkPhoenixs/message-queue-client-framework/wiki/Configuration-Examples

image
对于Kafka Consumer的增强,作者是从Kafka 0.8.x版本开始使用Kafka的,那个时候的kafka还只是分布式消息中间件,在使用和开发过程中的一个感受就是Kafka的API真的是过于“简单”,尤其是Consumer端的API,只提供一种poll方式让用户自由发挥,这样使用者需要额外做很多工作,再加上非常奇怪的4位版本号,曾经一度认为Kafka是Linkedin内部的阉割版,后来感觉这可能是和kafka的设计思想有关系,有句话好像是这么说的:“在计算机领域,一些比较复杂的问题,往往是不需要解决的”,那既然这样总要有人来做,所以框架对Kafka Consumer做了一些特性增强。
image
一个最主要的特性是消费模式的增强,分了两种模式:
MODEL_1:是默认的模式,每一个线程消费一个分区(partition)的数据,缺点就是并行度受限于Topic的分区总数,
MODEL_2:之前也说过kafka并不适用于过多分区;所以把消费线程与处理线程分离,在消费线程受限的情况下,增加处理线程能够有效提高吞吐量,但是缺点就是不能保证消息顺序。
image
然后还有批量处理的特性,
NON_BATCH:默认是非批量的,一条一条的处理。
BATCH:在批量场景下使用批量处理能提高消费端的处理能力,比如批量入库。
image
Message Retry,这是一个容错机制,就是消息处理出现异常时,可重新处理,能提高了数据可靠性,但是目前仅在非批量处理时可用。
(这些特性只是针对kafka增加,并没有对 RocketMQ做增强,因为RocketMQ已经具备了这些特性,所以框架没有过多封装,API和配置尽量全都用的它自己的。)
image
至于为什么不封装成一套统一的API,所有的接口和配置全都由框架实现,从代码层面就让MQ完全透明(Spring Cloud的做法),因为封装过度会产生一些问题:
一方面是可能会屏蔽原因特性,因为随着MQ的迭代升级,肯定会有些新特性,如果框架无法跟上MQ的迭代速度,这些新特性可能会被屏蔽,而且未来的维护成本也很巨大。
另一方面就是性能,框架过度封装,本身就会占用很多资源,肯定会影响性能。
image
针对这个框架进行了性能测试和性能对比,以Kafka客户端为例,因为对kafka的API封装的比较多。对直接使用Kafka API、使用客户端框架、和使用spring cloud stream做了对比。
测试服务器用的是阿里云的ECS 4核8G,测试场景完全一样。
Kafka Native API:TPS 80W+
Client Framework API:TPS 80W-
Spring Cloud API:TPS 10W+
从测试结果上来看性能差距还是很大的,所以如果对吞吐和成本有很高要求,其实不建议使用Spring Cloud,不过Spring Cloud封装的确很好,使用也非常方便,所以就要自己衡量了,就像很多在开源微服务框架技术选型上,最终还是放弃Spring Cloud,而使用Dubbo是一个道理,即便是Spring Cloud提供了非常丰富的微服务套件。
image
最后分享一个大件事,OpenMessaging,在2017杭州云栖大会,由阿里和其他几家公司共同发起的分布式消息领域的国际标准。
目标打造厂商中立,面向云原生,对流计算和大数据生态友好的分布式消息标准,未来就可以在不同厂商的产品和平台之间进行无缝迁移。
目前RocketMQ和Pulsar完成了对OpenMessaging支持,后续会推动更多消息中间件厂商落地该标准。

结束语:目前这个消息队列客户端框架只支持ActiveMQ、RocketMQ和Kafka,接下来也会考虑把OpenMessaging集成到这个框架里面,如果感兴趣的小伙伴也可以加入进来,非常的欢迎,一起把它完善的更好。

相关实践学习
消息队列RocketMQ版:基础消息收发功能体验
本实验场景介绍消息队列RocketMQ版的基础消息收发功能,涵盖实例创建、Topic、Group资源创建以及消息收发体验等基础功能模块。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
相关文章
|
3月前
|
消息中间件 JSON Java
开发者如何使用轻量消息队列MNS
【10月更文挑战第19天】开发者如何使用轻量消息队列MNS
242 11
|
3月前
|
消息中间件 安全 Java
云消息队列RabbitMQ实践解决方案评测
一文带你详细了解云消息队列RabbitMQ实践的解决方案优与劣
124 10
|
2月前
|
消息中间件 存储 Kafka
MQ 消息队列核心原理,12 条最全面总结!
本文总结了消息队列的12个核心原理,涵盖消息顺序性、ACK机制、持久化及高可用性等内容。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
|
3月前
|
消息中间件
解决方案 | 云消息队列RabbitMQ实践获奖名单公布!
云消息队列RabbitMQ实践获奖名单公布!
|
3月前
|
消息中间件 存储 弹性计算
云消息队列RabbitMQ实践
云消息队列RabbitMQ实践
|
3月前
|
消息中间件 存储 监控
解决方案 | 云消息队列RabbitMQ实践
在实际业务中,网站因消息堆积和高流量脉冲导致系统故障。为解决这些问题,云消息队列 RabbitMQ 版提供高性能的消息处理和海量消息堆积能力,确保系统在流量高峰时仍能稳定运行。迁移前需进行技术能力和成本效益评估,包括功能、性能、限制值及费用等方面。迁移步骤包括元数据迁移、创建用户、网络打通和数据迁移。
90 4
|
4月前
|
消息中间件 弹性计算 运维
云消息队列RabbitMQ实践
本评测报告详细分析了阿里云云消息队列 RabbitMQ 版的实践原理、部署体验及核心优势。报告认为其在解决消息积压、脑裂难题及弹性伸缩方面表现优秀,但建议进一步细化架构优化策略和技术细节描述。部署文档详尽,对初学者友好,但仍需加强网络配置和版本兼容性说明。实际部署展示了其高可用性和成本优化能力,适用于高并发消息处理和分布式系统数据同步。为进一步提升方案,建议增加安全性配置指导、性能调优建议及监控告警系统设置。
|
4月前
|
消息中间件 监控 数据处理
解决方案 | 云消息队列RabbitMQ实践
解决方案 | 云消息队列RabbitMQ实践
60 1
|
3月前
|
消息中间件 监控 测试技术
云消息队列RabbitMQ实践 - 评测
根据反馈,对本解决方案的实践原理已有一定理解,描述整体清晰但需在消息队列配置与使用上增加更多示例和说明以助理解。部署体验中获得了一定的引导和文档支持,尽管文档仍有待完善;期间出现的配置文件错误及依赖库缺失等问题已通过查阅资料解决。设计验证展示了云消息队列RabbitMQ的核心优势,包括高可用性和灵活性,未来可通过增加自动化测试来提高系统稳定性。实践后,用户对方案解决问题的能力及适用场景有了明确认识,认为其具有实际生产价值,不过仍需在性能优化、安全性增强及监控功能上进行改进以适应高并发和大数据量环境。
59 0
|
6月前
|
消息中间件 C语言 RocketMQ
消息队列 MQ操作报错合集之出现"Connection reset by peer"的错误,该如何处理
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。

相关产品

  • 云消息队列 MQ