从0到1的快速裂变：详解快的打车架构设计及技术实践

1、前言

快的打车从2013年年底到2014年下半年，系统访问量迅速膨胀，很多复杂的问题要在短时间内解决，且不能影响线上业务，这是比较大的挑战，本文将会阐述快的打车架构演变过程遇到的一些有代表性的问题和解决方案。

* 本文已于2021年12月9日重新优化排版。

2、早期架构中的LBS方案及其瓶颈

先看看基本的系统模型，如下图所示：

• 1）司机每隔几秒钟上报一次经纬度，存储在MongoDB里；
• 2）乘客发单时，通过MongoDB圈选出附近司机；
• 3）将订单通过长连接服务推送给司机；
• 4）司机接单，开始服务。
  

MongoDB集群是一主多从的复制集方式，读写都很密集（4w+/s写、1w+/s读）时出现以下问题：

• 1）从服务器CPU负载急剧上升；
• 2）查询性能急剧降低（大量查询耗时超过800毫秒）；
• 3）查询吞吐量大幅降低；
• 4）主从复制出现较大的延迟。
  

原因是当时的MongoDB版本（2.6.4）是库级别的锁每次写都会锁库，还有每一次LBS查询会分解成许多单独的子查询，增大整个查询的锁等待概率。我们最后将全国分为4个大区，部署多个独立的MongoDB集群，每个大区的用户存储在对应的MongoDB集群里。

3、实时消息推送长连接服务稳定性

我们的长连接服务通过Socket接收客户端心跳、推送消息给乘客和司机。打车大战期间，长连接服务非常不稳定。

先说说硬件问题，现象是CPU的第一个核经常使用率100%，其他的核却非常空闲，系统吞吐量上不去，对业务的影响很大。经过较长时间排查，最终发现这是因为服务器用了单队列网卡，I/O中断都被分配到了一个CPU核上，大量数据包到来时，单个CPU核无法全部处理，导致LVS不断丢包连接中断。最后解决这个问题其实很简单，换成多队列网卡就行。

再看软件问题，长连接服务当时用Mina实现，Mina本身存在一些问题：内存使用控制粒度不够细、垃圾回收难以有效控制、空闲连接检查效率不高、大量连接时周期性CPU使用率飙高。快的打车的长连接服务特点是：大量的广播、消息推送具有不同的优先级、细粒度的资源监控。

最后我们用AIO重写了这个长连接服务框架，彻底解决了这个问题。主要有以下特性：

• 1）针对快的场景定制开发；
• 2）资源（主要是ByteBuffer）池化，减少GC造成的影响；
• 3）广播时，一份ByteBuffer复用到多个通道，减少内存拷贝；
• 4）使用TimeWheel检测空闲连接，消除空闲连接检测造成的CPU尖峰；
• 5）支持按优先级发送数据。
  

（有关Java NIO和Linux AIO的原理文章，请见《Java新一代网络编程模型AIO原理及Linux系统AIO介绍》）

其实Netty已经实现了资源池化和TimeWheel方式检测空闲连接，但无法做到消息优先级区分和细粒度监控，这也算是快的自身的定制特性吧，通用的通信框架确实不好满足。选用AIO方式仅仅是因为AIO的编程模型比较简单而已，其实底层的性能并没有多大差别。

即时通讯网注：

Java NIO ： 同步非阻塞，服务器实现模式为一个请求一个线程，即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有I/O请求时才启动一个线程进行处理。
Java AIO(NIO.2) ： 异步非阻塞，服务器实现模式为一个有效请求一个线程，客户端的I/O请求都是由OS先完成了再通知服务器应用去启动线程进行处理，

NIO方式适用于连接数目多且连接比较短（轻操作）的架构，比如聊天服务器，并发局限于应用中，编程比较复杂，JDK1.4开始支持。
AIO方式使用于连接数目多且连接比较长（重操作）的架构，比如相册服务器，充分调用OS参与并发操作，编程比较复杂，JDK7开始支持

I/O属于底层操作，需要操作系统支持，并发也需要操作系统的支持，所以性能方面不同操作系统差异会比较明显（注：Linux 2.6版内核开始支持AIO）。另外NIO的非阻塞，需要一直轮询，也是一个比较耗资源的。

4、系统分布式改造

快的打车最初只有两个系统，一个提供HTTP服务的Web系统，一个提供TCP长连接服务的推送系统，所有业务运行在这个Web系统里，代码量非常庞大，代码下载和编译都需要花较长时间。

业务代码都混在一起，频繁的日常变更导致并行开发的分支非常多，测试和代码合并以及发布验证的效率非常低下，常常一发布就通宵。这种情况下，系统的伸缩性和扩展性非常差，关键业务和非关键业务混在一起，互相影响。

