顾庆：携程自主研发消息系统Hermes

个人简介 顾庆,携程框架研发部高级经理，负责消息系统等基础设施的研发工作，有多年消息系统开发和运营经验。当前负责的携程新一代开源消息系统Hermes(https://github.com/ctripcorp/hermes)刚刚完成研发，正在随着多个重要业务项目的架构改造展现威力。此前在大众点评和百度从事架构和中间件相关的工作，参与过点评消息系统、云平台、软路由、架构组件独立发布系统以及百度凤巢系统的研发。有丰富的Java开发和使用经验，是Java的忠实拥护者，长期关注架构及Java相关技术的发展。是一个忠实的果粉，业余喜欢各种球类运动及DOTA。

QCon是由InfoQ主办的全球顶级技术盛会，每年在伦敦、北京、东京、纽约、圣保罗、杭州、旧金山召开。自2007年3月份首次举办以来，已经有包括传统制造、金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。

   

1. 大家好，这里是2015上海QCon的现场，我们今天非常荣幸地邀请到携程框架研发部的高级经理顾庆老师，顾庆老师是Qcon的老朋友了，最近两三年的QCon都有顾庆老师的身影。这次他带来了异步消息系统的分享。我们现在对他进行一次现场采访，让他给我们聊聊更多关于这个消息系统的干货。那么先请顾庆老师介绍一下自己，让更多的同行能够认识他。

0顾庆：大家好，我叫顾庆，来自那个的新型的研发部，确实是InfoQ的老朋友了，应该来过两三次了，应该，InfoQ第一次在上海的时候就过来参加了，那个时候还在大众点评。那之前的话，我是在百度，那这几年一直都是在做框架架构相关的这样一些工作，那现在是在携程，大概带领十几个人这样一个团队，主要是做消息，监控这样一大块，今天很高兴能够到InfoQ来跟大家分享一下我们做这个消息队列这样一些情况。

   

2. 这个消息系统产品的名字很高大上，它叫“Hermes”（爱马仕）。顾老师请跟我们聊一下Hermes与市场上目前比较主流的一些开源的MQ，比如像ActiveMQ、RabbitMQ等有什么区别，是什么促使携程选择走自主研发这条路的？

顾庆：我先解释一下这个Hermes这个名字的来源。我们的项目名称是走希腊的神，然后找了一圈发现Hermes其实是一个姓氏，跟我们这个消息队列非常吻合的，所以我们叫Hermes，那么我也是希望他能够做成消息队列里面的贵子。

刚刚提到跟其他的一些消息系统的比较，其实我们之前也用过很多消息系统，包括像ActiveMQ、RabbitMQ等都会用到。我们觉得有两个非常重要的问题，一是稳定性没有达到预期，经常会出现莫名其妙的一些问题，我们没有办法100%掌控。一旦推广到业务那边去，出现问题后完全没有办法去控制。另外一个问题是，我们希望消息系统的监控是非常的完善的，因为在企业里面用，不仅是性能和吞吐量，监控和治理那块长期来说也是最重要的。所以我们宁愿在前期多投一点时间，来换取后面运维的能力。

   

3. 顾老师能不能谈一下Hermes带来了哪些优势，Hermes本身还有没有一些别的特性？

顾庆：这里说一下背景，携程是以.Net技术站为主的，基本上80%都是走.Net客户站，现在很多应用都是想有这样一个消息系统，很多开源技术站都是Kafka消息站的，包括像Storm，ES，都跟Kafka天然集成。.Net有个短板，它不提供原生驱动，它只有一个第三方给的，功能不完全，有很多一些Bug，是用不了的。那么用了Hermes以后，其实还有个优点就是.Net的一些技术站可以通过Hermes做一个中转，来跟Kafka打通，然后打通后面的一整套生态系统。

   

4. 现在业界有很多消息服务相关规范，比如像JMS，MQP， Hemes会不会去实现它们。你是怎么看到这些规范的，基于怎么样的考虑呢？

顾庆：Java有JMS规范，包括原来像ActiveQ等会有一套规范。还有一套是业界开源的MQP规范。JMS比较老，现在基本上也不太更新，很少有去Follow它的，它的理念，它的模型，跟我们现在都不太一样，我们不会去Follow它。MQB我们当初也看过，Kafka它为什么没有去走这个MQB协议，还是它规定的模型跟我们想解决的事情其实不是同一个范围，我们可能想解决的范围会更大。强行嫁接到这个协议的话，除了一些客户端能够支持它外，其实没有什么特别的好处，所以我们暂时是不会考虑嫁接到这样两个协议上去。

   

5. 那在研发的过程当中，我们在性能优化方面有过什么样的考虑，比如说做过什么样的调优？

顾庆：性能方面的话，我们一开始是希望Hermes能够有两种存储，一种是基于数据库的，我们用的是MySQL。另外一方面，我们希望它能够支持文件存储，像Kafka一样。我们认为基于文件跟基于MySQL各有优势。MySQL后面有一整套非常完善的运维治理，它的性能也优化得非常好。文件相对来说会做得比较重，它虽然性能好，但很多事情，比如同步，都要自己去做。外界诟病这样的一种方式也是觉得基于文件的方式太重了，也不太可控，很多事情没有办法去控制。我们也遇到过，前几天Kafka刚刚报出一个Bug，就是它会无缘无故地把一些partition删掉，就是同步有一些问题，这个bug它们也确认了。所以这个东西做得重了以后，会有很多问题出来。所以我们实际上是基于MySQL的，MySQL后面一整套技术非常成熟，我们是在它上面做一些业务，现在很多优化放在MySQL这边，当然我们也为后面基于文件的优化做了很多考虑，包括ZeroMQ、Zero-Copy、对外的内存等这些技术我们都会用到。在MySQL这边我们做了很多事情，包括说很多消息缓存，减少了的很多的轮循。在表的设计上，我们尽可能减少索引，继续做Insert，等等，就是希望能够把MySQL用成像一个文件那样，把它用的非常轻，然后发挥它最大的效果。

   

6. 经过顾老师刚才的介绍，我觉得大家应该对消息队列的一些特性有所了解了。顾老师能谈谈开发这个消息系统的团队，以及这个系统后续的发展规划吗。我注意到，Hermes已经在GitHub上面开源了，接下来在开源方面有什么打算？

顾庆：我们的话，其实做了蛮久的框架，和中间件，其实我们的项目一直是放在GitHub上的，因为这个项目比较特别，跟业务不太相关，没有业务机密泄露问题，公司也比较支持我们这样做。这个项目从第一天起就是开源的，我觉得现在离开源还有些差距，就是像文档等些相关的东西还没完善，这个项目现在主要面向自己内部使用。你知道有很多一些潜规则在里面，把它搭起来可能还是很费力的，我们一直有开源的计划，只是我们现在还是把精力主要放在携程内部推广，我们希望今后有时间能去把它做到开源，就像我们原来做的Cat系统。我们现在的团队现在大概是五六个人，还在不断补充人手。