请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 3
从0到1的快速裂变:详解快的打车架构设计及技术实践

前言


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

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


先看看基本的系统模型,如下图所示:

20160105090210270.png

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

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

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

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

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


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

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

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

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

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

(有关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的非阻塞,需要一直轮询,也是一个比较耗资源的。


系统分布式改造


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

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

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

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

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

无线开放平台


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

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

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

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

实时计算与监控


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

2.png

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

某个系统的实时业务指标(关键数据被隐藏),见下图:

3.png

数据层改造


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

但是还有以下问题:

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

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

4.png

如上图所示:

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

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

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

5.png

如上图所示:

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

另外:

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

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


全站即时通讯技术资料分类


[1] 网络编程基础资料:
TCP/IP详解 - 第11章·UDP:用户数据报协议
TCP/IP详解 - 第17章·TCP:传输控制协议
TCP/IP详解 - 第18章·TCP连接的建立与终止
TCP/IP详解 - 第21章·TCP的超时与重传
理论经典:TCP协议的3次握手与4次挥手过程详解
理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程
计算机网络通讯协议关系图(中文珍藏版)
NAT详解:基本原理、穿越技术(P2P打洞)、端口老化等
UDP中一个包的大小最大能多大?
Java新一代网络编程模型AIO原理及Linux系统AIO介绍
NIO框架入门(三):iOS与MINA2、Netty4的跨平台UDP双向通信实战
NIO框架入门(四):Android与MINA2、Netty4的跨平台UDP双向通信实战
>> 更多同类文章 ……

[2] 有关IM/推送的通信格式、协议的选择:
为什么QQ用的是UDP协议而不是TCP协议?
移动端即时通讯协议选择:UDP还是TCP?
如何选择即时通讯应用的数据传输格式
强列建议将Protobuf作为你的即时通讯应用数据传输格式
移动端IM开发需要面对的技术问题(含通信协议选择)
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
理论联系实际:一套典型的IM通信协议设计详解
58到家实时消息系统的协议设计等技术实践分享
>> 更多同类文章 ……

[3] 有关IM/推送的心跳保活处理:
Android进程保活详解:一篇文章解决你的所有疑问
Android端消息推送总结:实现原理、心跳保活、遇到的问题等
为何基于TCP协议的移动端IM仍然需要心跳保活机制?
微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)
微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)
移动端IM实践:实现Android版微信的智能心跳机制
移动端IM实践:WhatsApp、Line、微信的心跳策略分析
>> 更多同类文章 ……

[4] 有关WEB端即时通讯开发:
新手入门贴:史上最全Web端即时通讯技术原理详解
Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE
SSE技术详解:一种全新的HTML5服务器推送事件技术
Comet技术详解:基于HTTP长连接的Web端实时通信技术
WebSocket详解(一):初步认识WebSocket技术
socket.io实现消息推送的一点实践及思路
>> 更多同类文章 ……

[5] 有关IM架构设计:
浅谈IM系统的架构设计
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
一套原创分布式即时通讯(IM)系统理论架构方案
从零到卓越:京东客服即时通讯系统的技术架构演进历程
蘑菇街即时通讯/IM服务器开发之架构选择
腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT
微信技术总监谈架构:微信之道——大道至简(演讲全文)
如何解读《微信技术总监谈架构:微信之道——大道至简》
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
17年的实践:腾讯海量产品的技术方法论
>> 更多同类文章 ……

[6] 有关IM安全的文章:
即时通讯安全篇(一):正确地理解和使用Android端加密算法
即时通讯安全篇(二):探讨组合加密算法在IM中的应用
即时通讯安全篇(三):常用加解密算法与通讯安全讲解
即时通讯安全篇(四):实例分析Android中密钥硬编码的风险
传输层安全协议SSL/TLS的Java平台实现简介和Demo演示
理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)
微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解
来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享
>> 更多同类文章 ……