因此我们Web系统做了拆分，将整个系统从上往下分为3个大的层次：业务层、服务层以及数据层。

我们在拆分的同时，也仔细梳理了系统之间的依赖。对于强依赖场景，用Dubbo实现了RPC和服务治理。对于弱依赖场景，通过RocketMQ实现。Dubbo是阿里开源的框架，在阿里内部和国内大型互联网公司有广泛的应用，我们对Dubbo源码比较了解。RocketMQ也是阿里开源的，在内部得到了非常广泛的应用，也有很多外部用户，可简单将RocketMQ理解为Java版的Kafka，我们同样也对RocketMQ源码非常了解，快的打车所有的消息都是通过RocketMQ实现的，这两个中间件在线上运行得非常稳定。

借着分布式改造的机会，我们对系统全局也做了梳理，建立研发流程、代码规范、SQL规范，梳理链路上的单点和性能瓶颈，建立服务降级机制。

5、无线开放平台

当时客户端与服务端通信面临以下问题:

• 1）每新增一个业务请求，Web工程就要改动发布。
• 2）请求和响应格式没有规范，导致服务端很难对请求做统一处理，而且与第三方集成的方式非常多，维护成本高。
• 3）来多少请求就处理多少，根本不考虑后端服务的承受能力，而某些时候需要对后端做保护。
• 4）业务逻辑比较分散，有的在Web应用里，有的在Dubbo服务里。提供新功能时，工程师关注的点比较多，增加了系统风险。
• 5）业务频繁变化和快速发展，文档无法跟上，最后没人能说清到底有哪些协议，协议里的字段含义。
  

针对这些问题，我们设计了快的无线开放平台KOP，以下是一些大的设计原则：

• 1）接入权限控制：
  为接入的客户端分配标示和密钥，密钥由客户端保管，用来对请求做数字签名。服务端对客户端请求做签名校验，校验通过才会执行请求。
  
• 2）流量分配和降级：
  同样的API，不同接入端的访问限制可以不一样。可按城市、客户端平台类型做ABTest。极端情况下，优先保证核心客户端的流量，同时也会优先保证核心API的服务能力，例如登录、下单、接单、支付这些核心的API。被访问被限制时，返回一个限流错误码，客户端根据不同场景酌情处理。
  
• 3）流量分析：
  从客户端、API、IP、用户多个维度，实时分析当前请求是否恶意请求，恶意的IP和用户会被冻结一段时间或永久封禁。
  
• 4）实时发布：
  上线或下线API不需要对KOP进行发布，实时生效。当然，为了安全，会有API的审核机制。
  
• 5）实时监控：
  能统计每个客户端对每个API每分钟的调用总量、成功量、失败量、平均耗时，能以分钟为单位查看指定时间段内的数据曲线，并且能对比历史数据。当响应时间或失败数量超过阈值时，系统会自动发送报警短信。
  

6、实时计算与监控

我们基于Storm和HBase设计了自己的实时监控平台，分钟级别实时展现系统运行状况和业务数据（架构如下图所示），包含以下几个主要部分。

• 1）核心计算模型 ：
  求和、求平均、分组。
  
• 2）基于Storm的实时计算 ：
  Storm的逻辑并不复杂，只有两个Bolt，一个将一条日志解析成KV对，另外一个基于KV和设定的规则进行计算。每隔一分钟将数据写入RocketMQ。
  
• 3）基于HBase的数据存储 ：
  只有插入没有更新，避免了HBase行锁竞争。rowkey是有序的，因为要根据维度和时间段查询，这样会形成HBase Region热点，导致写入比较集中，但是没有性能问题，因为每个维度每隔1分钟定时插入，平均每秒的插入很少。即使前端应用的日志量突然增加很多，HBase的插入频度仍然是稳定的。
  
• 4）基于RocketMQ的数据缓冲 ：
  收集的日志和Storm计算的结果都先放入MetaQ集群，无论Storm集群还是存储节点，发生故障时系统仍然是稳定的，不会将故障放大；即使有突然的流量高峰，因为有消息队列做缓冲，Storm和HBase仍然能以稳定的TPS处理。这些都极大的保证了系统的稳定性。RocketMQ集群自身的健壮性足够强，都是物理机。SSD存储盘、高配内存和CPU、Broker全部是M/S结构。可以存储足够多的缓冲数据。
  

某个系统的实时业务指标（关键数据被隐藏），见下图：

7、数据层改造

随着业务发展，单数据库单表已经无法满足性能要求，特别是发券和订单，我们选择在客户端分库分表，自己做了一个通用框架解决分库分表的问题。

