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