[7] 有关实时音视频开发:
即时通讯音视频开发(一):视频编解码之理论概述
即时通讯音视频开发(二):视频编解码之数字视频介绍
即时通讯音视频开发(三):视频编解码之编码基础
即时通讯音视频开发(四):视频编解码之预测技术介绍
即时通讯音视频开发(五):认识主流视频编码技术H.264
即时通讯音视频开发(六):如何开始音频编解码技术的学习
即时通讯音视频开发(七):音频基础及编码原理入门
即时通讯音视频开发(八):常见的实时语音通讯编码标准
即时通讯音视频开发(九):实时语音通讯的回音及回音消除概述
即时通讯音视频开发(十):实时语音通讯的回音消除技术详解
即时通讯音视频开发(十一):实时语音通讯丢包补偿技术详解
即时通讯音视频开发(十二):多人实时音视频聊天架构探讨
即时通讯音视频开发(十三):实时视频编码H.264的特点与优势
即时通讯音视频开发(十四):实时音视频数据传输协议介绍
即时通讯音视频开发(十五):聊聊P2P与实时音视频的应用情况
即时通讯音视频开发(十六):移动端实时音视频开发的几个建议
即时通讯音视频开发(十七):视频编码H.264、V8的前世今生
简述开源实时音视频技术WebRTC的优缺点
良心分享:WebRTC 零基础开发者教程(中文)
>> 更多同类文章 ……

[8] IM开发综合文章:
移动端IM开发需要面对的技术问题
开发IM是自己设计协议用字节流好还是字符流好?
请问有人知道语音留言聊天的主流实现方式吗?
IM系统中如何保证消息的可靠投递(即QoS机制)
谈谈移动端 IM 开发中登录请求的优化
完全自已开发的IM该如何设计“失败重试”机制?
微信对网络影响的技术试验及分析(论文全文)
即时通讯系统的原理、技术和应用(技术论文)
开源IM工程“蘑菇街TeamTalk”的现状:一场有始无终的开源秀
>> 更多同类文章 ……

[9] 开源移动端IM技术框架资料:
开源移动端IM技术框架MobileIMSDK:快速入门
开源移动端IM技术框架MobileIMSDK:常见问题解答
开源移动端IM技术框架MobileIMSDK:压力测试报告
开源移动端IM技术框架MobileIMSDK:Android版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:Java版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:iOS版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:Android客户端开发指南
开源移动端IM技术框架MobileIMSDK:Java客户端开发指南
开源移动端IM技术框架MobileIMSDK:iOS客户端开发指南
开源移动端IM技术框架MobileIMSDK:Server端开发指南
>> 更多同类文章 ……

[10] 有关推送技术的文章:
iOS的推送服务APNs详解:设计思路、技术原理及缺陷等
Android端消息推送总结:实现原理、心跳保活、遇到的问题等
扫盲贴:认识MQTT通信协议
一个基于MQTT通信协议的完整Android推送Demo
求教android消息推送:GCM、XMPP、MQTT三种方案的优劣
移动端实时消息推送技术浅析
扫盲贴:浅谈iOS和Android后台实时消息推送的原理和区别
绝对干货:基于Netty实现海量接入的推送服务技术要点
移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)
为何微信、QQ这样的IM工具不使用GCM服务推送消息?
>> 更多同类文章 ……

[11] 更多即时通讯技术好文分类:
http://www.52im.net/forum.php?mod=collection&op=all

(原文链接:http://geek.csdn.net/news/detail/49447/

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:58到家实时消息系统的架构设计及技术选型经验总结下一篇:已有的推送框架如何结合APNS

本帖已收录至以下技术专辑

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

内容写的不错,感谢原作者。
签名: 《零基础通信技术入门(十三):为什么手机信号差?一文即懂!》http://www.52im.net/thread-2415-1-1.html
话说群主的开源项目属于什么认证呢
签名: 17 小时前 (Lv9)以坛为家II
笔者说的
引用:当时客户端与服务端通信面临以下问题


其中的1,2,4,5条怎么解决的?在后续描述中没说清楚啊。
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部