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

标签: 技术杂记 转载 消息中间件 选型 | 发表时间:2018-03-12 08:29 | 作者:
出处:http://blog.didispace.com/

前言

近来有很多网友留言:公司要做消息中间件选型,该如何选?你哪个比较好?我的回答一般是: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,也可以为你的职业发展多加点料。

相关 [消息 中间件] 推荐:

消息中间件的比较-转载

- - 人月神话的BLOG
原文: http://www.orientware.org/viewArticles.do?action=browse&columnId=29&id=22&flag=home. 消息中间件(message oriented middleware)是指支持与保障分布式应用程序之间同步/异步收发消息的中间件.

[转]面向消息的中间件

- - junecauzhang的专栏
Unique integration with the database allows AQ to inherit the reliability, security, and integrity of the Oracle Database, and provides the necessary message management features for eBusinesses.

消息中间件事务处理

- - 开源软件 - ITeye博客
假设消息中间件没有提供“事务消息”功能,比如你用的是Kafka. (1)Producer端准备1张消息表,把update DB和insert message这2个操作,放在一个DB事务里面. (2)准备一个后台程序,源源不断的把消息表中的message传送给消息中间件. 允许消息重复,但消息不会丢,顺序也不会打乱.

中间件技术及双十一实践·消息中间件篇

- - 阿里中间件团队博客
消息中间件——分布式消息的广播员. 消息中间件是一种由消息传送机制或消息队列模式组成的最典型的中间件技术. 通过消息中间件,应用程序或组件之间可以进行可靠的异步通讯来降低系统之间的耦合度,从而提高整个系统的可扩展性和可用性. Notify是淘宝自主研发的一套消息服务引擎,是支撑双11最为核心的系统之一,在淘宝和支付宝的核心交易场景中都有大量使用.

消息中间件的技术选型心得-RabbitMQ、ActiveMQ和ZeroMQ

- - haohtml's blog
RabbitMQ、ActiveMQ和ZeroMQ都是极好的消息中间件,但是我们在项目中该选择哪个更适合呢. 下面我会对这三个消息中间件做一个比较,看了后你们就心中有数了. RabbitMQ是AMQP协议领先的一个实现,它实现了代理(Broker)架构,意味着消息在发送到客户端之前可以在中央节点上排队.

淘宝开源分布式消息中间件Metamorphosis

- - InfoQ cn
最近,淘宝开源了分布式消息中间件 Memorphosis项目,它是Linkedin开源MQ——Kafka的Java版本,针对淘宝内部应用做了定制和优化. 据了解,Metamorphosis(以下简称Meta)的设计原则包括:. 分布式,生产者、服务器和消费者都可分布. Metamorphosis的总体 架构图如下:.

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

- - 程序猿DD
近来有很多网友留言:公司要做消息中间件选型,该如何选. 我的回答一般是:It’s a nice topic~如果随意回答一个的话显得很不严谨也不太负责任,如果严谨的回答的话一天就不用干活了. 消息选型的确是一个大论题,实则说来话长的事情又如何长话短说. 被问的越多越觉得需要整理一篇自己的观点出来,主要的目的将自己的经验分享出来,可以让别人少踩点误区,次要的目的是下次再被问到了可以直接甩链接而不用再打太极(如果你后者觉得这是主要目的话,那么我只能回答:橘生淮南则为橘,嘿嘿~~).

互联网网站架构升级----消息中间件的实现方案

- liu - ITeye论坛最新讨论
    最近一直比较忙,前面设计的架构完成了基本的实现,最近工作重心发生了点转变,偷闲来继续前面的话题;.     这一篇博客准备聊聊消息系统,消息中间件对目前大中型互联网来说是非常重要的,在业务数据流动中仅次于RPC服务调用,担负着越来越复杂的网站业务从主流程上解耦的重要责任;.     从目前互联网对消息中间件的需求来看应该分为两种类型,一种是和钱相关的需求,一种是和钱无关的需求;和钱相关的需求消息的可靠性是放在第一位的,和钱无关的需求是速度放在第一位的,但这两种需求又是矛盾的,很难设计出一种既可靠又高效的系统,除非将两套方案捏合成一个系统,通过配置来选择不同方案,但从实现上说还是两种实现.

[转][转]使用 Apache MINA2 实现 Web 系统的消息中间件

- - heiyeluren的Blog
来源: http://www.ibm.com/developerworks/cn/web/1108_sumeng_mina2/index.html. 本文将介绍如何使用 Apache MINA2(以下简称 MINA2)解决复杂 Web 系统内各子系统之间同步消息中间件的问题. MINA2 为开发高性能和高可用性的网络应用程序提供了非常便利的框架.

消息中间件选型分析——从Kafka与RabbitMQ的对比来看全局

- - 程序猿DD
有很多网友留言:公司要做消息中间件选型,该如何选. 消息选型的确是一个大论题,实则说来话长的事情又如何长话短说. 对此笔者专门撰稿一篇内功心法: 如何看待消息中间件的选型,不过这篇只表其意未表其行,为了弥补这种缺陷,笔者最近特意重新撰稿一篇,以供参考. 温馨提示:本文一万多字,建议先马(关注)后看.