但是还有以下问题：

• 1）数据同步 ：
  快的原来的数据库分为前台库和后台库，前台库给应用系统使用，后台库只供后台使用。不管前台应用有多少库，后台库只有一个，那么前台的多个库多个表如何对应到后台的单库单表？MySQL的复制无法解决这个问题。
  
• 2）离线计算抽取 ：
  还有大数据的场景，大数据同事经常要dump数据做离线计算，都是通过Sqoop到后台库抽数据，有的复杂SQL经常会使数据库变得不稳定。而且，不同业务场景下的Sqoop会造成数据重复抽取，给数据库添加了更多的负担。
  

我们最终实现了一个数据同步平台，见下图：



如上图所示：

• 1）数据抽取用开源的canal实现，MySQL binlog改为Row模式，将canal抽取的binlog解析为MQ消息，打包传输给MQ；
• 2）一份数据，多种消费场景，之前是每种场景都抽取一份数据；
• 3）各个消费端不需要关心MySQL，只需要关心MQ的Topic；
• 4）支持全局有序，局部有序，并发乱序；
• 5）可以指定时间点回放数据；
• 6）数据链路监控、报警；
• 7）通过管理平台自动部署节点。
  

分库分表解决了前台应用的性能问题，数据同步解决了多库多表归一的问题，但是随着时间推移，后台单库的问题越来越严重，迫切需要一种方案解决海量数据存储的问题，同时又要让现有的上层应用不会有太大改动。

因此我们基于HBase和数据同步设计了实时数据中心，如下图所示：



如上图所示：

• 1）将前台MySQL多库多表通过同步平台，都同步到了HBase；
• 2）为减少后台应用层的改动，设计了一个SQL解析模块，将SQL查询转换为HBase查询；
• 3）支持二级索引：
  说说二级索引，HBase并不支持二级索引，对它而言只有一个索引，那就是Rowkey。如果要按其它字段查询，那就要为这些字段建立与Rowkey的映射关系，这就是所谓的二级索引。HBase二级索引可以通过Coprocessor在数据插入之前执行一段代码，这段代码运行在HBase服务端（Region Server），可以让这段代码负责插入二级索引。实时数据中心的二级索引是在客户端负责插入的，并没有使用Coprocessor，主要原因是Coprocessor不容易实现索引的批量插入，而批量插入，实践证明，是提升HBase插入性能非常有效的手段。二级索引的应用其实还有些条件，如下：
• 4）排序：
  在HBase中，只有一种排序，就是按Rowkey排序，因此，在建立索引的时候，实际上就定死了将来查询结果的排序。某个索引字段的reverse属性为true，则按这个字段倒序排序，否则正序排序。
• 5）打散：
  单调变化的Rowkey读写压力很难均匀分布到多个Region上，而打散将会使读写均匀分布到多个Region，因此提升了读写性能。但打散也有局限性，主要的是，经过打散的字段将无法支持范围查询。而且，hash和reverse这两个属性是互斥的，且hash优先级高，就是说一旦设置了hash=true，则会忽略reverse这个属性。
• 6）串联：
  另外需要特别强调的是，索引配置也影响到多表归一，作为“串联”的字段，必须建立唯一索引，如果串联字段上没有建立唯一索引，将无法完成多表归一。
  

另外：

我们还实现了一套将SQL语句转换成HBase API的引擎，可以通过SQL语句直接操作HBase。这里需要指出的是HSQL引擎和Hive是不同的，Hive主要用于将SQL语句转换成Hadoop的Map/Reduce任务，当然也可以转换成HBase的查询。但Hive无法利用二级索引（HBase本来就不存在二级索引这个概念），Hive主要面向的是大批量、低频度、高延迟、顺序读的访问场景，而HSQL可以有效利用二级索引，它面向的是小批量、高频度、低延迟、随机读的访问场景。

作者简介：王小雪，滴滴出行架构师、原快的打车架构师。从无到有组建了快的打车基础服务团队，主持研发、引进了众多基础框架和服务，推进快的架构升级，从稳定性、可用性、性能、安全、监控多方面体系化的建设了快的高可用架构。对高并发分布式系统架构、实时数据处理、网络通信和Java中间件有比较深厚的经验积累。

附录：更多架构设计方面的资料

