SDCC2015-快的打车-快的打车架构实践.pdf

快的打车架构实践 王小雪 发展历程 1亿用户 滴滴快的合并 日订单：600w+ 收购“大黄 蜂”，开启 商务车业务 覆盖城市：70+ 5月成立，8 月上线运营 V1阶段——基本功能可用  公司没有知名度  系统仅满足基本的功能  技术团队10-30人左右  天气不好系统就崩溃  日订单从几百单到几万单  快的一崩溃滴滴也崩溃  作坊式研发  反过来也是一样，很有默契 确立了原始的系统模型 MongoDB Mina V2阶段——核心链路优化 2013年底打车大战爆发，很短时间内，日订单规模从几万单迅速膨胀到几百万单。系统面 临很多问题，我们将问题分优先级，首先对核心链路进行优化，否则业务主流程都无法正 常进行。 核心链路问题及业务影响 LBS瓶颈 问题：暴增的LBS查询和写入给MongoDB带来巨大的压力，经常会延时 影响：推单时选取的司机有时离乘客很远，或者很近的却没有推送 长连接服务稳定性 问题：TCP server高峰期CPU load很高、消息被截断、连接丢失 影响：司机收不到订单；司机接单了乘客却不知道；乘客取消订单了司机不知道 LBS瓶颈和方案 长连接服务稳定性 硬件问题 不支持多队列的网卡，IO中断都被分配到了一个cpu核上，大量数据包到来的情况下，单个 cpu核无法全部处理，导致LVS不断丢包，连接不断中断。 解决方案 更换支持硬件多队列的网卡(Intel 82575、82576 ，Boardcom的57711等，linux 内核版本需要 在2.6.21 以上) 长连接服务稳定性 软件问题（Mina框架） 1 内存使用控制不够细粒度，垃圾回收难以有效控制 2 空闲连接检查效率不高，在大量连接的情况下会出现周期性CPU 使用率飙高 3 编解码组件在高并发下会出现消息被截断的情况 解决方案 （快的自己的AIO框架）  资源(主要是ByteBuffer)池化,减少GC造成的影响  广播时，一份ByteBuffer复用到多个通道，减少内存拷贝  使用TimerWheel检测空闲连接，消除空闲连接检测造成的CPU尖峰  支持按优先级发送数据 Timer wheel V3阶段——体系化的架构改造 截止到2014年4月份，我们解决了LBS瓶颈、长连接服务的稳定性，核心业务流程的稳定 性有很大提高。技术团队100多人，日订单600万左右，业务场景越来越复杂，原来很多非 核心问题变得越来越严重。  稳定性差 经常会出现一些功能不可用。都忙着做业务需求，怎么快怎么来，后面堆积了大量的历史债  伸缩性差 核心业务和非核心业务混杂在一起  存储瓶颈 每天有几百万的订单，每天都发大量的券，单库单表已经无法支撑了  效率低下 所有业务都在一个系统里，每天很多的并行分支  安全问题