杜欢_《滴滴出行业务系统的架构升级》PDF版.pdf

《杜欢_《滴滴出行业务系统的架构升级》PDF版.pdf》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、ArchSummit全球架构师峰会深圳站2016滴滴出行业务系统的架构升级滴滴出行/杜欢关于·我•2015年5月加入滴滴，第一个项目即负责公司级重构项目的技术架构设计•曾在微软和百度工作，后自主创业五年有余，深耕于游戏行业•熟悉前后端各种工程类技术栈，对各种新技术持续保持关注•喜欢对事物进行抽象，寻找其中优雅简洁的本质大纲•挑战在哪里？•现状是什么？•该如何入手？•客户端怎么拆？•WebApp怎么拆？•服务端API怎么拆？•效果怎么样？•如何避免重蹈覆辙？挑战在哪里？公司规模指数级增长2016/6：累计融资超过100亿美元2015/9：更名“滴滴出行”，全面出击2015/

2、2：滴滴和快的合并2014/1：D轮7亿美元及补贴大战2012/12：A轮300万美元2012/6：公司成立业务数量爆炸性增长企业海外出租车顺风车专车快车代驾豪车试驾小巴公交积压大量难以解决的问题乘客App服务端WebApp业务高耦合服务分层少入口高耦合组件封装少重复代码多黑魔法遍布测试消耗大数据表混乱体验不一致发版周期长迭代速度慢技术栈分裂现状是什么？2015年下半年系统架构用户应用WebApp乘客App司机App企业AppVIPTCP接入层接入层NginxPush服务坐标流分发业务层Web集群策略引擎司机调度数据层KV集群MySQL集群任务队列特征存储2015年下半年

3、乘客App结构•基本情况–iOS曾经历过一次大规模重构，已经沉淀出一些公共组件，但是依赖关系过于混乱–Android一直野蛮生长，没有公共框架和特别的设计•iOS模块依赖分析–分析#import和#include–一个物理目录算作一个模块–存在循环依赖，标为红色–单向依赖，标为蓝色2015年下半年WebApp结构•基本情况–由于历史原因，所有业务入口耦合在出租车代码中，业务修改入口需要更改出租车的仓库–发送订单之后页面跳转到各个业务–前端代码没有模块化，仅做了简单的代码合并–所有渠道使用同一份代码，充斥着黑魔法–没有公共组件，也没有机制来沉淀组件重构前的WebApp首页2

4、015年下半年API结构•基本情况–API层仅存在业务线级别的划分–业务内缺乏模块划分，所有API混合在一个仓库中–API和后台通过数据库直接共享信息，API没有model封装–API的日志没有统一规范，监控、大数据分析、反作弊等不统一–API函数长度惊人，且存在大量重复代存储码–快车API项目总代码量达到百万行该从何入手？重构思路将类似的模块归类及合并，再逐步优化从前到后、从粗到细•v0.5：2015年Q3/Q4–乘客App代码按业务拆分–WebApp首页代码按业务拆分–提供各种方便组件下沉的构建流程和开发工具•v1.0：2016年Q1/Q2–API服务化改造–平台服务

5、下沉核心关注点代码治理+模块下沉关键动作按照产品逻辑，重新划分模块提供模块下沉所需要的工具和流程将不同模块拆分到不同仓库之中全新的基于模块的构建系统消除模块间的循环依赖控制模块下沉所需成本独立的模块开发、测试、上线流程临时的全公司需求管控核心设计思想无状态异步化客户端互相独立无依赖的界面流程异步获取共享数据WebApp业务互不干扰的并发加载异步获取共享数据服务端易于扩容的无状态服务单元用订阅/发布模型解耦业务模型的理想形态匹配策略能力模型需求方服务者交通工具计价模型高度可配置的出行工具客户端怎么拆？乘客App方案•所有业务都作为独立仓库从主工程抽离出来，可单独运行•iOS

6、采用Cocoapods；Android采用gradle+maven•暂时不关注业务内部的代码质量问题，由业务自行演进，只通过制定一些规则来引导乘客App跨页面解耦乘客App组件化乘客App业务集成方案对外发版apk/ipa部门A部门B部门CWebApp怎么拆？WebApp方案•实现一个新的业务框架，提供入口调用规范•用scrat/webpack管理组件依赖•动态加载业务代码，支持离线缓存和分级灰度•控制每个业务代码加载时间和未捕获异常，避免造成全局性灾难业务线代码WebApp方案•实现一系列公共组件，提供贴近客户端的交互体验–字体和颜色规范–按钮–导航栏–弹层–地址列表–

7、时间选择器–进度条–……服务端API怎么拆？服务器API拆分PlanA：可拼接的业务组件•2015年方案–将业务按照抽象的可复用App的组件进行拆分–基于长连接的应答式可靠conndchat安全的自定义通信协议–基于“消息”的订阅/发routerresponse布模式，每一个worker都是一个最小业务单元，kafka可通过配置服务随意拼接worker顺序、插入新worker、复制流量–统一的订单系统optimusworker1worker2optimus–统一的账号、支付、分单引擎等核心组件PlanA的优缺点•优点–函数式编