• 《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
• 《快速理解高性能HTTP服务端的负载均衡技术原理》
• 《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
• 《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》
• 《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
• 《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
• 《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
• 《达达O2O后台架构演进实践：从0到4000高并发请求背后的努力》
• 《优秀后端架构师必会知识：史上最全MySQL大表优化方案总结》
• 《小米技术分享：解密小米抢购系统千万高并发架构的演进和实践》
• 《一篇读懂分布式架构下的负载均衡技术：分类、原理、算法、常见方案等》
• 《通俗易懂：如何设计能支撑百万并发的数据库架构？》
• 《多维度对比5款主流分布式MQ消息队列，妈妈再也不担心我的技术选型了》
• 《从新手到架构师，一篇就够：从100到1000万高并发的架构演进之路》
• 《美团技术分享：深度解密美团的分布式ID生成算法》
• 《12306抢票带来的启示：看我如何用Go实现百万QPS的秒杀系统(含源码)》
• -------------------
• 《浅谈IM系统的架构设计》
• 《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
• 《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》
• 《一套原创分布式即时通讯(IM)系统理论架构方案》
• 《从零到卓越：京东客服即时通讯系统的技术架构演进历程》
• 《蘑菇街即时通讯/IM服务器开发之架构选择》
• 《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
• 《微信后台基于时间序的海量数据冷热分级架构设计实践》
• 《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
• 《如何解读《微信技术总监谈架构：微信之道——大道至简》》
• 《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
• 《17年的实践：腾讯海量产品的技术方法论》
• 《移动端IM中大规模群消息的推送如何保证效率、实时性？》
• 《现代IM系统中聊天消息的同步和存储方案探讨》
• 《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》
• 《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》
• 《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》
• 《WhatsApp技术实践分享：32人工程团队创造的技术神话》
• 《微信朋友圈千亿访问量背后的技术挑战和实践总结》
• 《王者荣耀2亿用户量的背后：产品定位、技术架构、网络方案等》
• 《IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？》
• 《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
• 《以微博类应用场景为例，总结海量社交系统的架构设计步骤》
• 《快速理解高性能HTTP服务端的负载均衡技术原理》
• 《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
• 《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》
• 《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
• 《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
• 《一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》
• 《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》
• 《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》
• 《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》
• 《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》
• 《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》
• 《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》
• 《社交软件红包技术解密(七)：支付宝红包的海量高并发技术实践》
• 《社交软件红包技术解密(八)：全面解密微博红包技术方案》
• 《社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等》
• 《社交软件红包技术解密(十)：手Q客户端针对2020年春节红包的技术实践》
• 《社交软件红包技术解密(十一)：解密微信红包随机算法(含代码实现)》
• 《即时通讯新手入门：一文读懂什么是Nginx？它能否实现IM的负载均衡？》
• 《即时通讯新手入门：快速理解RPC技术——基本概念、原理和用途》
• 《多维度对比5款主流分布式MQ消息队列，妈妈再也不担心我的技术选型了》
• 《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》
• 《从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结》
• 《从游击队到正规军(三)：基于Go的马蜂窝旅游网分布式IM系统技术实践》
• 《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
• 《瓜子IM智能客服系统的数据架构设计（整理自现场演讲，有配套PPT）》
• 《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》
• 《微信后台基于时间序的新一代海量数据存储架构的设计实践》
• 《IM开发基础知识补课(九)：想开发IM集群？先搞懂什么是RPC！》
• 《IM开发基础知识补课(十)：大型IM系统有多难？万字长文，搞懂异地多活！》
• 《阿里技术分享：电商IM消息平台，在群聊、直播场景下的技术实践》
• 《一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等》
• 《一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等》
• 《从新手到专家：如何设计一套亿级消息量的分布式IM系统》
• 《企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等》
• 《融云技术分享：全面揭秘亿级IM消息的可靠投递机制》
• 《IM开发技术学习：揭秘微信朋友圈这种信息推流背后的系统设计》
• 《阿里IM技术分享(三)：闲鱼亿级IM消息系统的架构演进之路》
• 《阿里IM技术分享(四)：闲鱼亿级IM消息系统的可靠投递优化实践》
• 《阿里IM技术分享(五)：闲鱼亿级IM消息系统的及时性优化实践》
• 《阿里IM技术分享(六)：闲鱼亿级IM消息系统的离线推送到达率优化》
• 《基于实践：一套百万消息量小规模IM系统技术要点总结》
  

>> 更多同类文章 ……

（原文链接：http://geek.csdn.net/news/detail/49447/）

文中提到的技术，几乎都是开源工程，能深深地感受到：没有开源的贡献，类假于文中的架构至少从技术选型上来说，可选的余地要小的多，甚至别无选择。不可否认，真是开源技术促进了互联网的繁荣。

内容写的不错，感谢原作者。

话说群主的开源项目属于什么认证呢

笔者说的

引用：当时客户端与服务端通信面临以下问题

其中的1，2，4，5条怎么解决的？在后续描述中没说清楚啊。