跳至主要內容

如何看待消息中间件的选型

朱小厮架构运维消息中间件大约 7 分钟

前言

近来有很多网友留言:公司要做消息中间件选型,该如何选?你哪个比较好?我的回答一般是:It's a nice topic~如果随意回答一个的话显得很不严谨也不太负责任,如果严谨的回答的话一天就不用干活了。消息选型的确是一个大论题,实则说来话长的事情又如何长话短说。被问的越多越觉得需要整理一篇自己的观点出来,主要的目的将自己的经验分享出来,可以让别人少踩点误区,次要的目的是下次再被问到了可以直接甩链接而不用再打太极(如果你后者觉得这是主要目的话,那么我只能回答:橘生淮南则为橘,嘿嘿~~)。不过本文的主要内容为观点表达(别名:“吹水”),不涉及具体的技术细节。

历程

目前大多数所用的、所讨论的(Fashion的)消息中间件大致为Kafka、RabbitMQ和RocketMQ这三种,本文尽量站在一个中立的视角上去看待这个问题。当然如果你说市面上的MQ多了去了,比如还有ActiveMQ、ZeroMQ呢,这点我也不否认、不反驳,也不接茬~

关于消息中间件(下文会时不时的以MQ作为简称)的玩法,或者更贴切的称为使用历程大致可以分为四个阶段:

  • 大多数情况下基于时间、成本、技术栈等等考虑都会直接使用一种(或者多种)成熟的开源消息中间件。当然在选择之前一般也会做一些调研,不一样的选择意味着未来踩不一样的坑。很多初创型公司也会选择直接购买MQ的云服务,这不失为省钱的一个好办法。
  • 随着对消息中间件的了解以及业务需求的发展,基于现有的消息中间件来说无法完全满足目前的需求,这时候最好的方式就是对消息中间件本身做深度包装(也有可能再换一种MQ继续耍),最好是做成平台化的、以监控和管理等为一体的。
  • 当然也有团队选择自研。自研不是指拿一个开源的消息中间件出来随意“动两刀”,然后换个名称的假自研,而是大刀阔斧的对现有的消息中间件动刀或者是完全的功能自实现。至于自研具体原因其实有很多:是基于业务需求的拓展、还是现有的MQ无能力掌控、还是leader内心的躁动、还是KPI的压迫那就不得而知了,不过这的确是玩转消息中间件历程中不可或缺的一步。但这一步不是说比前面的两步绝对的高级,你完全可以简单对ArrayBlockingQueue做一个简单的封装而成为一个MQ,你也可以基于文件、数据库、redis等做封装而形成一个MQ,玩法随意、在“吹水”的同时能够不忘初心、真正落地即可。这一步的风险在于你基本脱离了生态社区的支持,自己挖的坑没人帮填;还有一个风险就是:老人离职、新人抓瞎。如果自研一个功能丰富的MQ的话,对人力、精力、财力都是不小的考验。
  • 最终极的当然是形成一定的规模体系、技术深度、生态口碑之后进行产品开源,技术来源于社区回馈于社区,既可以为公司做一定程度上的技术宣导,也可以提升自身境界。

选择

再回到本文的主题上来,个人对于消息的选型有3点看法:

  1. 没有蹩脚的MQ,只有蹩脚的coder 很多时候你会看到网上的文章说这个MQ不好,哪个MQ不好。比如经常有评论说Kafka容易丢消息,我的内心回答:滚~说Kafka消息可靠,我的内心回答:也滚~ 这个世界上的事物没有绝对的,关键在于你对MQ本身的掌握程度。新版的Kafka有很多机制能够保证消息的可靠性,容易丢失是coder玩不转,如果说消息绝对可靠也是错误的,即使不说机房被炸,那你也是没有遇到偷硬盘的贼哦~ 不管选择哪个MQ都会有坑,没有绝对的好坏优劣,关键在于coder的把控。如果一些功能其他的MQ有而你的MQ么有,那你可以做一些深度包装;如果你的MQ性能跟不上,那你可以试一试优化,或者分布式水平扩展等等。
  2. 基于当前及可见未来的需求 目前网络上的消息选型的对比文章,除非在文中严格限定了基于比较的版本,否则都是辣眼睛的,唾弃之。比如消息的幂等性,以前三大Fashion的MQ都不支持消息幂等性,所以很多选型对比类的文章在这一功能栏就写上了:不支持,现在最新版的Kafka就能支持一定程度上的幂等性,那么现在再看这篇文章的时候是不是觉得有槽点。再比如说RabbitMQ在消息大量堆积时会对性能产生影响,那你是没有调过优吧,你没玩过惰性队列吧。再比如流控、多租户、多语言支持、事务、可靠性等等方面的对比,Fashion的MQ时刻在level up,今天没有的、受限支持的功能或许明天就能实现。绝对的去评判哪个MQ好哪个MQ不好没有实际的意义,而是要根据实际的需求来做决定,多想想你的需求,有些业务需求对于某个MQ而言可以很容易的得到解决,而有些却是要山路十八弯,一个贴近需求的MQ选型可以让团队事半功倍。同时也需要考虑团队的技术栈,如果团队中对于某个MQ很熟悉,掌控力度很高,而对另一个MQ非常的陌生,如果此时选择是后者的话那就要多想想以后的路,路漫漫其修远兮~贴近需求,但也不要盲目的幻想需求,基于当前及可见未来的需求内而寻求能够落地的准则,没有最好的,只有最合适的,类似爱情~~
  3. 社区力度及生态发展 对于目前流行的编程语言Java、Python而言,当然还有宇宙最强的php,如果你在使用过程中遇到了某个Exception,那么去搜索引擎上随意搜索下就能找到很多解决方案。对于MQ而言同样可以使用,如果你选择的是一种Fashion的MQ,那么势必用的人很多,用的人多了踩出来的坑也就多了,顺其自然的解决方案也就多了,版本更新弥补的也多了,进而你就可以站在这些“巨人的肩膀”上了。相反如果你采用了一种生僻的MQ,有可能在某些方面用的很爽,但是版本更新缓慢、遇到棘手问题难以得到社区的支持,最后就只能“跪在地板上”抓瞎了。社区力度越大的MQ,更新力度也大,不仅可以填补旧版本的坑,也能时不时带来一些新功能,释放你的双手。当然消息的选型也要考虑下其生态的发展,能够在多个领域里大放异彩的MQ基本是好的MQ,也可以为你的职业发展多加点料。
上次编辑于:
贡献者: 程序猿DD