实例介绍
【实例简介】
SDCC2015-快的打车-王小雪-快的打车架构实践
V1阶段—基本功能可用 SDCC 中国软件开发者大会 OFTWARE DEVELOPER CONFERENCE CHINA 公司没有知名度 ●系统仅满足基本的功能 ●技术团队10-30人左右 天气不好系统就崩溃 ●日订单从几百单到几万单 快的一崩溃滴滴也崩溃 作坊式研发 ●反过来也是一样,很有默契 确立了原始的系统模型 乘 司 机 位置 心跳 发单 推送 上传 图选 司积 每秒4万更新 p server bs服务 tcp server 派发消息 MongoDB Mina V2阶段——核心链路优化 SDCC 中国软件开发者大会 OFTWARE DEVELOPER CONFERENCE CHINA 2013年底打车大战爆发,很短时间内,日订单规模从几万单迅速膨胀到几百万单。系统面 临很多问题,我们将问题分优先级,首先对核心链路进行优化,否则业务主流程都无法正 常进行。 核心链路问题及业务影响 LBS瓶颈 问题:暴增的LBS查询和写入给 MongoDB带来巨大的压力,经常会延时 影响:推单时选取的司机有时离乘客很远,或者很近的却没有推送 长连接服务稳定性 问题: TCP server髙峰期￠ PU load很高、消息被截断、连接丢失 影响:司杌收不到订单;司机接单了乘客却不知道;乘客取消订单了司机不知道 LBS瓶颈和方案 SDCC 中国软件开发者大会 OFTWARE DEVELOPER CONFERENCE CHINA 快的 LBS MongoDB集群结构wmte MongoDB2D查询原理 myco11 ection” near:[120.5842,30.6597] maxDistance. 5 }) Read MongoDB0瓶须 解决方案:分区 读写都很密集(w/s写,1w/s读)时出现的问题 从服务器cpu负载急剧上升 查询性能急剧降低(大量查询耗时超过800毫秒) 查询吞吐量大幅降低 主从复制出现较大的延迟 MongodB geo瓶颈原因 Mongodb目前(2.6.4版本)锁是库级别的锁,每一 次写都会锁库 每一次LBS查询,会分解成许多次单独的子查询 增大了整个查询的锁等待概率 长连接服务稳定性 SDCC 中国软件开发者大会 OFTWARE DEVELOPER CONFERENCE CHINA 硬件问题 不支持多队列的网卡,lo中断都被分配到了一个cpu核上,大量数据包到来的情况下,单个 cpu核无法全部处理,导致LV不断丢包,连接不断中断。 解决方案 更换支持硬件多队列的网卡(nte82575、82576, Boardcom的57711等, linux内核版本需要 在2621以上) 长连接服务稳定性 SDCC 中国软件开发者大会 OFTWARE DEVELOPER CONFERENCE CHINA 软件问题(Mina框架) 1内存使用控制不够细粒度,垃圾回收难以有效控制 2空闲连接检査效率不高,在大量连接的情况下会出现周期性CPU使用率飙高 3编解码组件在高并发下会出现消息被截断的情况 解决方案(快的自己的AO框架) 资源(主要是 Byte buffer池化减少GC造成的影响 广播时,一份 Byte Buffer复用到多个通道,减少内存拷贝 使用τ imerWhee?检测空闲连接,消除空闲连接检测造成的CPU尖峰 支持按优先级发送数据 Timer wheel ∨3阶段—体系化的架构改造sDcc 中国软件开发者大会 OFTWARE DEVELOPER CONFERENCE CHINA 截止到2014年4月份,我们解决了LBS瓶颈、长连接服务的稳定性,核心业务流程的稳定 性有很大提高。技术团队100多人,日订单600万左右,业务场景越来越复杂,原来很多非 核心问题变得越来越严重 稳定性差 经常会出现一些功能不可用。都忙着做业务需求,怎么快怎么来,后面堆积了大量的历史债 伸缩性差 核心业务和非核心业务混杂在一起 存储瓶颈 每天有几百万的订单,每天都发大量的券,单库单表已经无法支撑了 ●效率低下 所有业务都在一个系统里,每天很多的并行分支 ●安全问题 线上配置都是明文写在工程配置文件里的;XSS漏洞很多 没有监控 无法了解系统运行情况,故障定位效率很低 协议混乱 客户端和服务器的通信协议混乱,没有统一的文档和格式 体系化的架构改造 SDCC 中国软件开发者大会 OFTWARE DEVELOPER CONFERENCE CHINA 切都是为了更高的可用性 系统全局梳理 应用分布式改造 扩展性 无线开放平台 效率 数据层改造 伸缩性 日志收集与检索 核心要素 ●监控系统 安全 可用性 风控平台 配置中心 监控 研发流程自动化 系统全局梳理 SDCC 中国软件开发者大会 OFTWARE DEVELOPER CONFERENCE CHINA 流程与规范 建立研发流程、代码规范、SQL规范 执行严格的 code review,普及质量意识 ●建立故障问责机制 稳定性 梳理链路上的单点 梳理链路上的性能瓶颈 梳理每个环节的故障恢复机制,比如网络闪断后能否自动重连以及重连的影响 梳理JMM配置、 tomcat配置、应用参数配置 定期对系统做性能压测,科学合理的应对营销活动 定期 Ireview系统的机器部署 建立服务降级机制 业务梳理 小规模的迭代重构 不求一步到位,但求一直进步 【实例截图】
【核心代码】
SDCC2015-快的打车-王小雪-快的打车架构实践
V1阶段—基本功能可用 SDCC 中国软件开发者大会 OFTWARE DEVELOPER CONFERENCE CHINA 公司没有知名度 ●系统仅满足基本的功能 ●技术团队10-30人左右 天气不好系统就崩溃 ●日订单从几百单到几万单 快的一崩溃滴滴也崩溃 作坊式研发 ●反过来也是一样,很有默契 确立了原始的系统模型 乘 司 机 位置 心跳 发单 推送 上传 图选 司积 每秒4万更新 p server bs服务 tcp server 派发消息 MongoDB Mina V2阶段——核心链路优化 SDCC 中国软件开发者大会 OFTWARE DEVELOPER CONFERENCE CHINA 2013年底打车大战爆发,很短时间内,日订单规模从几万单迅速膨胀到几百万单。系统面 临很多问题,我们将问题分优先级,首先对核心链路进行优化,否则业务主流程都无法正 常进行。 核心链路问题及业务影响 LBS瓶颈 问题:暴增的LBS查询和写入给 MongoDB带来巨大的压力,经常会延时 影响:推单时选取的司机有时离乘客很远,或者很近的却没有推送 长连接服务稳定性 问题: TCP server髙峰期￠ PU load很高、消息被截断、连接丢失 影响:司杌收不到订单;司机接单了乘客却不知道;乘客取消订单了司机不知道 LBS瓶颈和方案 SDCC 中国软件开发者大会 OFTWARE DEVELOPER CONFERENCE CHINA 快的 LBS MongoDB集群结构wmte MongoDB2D查询原理 myco11 ection” near:[120.5842,30.6597] maxDistance. 5 }) Read MongoDB0瓶须 解决方案:分区 读写都很密集(w/s写,1w/s读)时出现的问题 从服务器cpu负载急剧上升 查询性能急剧降低(大量查询耗时超过800毫秒) 查询吞吐量大幅降低 主从复制出现较大的延迟 MongodB geo瓶颈原因 Mongodb目前(2.6.4版本)锁是库级别的锁,每一 次写都会锁库 每一次LBS查询,会分解成许多次单独的子查询 增大了整个查询的锁等待概率 长连接服务稳定性 SDCC 中国软件开发者大会 OFTWARE DEVELOPER CONFERENCE CHINA 硬件问题 不支持多队列的网卡,lo中断都被分配到了一个cpu核上,大量数据包到来的情况下,单个 cpu核无法全部处理,导致LV不断丢包,连接不断中断。 解决方案 更换支持硬件多队列的网卡(nte82575、82576, Boardcom的57711等, linux内核版本需要 在2621以上) 长连接服务稳定性 SDCC 中国软件开发者大会 OFTWARE DEVELOPER CONFERENCE CHINA 软件问题(Mina框架) 1内存使用控制不够细粒度,垃圾回收难以有效控制 2空闲连接检査效率不高,在大量连接的情况下会出现周期性CPU使用率飙高 3编解码组件在高并发下会出现消息被截断的情况 解决方案(快的自己的AO框架) 资源(主要是 Byte buffer池化减少GC造成的影响 广播时,一份 Byte Buffer复用到多个通道,减少内存拷贝 使用τ imerWhee?检测空闲连接,消除空闲连接检测造成的CPU尖峰 支持按优先级发送数据 Timer wheel ∨3阶段—体系化的架构改造sDcc 中国软件开发者大会 OFTWARE DEVELOPER CONFERENCE CHINA 截止到2014年4月份,我们解决了LBS瓶颈、长连接服务的稳定性,核心业务流程的稳定 性有很大提高。技术团队100多人,日订单600万左右,业务场景越来越复杂,原来很多非 核心问题变得越来越严重 稳定性差 经常会出现一些功能不可用。都忙着做业务需求,怎么快怎么来,后面堆积了大量的历史债 伸缩性差 核心业务和非核心业务混杂在一起 存储瓶颈 每天有几百万的订单,每天都发大量的券,单库单表已经无法支撑了 ●效率低下 所有业务都在一个系统里,每天很多的并行分支 ●安全问题 线上配置都是明文写在工程配置文件里的;XSS漏洞很多 没有监控 无法了解系统运行情况,故障定位效率很低 协议混乱 客户端和服务器的通信协议混乱,没有统一的文档和格式 体系化的架构改造 SDCC 中国软件开发者大会 OFTWARE DEVELOPER CONFERENCE CHINA 切都是为了更高的可用性 系统全局梳理 应用分布式改造 扩展性 无线开放平台 效率 数据层改造 伸缩性 日志收集与检索 核心要素 ●监控系统 安全 可用性 风控平台 配置中心 监控 研发流程自动化 系统全局梳理 SDCC 中国软件开发者大会 OFTWARE DEVELOPER CONFERENCE CHINA 流程与规范 建立研发流程、代码规范、SQL规范 执行严格的 code review,普及质量意识 ●建立故障问责机制 稳定性 梳理链路上的单点 梳理链路上的性能瓶颈 梳理每个环节的故障恢复机制,比如网络闪断后能否自动重连以及重连的影响 梳理JMM配置、 tomcat配置、应用参数配置 定期对系统做性能压测,科学合理的应对营销活动 定期 Ireview系统的机器部署 建立服务降级机制 业务梳理 小规模的迭代重构 不求一步到位,但求一直进步 【实例截图】
【核心代码】
标签：
好例子网口号：伸出你的我的手 — 分享！
小贴士
感谢您为本站写下的评论，您的评论对其它用户来说具有重要的参考价值，所以请认真填写。
- 类似“顶”、“沙发”之类没有营养的文字，对勤劳贡献的楼主来说是令人沮丧的反馈信息。
- 相信您也不想看到一排文字/表情墙，所以请不要反馈意义不大的重复字符，也请尽量不要纯表情的回复。
- 提问之前请再仔细看一遍楼主的说明，或许是您遗漏了。
- 请勿到处挖坑绊人、招贴广告。既占空间让人厌烦，又没人会搭理，于人于己都无利。
关于好例子网
本站旨在为广大IT学习爱好者提供一个非营利性互相学习交流分享平台。本站所有资源都可以被免费获取学习研究。本站资源来自网友分享，对搜索内容的合法性不具有预见性、识别性、控制性，仅供学习研究，请务必在下载后24小时内给予删除，不得用于其他任何用途，否则后果自负。基于互联网的特殊性，平台无法对用户传输的作品、信息、内容的权属或合法性、安全性、合规性、真实性、科学性、完整权、有效性等进行实质审查；无论平台是否已进行审查，用户均应自行承担因其传输的作品、信息、内容而可能或已经产生的侵权或权属纠纷等法律责任。本站所有资源不代表本站的观点或立场，基于网友分享，根据中国法律《信息网络传播权保护条例》第二十二与二十三条之规定，若资源存在侵权或相关问题请联系本站客服人员，点此联系我们。关于更多版权及免责申明参见 版权及免责申明
网友评论
我要评论