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

前言

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