滴滴打车架构演变及应用实践

2020-03-01 199浏览

  • 1.滴滴打⻋车架构演变及应⽤用实践 杨振麟   MagicYang
  • 2.⾃自我介绍 • 2010-­‐2012  百度    ⾼高级⼯工程师   • 2012-­‐Now    滴滴打⻋车    技术总监
  • 3.内容提要 • 聊什么   • 滴滴架构演变历程   • 3⽉月流量洪峰应对   • 当前架构介绍   • 未来规划   • 不聊什么   • 具体业务数据  :0   • 业务相关性较⾼高的技术细节  :)
  • 4.滴滴架构进化过程 进化 服务化 ⼯工业时代 ⽂文明终结？ LNMP集群进化 铁器时代 LNMP集群 单机LNMP AppEngine ⻘青铜时代 ⽯石器时代 远古时代 时间 2012.11 2013.4 2013.8 2013.12 2013.2 Now
  • 5.远古时代 • • • • 时期：2012.7-­‐2012.11   架构：公有云、裸PHP   流量：<  10W   团队：2研发，0运维
  • 6.远古时代 • 优点   • 零运维成本维护⼀一个线上LNMP环境   • APNS消息推送、短信、⽇日志等服务   • 代码托管、发布   • 免费⼆二级域名   • 缺点：   • MySQL存储引擎类型限制   • Web服务不稳定（各种502、504...）   • DNS服务故障
  • 7.远古时代 司机APP 乘客APP API 浏览器 MIS DB 公有云
  • 8.⽯石器时代 • • • • 时期：2012.12-­‐2013.4   流量：<  100W   架构：租⽤用IDC＋单机LNMP   团队：3研发，0运维
  • 9.⽯石器时代 • 问题：   • 公有云环境不稳定且不可控   • ⺫⽬目标：   • 消除了环境⿊黑盒，让环境更可控   • 改进：   • ⾃自购主机   • ⾃自选IDC   • 搭建维护LNMP环境
  • 10.⽯石器时代 司机APP 乘客APP 浏览器 nginx API DB MIS IDC
  • 11.⽯石器时代 • 问题：   • IDC⺴⽹网络故障   • IDC服务响应不及时   • ⺫⽬目标：   • 解决⺴⽹网络环境可⽤用性   • 改进：   • 双机房，⼀一主⼀一备   • 通过第三⽅方配置服务切换   • App通过域名访问改为IP直连
  • 12.⽯石器时代 App 实时获取IP 第三⽅方配置服务 IP直连 IDC1 IDC2
  • 13.⻘青铜时代 • • • • 时期：2013.5-­‐2013.8   流量：<  3000万   架构：LNMP集群   团队：5研发，1运维
  • 14.⻘青铜时代 • 问题：   • 随业务发展，流量逐步到达单机极限   • ⺫⽬目标：   • ⽀支撑千万级流量   • 改进：   • 引⼊入负载均衡   • 具备基本扩容和容错能⼒力   • 减轻MySQL压⼒力（缓存、前后台DB分离）
  • 15.⻘青铜时代 LVS API API MIS nginx nginx nginx php-­‐fpm php-­‐fpm php-­‐fpm memcached memcached memcached NFS NFS NFS MySQL(Master) MySQL(Slave)
  • 16.铁器时代 • • • • 时期：2013.9-­‐2014.2   流量：3000万〜～2亿   架构：LNMP集群优化   团队：12研发，2运维
  • 17.铁器时代 • 问题：   • 轮询效率低   • 数据库查询负载⾼高   • 系统监控及报警平台缺失   • 改进：   • 司机订单轮询改为⻓长连接推送   • 数据库读写分离   • 引⼊入MongoDB解决空间检索问题   • 基于nagios的监控系统
  • 18.系统架构 乘客App 司机App LVS Web Web Web Push  Server MySQL(Slave) 订单分配系统 DBProxy MongoDB MySQL(Slave) MySQL(Master)
  • 19.监控 • 基础监控   • CPU、Mem、I/O、⺴⽹网卡带宽、进程存活   • Ngnix   • 流量、HTTP  Status(502、504、500…)   • Fast-­‐CGI（php-­‐fpm）   • 活跃进程数、error  log、slow  log…   • MySQL   • 连接数、主从延迟、slow  log…   • Memcached   • 连接数、QPS   • MongoDB   • 连接数、QPS
  • 20.⽂文明终结？ • • • • • • • • 微信⽀支付上线了   ^_^   补贴活动开始，  业务量上涨   ^_^   业务量持续上涨   ^_^   系统开始不稳定了   @_@  T_T
  • 21.流量变化 16 pv（亿） 12 8 4 0 2/1 2/10 2/19 2/28 3/9 时间 3/18 3/27
  • 22.应对⼀一：优化 • API逻辑优化   • LVS性能瓶颈   • 单核限制：CPU  Affinity   • 单点极限：LVS集群＋DNS轮询   • 内⺴⽹网带宽极限   • Memcached：数据压缩   • 分单系统调度导致DB压⼒力过⼤大：削峰
  • 23.应对⼆二：柔性 • 系统分析   • 看清业务与系统开销的对应关系   • 服务停⽤用（⼆二级服务）   • 信息展⽰示、配置…   • 服务降级（⼀一级服务）   • 附近⻋车辆静态化   • 司机坐标上报降频   • 策略简化   • …
  • 24.应对三：扩容 • 数据库硬件升级   • ⽔水平扩展   • Push服务集群化改造   • 开发LBS服务替代MongoDB
  • 25.⼯工业时代 • • • • 时期：2014.3-­‐Now   流量：5亿   架构：服务化   团队：50+研发，7运维
  • 26.业务架构 ⽤用户 乘客App web流量⼊入⼝口 企业版 司机App 出租⻋车⻋车台 API服务 ⽀支付服务 认证服务 坐标服务 地理围栏服务 反作弊服务 分单服务 抢单服务 POI服务 短信服务 推送服务 LBS服务 运营后台 客服后台 ⼲⼴广告后台 服务 后台 数据中⼼心 报表中⼼心
  • 27.系统架构 乘客App 司机App VIP VIP TCP接⼊入层 Nginx集群 Nginx集群 Push  Server LBS  Server Web集群 KV集群 DBProxy集群 Redis优先级队列 司机任务调度 MySQL集群 抢单策略引擎 分配策略引擎 特征存储
  • 28.未来技术规划 • • • • 架构：分城市部署   体验：SPDY协议   效率：DevOps   成本：HHVM、内部私有云
  • 29.We Need You • 我们正在寻找技术上追求卓越的架构师，⼀一起改变世界   • 您将能参与到——   • 复杂的业务场景   • 出租⻋车、⾼高端⻋车等产品   • 移动⽀支付平台   • 基础架构服务   • ⾼高速的业务增⻓长   • 千万级⽤用户   • 百万级交易   • 亿级流量
  • 30.Contact Me ! ! • 微信：yzl1573   • 邮箱：yangzhenlin@diditaxi.com.cn
  • 31.Q&A