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

ArchSummit全球架构师峰会深圳站2016滴滴出行业务系统的架构升级滴滴出行/杜欢关于·我•2015年5月加入滴滴，第一个项目即负责公司级重构项目的技术架构设计•曾在微软和百度工作，后自主创业五年有余，深耕于游戏行业•熟悉前后端各种工程类技术栈，对各种新技术持续保持关注•喜欢对事物进行抽象，寻找其中优雅简洁的本质大纲•挑战在哪里？•现状是什么？•该如何入手？•客户端怎么拆？•WebApp怎么拆？•服务端API怎么拆？•效果怎么样？•如何避免重蹈覆辙？挑战在哪里？公司规模指数级增长2012/6：公司成立2012/12：A轮300万美元2014/1：D轮7亿美元及补贴大战2015/2：滴滴和快的合并2015/9：更名“滴滴出行”，全面出击2016/6：累计融资超过100亿美元业务数量爆炸性增长快车专车出租车顺风车企业代驾豪车试驾海外小巴公交积压大量难以解决的问题乘客App业务高耦合组件封装少测试消耗大发版周期长服务端服务分层少重复代码多数据表混乱迭代速度慢WebApp入口高耦合黑魔法遍布体验不一致技术栈分裂现状是什么？2015年下半年系统架构KV集群MySQL集群NginxWeb集群TCP接入层Push服务坐标流分发乘客AppWebApp司机AppVIP策略引擎司机调度任务队列特征存储企业App用户应用接入层业务层数据层2015年下半年乘客App结构•基本情况–iOS曾经历过一次大规模重构，已经沉淀出一些公共组件，但是依赖关系过于混乱–Android一直野蛮生长，没有公共框架和特别的设计•iOS模块依赖分析–分析#import和#include–一个物理目录算作一个模块–存在循环依赖，标为红色–单向依赖，标为蓝色2015年下半年WebApp结构•基本情况–由于历史原因，所有业务入口耦合在出租车代码中，业务修改入口需要更改出租车的仓库–发送订单之后页面跳转到各个业务–前端代码没有模块化，仅做了简单的代码合并–所有渠道使用同一份代码，充斥着黑魔法–没有公共组件，也没有机制来沉淀组件重构前的WebApp首页2015年下半年API结构•基本情况–API层仅存在业务线级别的划分–业务内缺乏模块划分，所有API混合在一个仓库中–API和后台通过数据库直接共享信息，没有model封装–API的日志没有统一规范，监控、大数据分析、反作弊等不统一–API函数长度惊人，且存在大量重复代码–快车API项目总代码量达到百万行API存储该从何入手？重构思路将类似的模块归类及合并，再逐步优化从前到后、从粗到细•v0.5：2015年Q3/Q4–乘客App代码按业务拆分–WebApp首页代码按业务拆分–提供各种方便组件下沉的构建流程和开发工具•v1.0：2016年Q1/Q2–API服务化改造–平台服务下沉核心关注点关键动作按照产品逻辑，重新划分模块提供模块下沉所需要的工具和流程将不同模块拆分到不同仓库之中全新的基于模块的构建系统消除模块间的循环依赖控制模块下沉所需成本独立的模块开发、测试、上线流程临时的全公司需求管控代码治理+模块下沉核心设计思想无状态异步化客户端互相独立无依赖的界面流程异步获取共享数据WebApp业务互不干扰的并发加载异步获取共享数据服务端易于扩容的无状态服务单元用订阅/发布模型解耦业务模型的理想形态服务者需求方交通工具匹配策略计价模型能力模型高度可配置的出行工具客户端怎么拆？乘客App方案•所有业务都作为独立仓库从主工程抽离出来，可单独运行•iOS采用Cocoapods；Android采用gradle+maven•暂时不关注业务内部的代码质量问题，由业务自行演进，只通过制定一些规则来引导乘客App跨页面解耦乘客App组件化乘客App业务集成方案对外发版apk/ipa部门A部门B部门CWebApp怎么拆？WebApp方案•实现一个新的业务框架，提供入口调用规范•用scrat/webpack管理组件依赖•动态加载业务代码，支持离线缓存和分级灰度•控制每个业务代码加载时间和未捕获异常，避免造成全局性灾难业务线代码WebApp方案•实现一系列公共组件，提供贴近客户端的交互体验–字体和颜色规范–按钮–导航栏–弹层–地址列表–时间选择器–进度条–……服务端API怎么拆？服务器API拆分PlanA：可拼接的业务组件•2015年方案–将业务按照抽象的可复用的组件进行拆分–基于长连接的应答式可靠安全的自定义通信协议–基于“消息”的订阅/发布模式，每一个worker都是一个最小业务单元，可通过配置服务随意拼接worker顺序、插入新worker、复制流量–统一的订单系统optimus–统一的账号、支付、分单引擎等核心组件Appconndchatrouterkafkaworker1worker2responseoptimusPlanA的优缺点•优点–函数式编程思想，类似erlang的actor模型，每个worker都是逻辑十分单纯的功能，极高的逻辑内聚性–Worker的上下游可方便的通过配置修改或添加–所有请求可追踪、重放、复制、进行实时大数据分析–天然支持灰度上线、动态容量伸缩、有损服务•缺点–方案抽象度过高，超出团队可接受水平–遗留系统代码完全不可复用，整体开发量巨大–服务端框架全部自研，缺乏必要的工具链支持最终半途而废……服务器API拆分PlanB：•2016年方案–回归现实，先从遗留代码拆分开始，以面向对象思路进行拆分–保持接口不变、数据存储不变，将一次函数调用变成多次RPC调用–小步快跑，多次分城市灰度上线•缺点？效果怎么样？乘客App重构前重构后业务开发业务间代码互相影响，经常因为业务一个修改全局buildbreak业务独立开发测试，互不干扰组件化基本靠代码拷贝，无法组件化每个组件都可做到独立仓库管理，独立更新周期构建速度改动代码经常会造成全部重新编译，一次编译30分钟任何修改对编译速度的影响都非常有限，能极快的完成编译迭代速度基本两周一个版本，半年内曾两次因为业务间互相等待造成重大延期稳定两周一个版本，很有节奏感Crash率1%0.3%WebApp重构前重构后业务开发业务的首页功能开发依赖于出租车团队排期业务独立开发测试上线，互不干扰组件化基本靠代码拷贝，无法组件化每个组件都可做到独立仓库管理，独立更新周期加载速度弱网环境下，firstrendering时间长全部资源离线缓存按需加载，firstrendering时间大幅提升用户体验跟乘客App相比过于简单的地址选择、时间选择、导航栏等控件极度贴近原生乘客App的各种控件体验如何避免重蹈覆辙？重新思考业务模型：抽象、抽象、再抽象需求表达匹配供给提供服务支付费用形成从客户端到服务端的FeatureTeam支付组件账号组件App服务端消息组件…业务A业务B业务C平台业务垂直业务支付服务账号服务消息服务…业务A服务业务B服务业务C服务……提供一个标准化组件平台