中国互联网热衷于“造轮子“!

在Github上查看消息队列的时候,那个专栏就透露:

京东已推出自己的消息队列产品 JMQ,并且将很快开源问世!

之后,我很少留意过 JMQ 的消息。今天偶然之间,看到去哪儿网也搞了一个消息中间件 QMQ。

根据去哪网的开发团队透露,QMQ 内部已经使用了 6 年。之所以,选择自研 QMQ 是因为当时并没有“优秀且适合去哪网“的 MQ。

首先因为技术栈去哪网排除了 erlang 开发的 RabbitMQ,而 Kafka 以及 Java 版 Kafka 的 MetaQ 在当时还并不成熟和稳定。

而 ActiveMQ 在去哪儿网已经有很多应用在使用了,但是使用过程中并不一帆风顺:宕机,消息丢失,消息堵塞等问题屡见不鲜,而且 ActiveMQ 发展多年,代码也非常复杂,想要完全把控也不容易,所以去哪网决定自己造一个轮子。

QMQ 目前在去哪网已进行了大量的使用。包括跟交易息息相关的订单场景;也包括报价搜索等高吞吐量场景。目前在公司内部日常消息 qps 在 60W 左右,生产上承载将近 4W+ 消息 topic ,消息的端到端延迟可以控制在 10ms 以内

“去哪儿网” QMQ 消息队列架构图

 

QMQ 主要提供以下特性:

  • 异步实时消息
  • 延迟/定时消息
  • 基于 Tag 的服务端过滤
  • Consumer 端幂等处理支持
  • Consumer 端 filter
  • 死信消息
  • 结合 Spring annotation 使用的简单 API
  • 提供丰富的监控指标
  • 接入 OpenTracing
  • 分布式事务
  • 消息投递轨迹
  • 历史消息的自动备份

看起来这都是一些很好的特性,但是依然被称为重复造轮子

每个造轮子的团队或程序员都有自己“不得不造”的理由。比如:

  1. 以为自己的需求独一无二,现有的库就是在某个点上满足不了
  2. 老轮子没有规格说明书,或者接口太复杂,不知道怎么用,搞明白太难
  3. 需要在老轮子上添加新功能,然而老轮子代码难读无人可问,不知道何时能弄明白,看不到结果,容易放弃
  4. 眼界有限,不知道已有这样的轮子
  5. 版权原因无法使用第三方库,比如Google Android实现JVM(Google曾因为一行代码而和Oracle打官司),比如阿里YunOS自己实现JVM
  6. 就想锻炼自己,因为造轮子对自己的设计、编码能力有很大好处,对理解业务也有很大好处
  7. 自己造轮子,有“控制感”,看得见摸的着,可以一步一步来,一个一个小目标迭代出大目标,不断成功的小激励,会带给自己前行的动力
  8. 创新成分多(对自己而言),有成就感
  9. 不相信老轮子,譬如老轮子可能有后门、漏洞(想想OpenSSL的心脏出血漏洞)、后期万一要修改没把握等,反正是觉得自己造轮子心里更踏实
  10. 不想让自己产品的关键技术掌握在别人手里,也不想让自己的核心用户数据流经别人的系统
  11. 别人的轮子不开放,我就是要赶紧造(山寨)一个出来以便获得话语权或商业利益

虽然,被调侃为造轮子,但是造轮子有造轮子的好处,那就是会多招一些程序员。同时,造轮子,挖的坑不好被替换,提升自己的竞争力,被裁员的风险可能就会小一些!

程序员造轮子也有特殊的学习意义,学习别人怎么造,了解内部机理,自己造造看,这也是非常好的锻炼机会。

最后,说一点,QMQ 开源后,可能我们在使用消息队列时就多了一种选择。但是,QMQ 的社区毕竟比较落后一些,遇到问题还真不一定能自己搞定。所以,在前期还是谨慎采用!