余庆：易到用车的消息推送平台重构和服务化框架

个人简介 余庆,15年互联网开发经验，开源分布式文件系统FastDFS作者；参与过Apache Traffic Server核心代码改造； 先后在新浪、中国雅虎、淘宝和阿里云工作，参与过搜索引擎、CDN等平台的设计和研发工作，对分布式和高性能计算有着比较深入的研究，现在易到用车担任架构师。

全球架构师峰会（International Architect Summit，下简称ArchSummit）是由InfoQ中文站主办的一次全球性架构师峰会。ArchSummit专门针对架构师人群，讲述与架构和架构师相关的各方面趋势、技术和案例。这也是继QCon之后，InfoQ中文站主办的又一次高端技术盛会。

   

1. 大家好，我在ArchSummit深圳大会现场，今天很高兴邀请到易到用车的首席架构师余庆来接受我们的采访。余庆在互联网做了15年，之前在新浪，雅虎，淘宝和阿里云都做过很多分享，分布式也做了很多，也写过FastDFS，您能简单介绍一下去年在易到这边的主要工作吗？

余庆：我是去年大概5月份加入的易到用车，到易到之后，最主要是做了两件事情，一个是消息推送平台的重构，我们原来的消息推送平台是基于ejabberd来做的，性能上存在一些瓶颈，所以我们就做了一个重构；另外一个事，就是大概八九月份的时候，我们做了一个服务化框架。和我们的CTO汤鹏，还有别的一些技术部的同事一块探讨，觉得后面服务化是我们的一个很重要的方向，所以在八九月份的时候，我们架构组这边就实现了一个服务框架。我们主要的开发语言是PHP，所以这个服务框架主要是针对PHP语言的服务化的框架性的东西。基于这个框架，我们前面做过一些小的项目的服务化尝试，效果还是可以的，然后在今年3月份，我们就把消息中心，基于我们的服务化框架也做了个重构。大概是3月底做了第一版，然后4月中旬就正式发布，到现在运行的效果都是非常好的，包括RT，系统的稳定性，对CPU的占用，整体效果都非常好，那就介绍这么多。

   

2. 您刚才提到新版的消息推送系统，那老的系统有什么问题，为什么要做这个新版的，它的技术实现和最后的结果能给我们介绍一下吗？

余庆：是这样的，我也稍微讲了一下，最早我们的消息推送是基于ejabberd的，是XMPP协议的一个实现。我们实现的时候会把自动推送消息先放到MongoDB里边，司机在线的时候会对MongoDB会做轮询，这个轮询机制对MongoDB造成的访问的压力比较大，明显存在性能瓶颈，轮询机制导致MongoDB的CPU压力、IO压力都很高。当时觉得这个方案在更大的并发数据量可能扛不住，我加入正好做消息推送平台的重构，我们用C语言重新实现了一套。还有就是送达率，这块我们做好之后也有一个对比，之前对司机的送达率大概可能只有93%，我们做好之后，能够到99%，大概就是这样的一个水平，送达率也高了。

   

3. 现在市面上有很多第三方的推送的服务，为什么还是决定自己研发这么一套？

余庆：是这样的一个情况，因为易到用车做得比较早，10年就开始做了。最早的时候，做推送的公司也有，也和他们聊过也评估过，但还是觉得他们的稳定性可能达不到我们的要求，所以当时就决定自己做，就基于ejabberd：xml自己做了一套。去年我过去的时候，基于原来对这些厂商的稳定性的一些怀疑，就决定还是自己做一套。我们考虑的除了刚才讲的担心第三方的稳定性可能达不到我们的要求之外，还有就是对可控性，实时性，送达率的要求也会变高。我们派发定单的时效一般都是一分钟，定单推给司机之后，他一分钟之内要做出响应选择接不接这个单，如果过了一分钟就失效了，所以它时效性要求比较高。另外就是送达率的要求会比较高，我们希望送达率能到99%，甚至更高。最近我们和一些第三方的推送平台公司也有接触，跟他们交流来看，他们现在稳定性已经做的很好了，如果我们自己没有这样的推送系统，比如说我们要新做一个APP，涉及到推送的话，那我建议，首选还是找这种第三方的比较成熟的，比较稳定的推送平台，这样开发的效率也更快，目前来看，它的稳定性、实时性，送达率都还是可以的。

   

4. 您刚才提到服务化这么一个工作，可能也是很多公司发展到一定程度会很关心的，那能不能介绍一下，你们是遇到什么样的问题才决定往这个方向多走一点？

余庆：服务化这块我就多说两句，我们可以看到，互联网的公司做的比较大的，他们的服务化工作已经早就做完了，比如说像阿里就是淘宝这块，据我了解的，它应该差不多08年就在做服务化的事情了，应该最晚是到10年服务化的工作全部做完了；还有我知道的新浪，大概是12年的时候就把服务化的工作做完了。再讲到我们自己，我加入易到之后，包括易到的老板周航也问我，他说你觉得易到的架构基础怎么样？其实周航找我聊之前，我也是了解过的，易到的整体技术架构还是比较清晰的，它的架构层次分的很清楚，然后服务化的雏形都是有的。他前面的系统架构就是按服务化的方式去做的，但是实际做的过程中可能业务冲得比较快，没有做到彻底的服务化，模块之间还是有耦合，比如像用户和定单这块就没有拆的很干净，创建订单的过程中，可能也会直接去访问用户的数据库，就还是耦合的比较紧密。它带来的问题就是随着业务的继续增长会有性能的问题，因为耦合，比如说定单的表太大了，我想对定单做优化，或者用户表太大了，我要对用户做优化，都没法做，因为很多业务逻辑都是相互访问数据表的，又访问用户表，又访问定单表。加cache都不好加，因为cache存在数据一致性的问题，各个业务方都直接去查数据表，比如说用户更新之后，cache怎么失效，要改的点太多了。性能提升的难度相对会比较高一点，这是一个方面。另外一个方面就是，因为模块之间的耦合，一些业务的修改可能涉及了好多方，改一个地方会影响到别的地方，这些情况是实际发生过的，这样的话，我们开发的效率就没有那么高了，主要就是这两个的考虑。然后去年我们就讨论决定要往服务化这个方向努力，我们也做了铺垫，前面我们针对PHP的服务化框架已经做成了，它是比较高性能的一个服务化框架，能支持大并发连接。我们也希望服务化的连接全用长连接的方式，也做了这种服务化方式的尝试，比如说我们的消息中心就是按我们的服务化框架做的，效果非常理想。服务化这块我再多说一下，其实服务化的做法不一定是非得基于私有协议的通信框架，基于HTTP这种通信协议也是完全可以的，但HTTP这种通讯协议，我不建议内部服务化使用。因为做HTTP有这么几个弊端，一个是HTTP的请求会带一些Header过去，然后它的response也有一个HTTP的Header，会造成没有必要的消耗。内部调用又不是用户浏览器上的调用，非得把User agent，或者Host那些带过来，HTTP它存在明显的overload现象。所以我们走自己的服务框架的话，我的通信协议也是私有的，它的头部就很简单，字节数特别小，在协议层的overload问题就给它消除掉了，这是一个问题。还有一个问题就是HTTP我们现在主要还是用apache，相对用的比较传统，目前是用的一个请求来了，一个进程去服务的这种apache的子进程的模型，这种的话，实施长连接的开销就很大，比如说一个apache server要支持一万个并发连接，那对应着要起一万个子进程，这个基本上是不可能的，就算现在的服务器的CPU内存都很强劲，但真的要支持一万个并发在跑的子线程也不太现实。所以基于现在的这种WebServer的方式要实现长连接的代价非常大。但是我们用自己的服务框架的话，因为我们是用C实现的，通讯这块用的异步，它支持并发连接就很轻松了，比如支持并发十万都很轻松。所以对这种内部的服务化有更高性能的通讯协议来支持，我建议能不用传统的HTTP服务就不用，这是我的一个建议。我也在想这样一个问题，如果你的内部服务化全走HTTP，如果你不走长连接的方式的话有可能这是个灾难，因为你的模块拆的很多，比如用户有定单，有支付，或者还有别的更多的系统，你拆了之后反而导致一个业务的处理要调用很多个模块，如果每一个都是短连接的话，建立连接的开销也是不容忽视的。不说多了，一个业务处理内部逻辑调十次，这其实不算多了，调十次可能就是十次建立连接的过程，这样就有可能反而会造成一个灾难，这种短连会占用本地的端口，如果一台机器支持的业务量相对比较大的话，有可能本地的端口会被耗尽的，耗尽再去连别的机器，因为本地的端口分配不出来，这个连接也建不起来。这种端口被耗尽的问题我们也碰到过，我相信业务量达到一定规模的公司如果用短连接方式的话也会碰到。

   

5. 是用HTTP的时候遇到这个问题？

余庆：因为目前我们主要还是用apache，并且用apache比较传统的子进程的工作模式，一个请求过来，一个子进程去服务的模式，这个模式支持大一点的并发连接消耗是非常大，非常费的。

   

6. 最后就是服务化的实施，对于有些团队来说，可能代码量已经比较大了，然后解耦本来做的也不是很好，就会涉及到比较大的工作量，但是研发团队又得响应业务新feature的需求，新feature研发跟现有系统优化方面有一定的平衡要处理。这个具体实施的方案，你们现在是怎么去调研思考的？有一些心得可以分享？

余庆：好的，其实服务化这个方向我们当初讨论定了之后，我们也在探讨说怎么实施的问题，因为服务化明显的要涉及到重构，一旦重构的话，可以说也是伤筋动骨的，我们当时也看过别的公司的做法，别的公司有这样做的，原来的业务团队还是继续支持原来的业务。然后再组建一个重构的团队并行做，重构团队找到某个时间点的代码拿过来，基于这些代码改造。但这样有个问题是说，在重构的过程中业务还在往前发展，还是有业务的代码在做改进，这个难度就在于，在改进的代码怎么把它整合到重构的版本里面来，这个是有挑战的。所以说这个工作还是决心的问题，你认为不解决服务化的问题，你的性能就扛不住了，或者说你的开发效率就受到很大的压缩的时候，你必须做服务化的时候，就会想办法去解决了，比如刚才说的这个方式，也是可以做的，肯定是有难度，有挑战，但这条路是走的通的，这是一个方向。那另外一个方向是基于原来的业务团队，他自己抽身出来做一个重构版本，因为业务在发展，如果业务不发展，你说我停下来专门做个重构版本，那当然没问题了。业务肯定是在往前发展的，不可能给你留一个月，留三个月，专门做一个重构版本，这是不可能的，这个大家也都很理解。其实不管怎么做，都要有专人来做一个重构版本，至于说做这个重构版本，怎么抽掉人手来做，还是说原来业务团队再分人手出来做，就是怎么抽调人手的问题了。现在据我所了解的做法，应该来讲就只能是抽调人手，专门做个重构版本，同时把原来的业务线一些改进合并就好了，我所看到的基本上就是这条路。

   

7. 那十分感谢余庆今天接受我们采访。

余庆：好的，谢谢。