杜欢_《滴滴出行业务系统的架构升级》PDF版
滴滴运营方案
滴滴运营方案一、引言随着互联网的发展和移动互联网的普及，出行方式也发生了巨大的变革。
滴滴出行作为中国领先的移动出行平台，致力于为用户提供安全、便捷、高效的出行服务。
本文针对滴滴出行的运营方案做一份详细的分析和规划，旨在进一步提高滴滴出行的服务水平和运营效率。
二、滴滴出行的发展历程滴滴出行成立于2012年，经过近十年的发展，已经成为中国最大的出行服务平台之一。
滴滴出行通过移动端APP，为用户提供打车、快车、顺风车、专车、代驾、出租车等多种出行服务，满足了广大用户的不同出行需求。
在发展过程中，滴滴出行也经历了一些挑战和困难。
比如安全问题的突出、司机资质不够、乘客体验不佳等等，这些问题都为滴滴出行的健康发展带来了一定的影响。
然而，滴滴出行通过不断优化服务和改进管理，在市场上取得了较好的成绩，成为用户首选的出行平台之一。
三、滴滴出行的运营现状1. 服务范围广泛滴滴出行的服务范围覆盖了全国各大城市和地区，满足了用户在不同地区的出行需求。
同时，滴滴出行还推出了国际版APP，为海外用户提供出行服务。
2. 司机数量多滴滴出行拥有庞大的司机队伍，覆盖了全国各地。
司机覆盖面广，能够满足用户在各地的出行需求。
3. 服务种类丰富滴滴出行提供了多种出行服务，包括打车、快车、顺风车、专车、代驾等，为用户提供了多元化的出行选择。
4. 用户体验提升滴滴出行不断改善APP的用户界面和功能，提高用户体验。
同时，还推出了会员制度和优惠活动，吸引更多用户使用。
5. 支付方式灵活滴滴出行提供了多种支付方式，包括微信支付、支付宝、银行卡支付等，方便用户支付。
以上是目前滴滴出行的一些亮点，然而，滴滴出行仍面临一些挑战和问题，比如安全问题、司机管理问题、用户服务问题等。
因此，需要制定一份完善的运营方案，不断改进服务，提高用户体验。
四、滴滴出行的运营方案1. 加强安全管理出行安全一直是滴滴出行的重点和难点。
为了提高用户的安全感和满意度，滴滴出行应该加强安全管理措施，包括但不限于以下几点：（1）严格的司机背景审核：加强对司机资格的审核，包括身份验证、行驶记录、驾驶证等。
滴滴打车APP分析报告
滴滴打车APP分析报告目录1．行业背景分析 (2)1.1 移动出行市场体量巨大 (2)1。
2 移动出行市场发展空间广阔 (2)1。
3 移动出行市场备受青睐 (2)1.4 合并后滴滴打车稳居移动出行市场领头羊 (2)2. 产品概况 (2)3。
产品分析定位和功能 (3)3.1产品定位 (3)3.2用户群体 (3)3。
3地域分布 (3)3。
4用户评价 (4)3。
5产品功能 (5)3.6用户需求用户痛点改进建议 (7)3.7交互体验 (7)4。
运营和商业化 (12)4.1用户运营 (12)4.2盈利模式 (12)5。
竞品分析 (12)6. SWOT分析 (13)7。
总结 (14)1．行业背景分析1。
1 移动出行市场体量巨大衣食住行，出行在生活中是常见的要事.一直以来，政府主导的出租车及巴士地铁等公共交通成为人们短途出行的主要交通工具，2014年仅出租车市场就创造了约4000亿的市场规模,但是依然有40％的打车需求无法得到满足。
1.2 移动出行市场发展空间广阔一方面移动互联网技术的发展带来了充足的用户基础，使得移动出行变为可能；另一方面大城市“打车难”,尤其是出行高峰期打车难，已成为影响公众生活的重要问题，而利用互联网技术，提升了出租车的载客效能,同时还大量引进专车与私家车补充出行市场,满足广大司乘用户的利益需求,形成了良好的闭环，促进了市场的更好的发展。
1。
3 移动出行市场备受青睐移动出行因为在生活中的应用场景十分丰富，同时又能很好的解决人们的出行痛点，再加上国际市场上的成功先例，备受国内资本市场青睐，已经成为新的风口。
1.4 合并后滴滴打车稳居移动出行市场领头羊据易观智库数据，截止2014年12月，中国打车APP累计账户规模达1。
72亿。
其中,快的打车、滴滴打车分别以56。
5％、43.3％的比例占据中国打车APP市场累计账户份额领先位置；《中国专车服务市场季度监测报告2015年第1季度》数据显示，2015年第1季度滴滴专车(含一号专车）以80.9％的比例占据中国专车服务活跃用户覆盖率的第一名.2. 产品概况滴滴打车于2012年9月上线，是中国领先的打车软件，滴滴打车改变了传统打车方式，为出行用户搭建了多种用车选择平台，建立培养出大移动互联网时代下引领的用户现代化出行方式。
互联网公司(阿里、腾讯、京东、滴滴等)组织架构及职级薪酬研究
互联网公司组织架构及职级薪酬研究分享管理知识，与您共成长1大型互联网公司组织架构研究”华为的成功，从很大意义上讲就是人力资源的成功“互联网大厂组织架构变革研究近年以来，包括BAT在内的优秀的互联网企业组织架构变革思路事业驱动，充分授权事业部B U （事业组群B G ），业务独立、清晰，B U 对业务的完整发展负责、鼓励完整价值的创造。
客户导向，资源下沉“N +平台”，事业部B U +能力服务平台S B U（资源、技术、职能），B U 以客户需求和产品创新为驱动。
业务试错，鼓励创新内部V C 机制，动态实施业务孵化、业务升级与资源追加，鼓励业务创新。
扁平管理，快速决策产品经理制、独立工作室、微型事业部，“岗位-岗位”支撑模式、缩短决策和资源调度流程。
腾讯组织架构腾讯控股产业共赢基金总办WXG 微信事业群CDG企业发展事业群IEG互动娱乐事业群MIG移动互联网事业群OMG网络媒体事业群SNG社交网络事业群TEG技术工程事业群职能系统互动娱乐事业群办公室互动娱乐市场部互动娱乐业务管理部渠道营销部互动娱乐运营部互动娱乐研发部桌面安全产品部互动娱乐商务部国际 业务支持部韩国分公司互动娱乐合作产品部穿越火线产品部QT产品部QQ游戏产品部魔方工作室北极光工作室卧龙工作室BostonStudio琳琅天上工作室量子工作室光速工作室美国分公司SNS游戏组微信O2O微信基础平台微信支付微信开放平台互动娱乐邮箱通讯录员工关系中心统一账号移动互联网事业部办公室无线媒体产品部无线增值产品部无线游戏产品部3G产品部移动通信部电信事业部无线合作开发部无线研发部无线浏览器产品部无线安全产品部无线运营部无线国际产品部地图平台部搜索营销部搜索广告平台部搜索拓展u部区域分支机构网络媒体事业群办公室商务运营部广告销售部广告平台产品部网络媒体市场部在线视频部综合资讯部产经资讯部区域门户运营部网络媒体产品技术部网络媒体拓展部微博事业部（撤）腾讯网总编办社交网络事业群办公室即通综合部社交平台部即通产品部开放平台部即通平台部SNS应用部即通应用部云平台部社交用户体验设计部QQ会员产品部社交产品测试部生活服务电商部技术工程事业群办公室技术运营线搜索平台线运营管理部搜索平台部网络平台部研发运营部架构平台部社区搜索部企业IT部搜索XX部研发管理部基础架构部数据平台部客户服务部安全平台部用户研究与体验设计部腾讯研究院职能线财经线HR与管理线职级线办公室采购部服务采购管理部董事会办公室公关部合规交易部知识产权部行政部政策发展部项目管理部建设委员会（虚拟）建设工程部规划设计部上海分公司建设合约部北京分公司成都分公司法务综合部企业社会责任部腾讯互联网与社会研究中心内审企业发展事业群财务管理内控互动娱乐事业群财务管理资金管理网络媒体事业群财务管理总账及合并报表社交网络事业群财务管理投资公司管理技术工程事业群财务管理投资并购S系统财务管理应付管理在线支付部财务管理应收管理电商财务部预算及管理分析分公司财务资产管理移动互联网事业群财务管理税务及XXXHR与管理线办公室企业发展事业 群人力资源中心薪酬福利部互动娱乐事业群人力资源中心企业文化部移动互联网事业群人力资源中心人力资源部网络媒体事业群人力资源中心腾讯学院社交网络事业群人力资源中心人力资源平台部技术工程事业群人力资源中心S系统人力资源中心战略发展部在线支付部投资者关系部国际业务部投资并购部虚拟服务电商部大快消事业群电子文娱事业群时尚生活事业群仓储配送系统开放平台系统区域公司系统个人服务群组企业服务群组营销系统客服系统研发系统财务人力总裁办生鲜事业部家电事业部居家生活事业部消费品事业部3C文旅事业部时尚事业部新通路事业部全球售事业部TOPLIFE拍拍二手业务部仓储物流部物流开放业务部华北区域分公司大件物流部物流规划发展部华东区域分公司小件物流部运营研发部华南区域分公司冷链物流部客服部西南区域分公司众包（达达）售后部华中区域分公司东北区域分公司西北区域分公司国际供应链部消费金融部财富管理部证券业务部众筹业务部农村金融部保险事业部支付业务部供应链金融部金融科技业务部城市计算部海外事业部大市场体系无线品牌招商用户体验设计部运营研发部营销研发部职能研发部大数据部成都研究院云平台人工客服智慧客服法务战略行政公共事务审计监督京东商城京东物流京东金融运营研发职能系统董事会CEO王笑松闫小兵胡胜利王振辉陈生强徐雷张晨黄宣德廖建文推出“零售即服务（RAAS）的战略顶层架构设计，”无界零售“模式的战略宏图、提出打造”积木型“组织的构想。
产品需求文档：滴滴快车业务
滴滴快车业务产品需求文档“滴滴快车”是2015年5月7日起正式登陆滴滴打车APP，该服务属于营利性搭车服务，乘客的所有付费，软件平台收取大约25%费用。
消费者使用滴滴快车即可享受每公里0.99元、最低只需7元的超低价服务，本文作者针对滴滴快车业务，制作了一份产品需求文档。
一.产品定位及用户分析1.1 滴滴出行滴滴出行（原名：滴滴打车，Didi Taxi）是由北京小桔科技有限公司推出的一站式移动出行平台，它涵盖出租车、专车、滴滴快车、顺风车、代驾及大巴、货运等出行和运输服务。
Slogan为滴滴一下，美好出行。
致力于与监管部门、出租车行业、汽车产业等伙伴积极协作，以人工智能技术推动智慧交通创新，解决全球交通、环保和就业挑战。
1.2 滴滴市场分析1.2.1 市场规模数据来源：易观千帆，‘中国网约车市场APP榜单’数据来源：易观千帆，‘中国网约车市场APP榜单’1.2.2 供-需市场滴滴旗下的网约车主要涉及到两个方面：供应侧（司机）和需求侧（乘客）。
•供应侧分析（滴滴司机人群画像）如图：滴滴供应侧分析据泰一舆情和章鱼大数据（滴滴司机人群画像大数据解读），在地域分布上，80%的司机分布于中国的中东部且较为发达地区，例如浙江、广州、被警告等。
从司机年龄来看，专快车司机的年龄主要集中在31-50岁之间（64%）。
同时，工作时间灵活是其加入滴滴的主要原因。
•需求侧（滴滴乘客画像）数据来源: 比达咨询，《2018 中国网约车行业行业发展监测报告》据数据统计，在2020年疫情逐步趋稳的情况，截至5月，网约车市场活跃用户规模为6557.4万。
滴滴出行APP以5439.48万活跃人数占据榜单第一，且将近六成用户均为男性。
滴滴的用户虽然覆盖全国，但一二线城市占大多数。
1.4 需求总结2. 产品结构2.1 产品结构功能图2.2 产品信息架构图3. 全局说明3.1 登入页面3.1.1 权限说明3.1.1.1 未登入状态未登入状态进入APP，不可叫车出行、回复消息、进行支付、进行服务评价、查询订单、咨询客服、查询路线等。
滴滴业务架构设计
滴滴业务架构设计
滴滴业务架构设计是指在滴滴出行这一大型互联网平台上，为了支撑其业务运
营和发展，所需建立的各个系统模块之间的关系和运行机制。
业务架构设计是对滴滴业务的整体规划和组织安排，涉及到技术架构、数据架构、业务流程等方面的设计。
首先，滴滴业务架构设计需要考虑技术架构。
技术架构是指滴滴出行平台所采
用的技术框架和组件，包括硬件设施、网络架构、软件开发平台等。
在滴滴的技术架构设计中，需要考虑系统的稳定性、扩展性、安全性等因素，确保滴滴平台能够满足大规模用户的需求，实现高并发、高可靠的业务运营。
其次，滴滴业务架构设计还需要考虑数据架构。
数据架构是指滴滴平台的数据
存储、处理、传输等方面的设计，包括数据库选择、数据模型设计、数据同步机制等。
在滴滴的数据架构设计中，需要考虑数据的一致性、可靠性、安全性等因素，确保滴滴平台的数据能够准确、及时地为业务运营提供支持。
另外，滴滴业务架构设计还需要考虑业务流程。
业务流程是指滴滴平台的各项
业务活动之间的关联和协作关系，包括用户注册、订单生成、派单调度、支付结算等流程。
在滴滴的业务流程设计中，需要考虑用户体验、业务效率、风险控制等因素，确保滴滴平台的业务流程能够顺畅、高效地运转。
综上所述，滴滴业务架构设计是一个涉及技术、数据、业务等多方面的综合设
计工作。
通过合理的技术架构、数据架构和业务流程设计，滴滴平台能够实现业务的持续发展和创新，提升用户体验，满足用户的出行需求，实现业务的可持续发展。
出租汽车服务管理信息系统架构浅析——放百度
出租汽车服务管理信息系统架构浅析摘要：出租汽车是城市综合交通体系的重要组成部分，出租汽车服务管理信息系统是对出租汽车及行业的日常服务监管、运营管理的信息化手段，出租汽车服务管理信息系统的建设，将为公共交通信息化的发展起到推进作用。
关键词：出租汽车、管理系统、车载、智能服务终端。
1 . 概述出租汽车是人民群众日常出行的重要方式之一，是城市综合交通体系的重要组成部分，是社会文明程度的重要窗口，被称为“城市流动的风景线”和“城市的名片”。
随着我国一、二级城市人口的不断增长、作为城市道路交通旅客运输业的重要组成部分，出租汽车已成为社会公众出行不可或缺的重要交通工具。
城市出租汽车行业对于我国来说仍然属于新兴的行业，自形成以来就在政府摸索管理和自我不断完善的环境中成长，且发展速度较快。
不同发展阶段因外部环境的快速变化和政策的更迭滞后，极易造成出租运输市场的矛盾骤显，行业稳定性与一些传统行业相比仍有差距。
而面对我国出租汽车行业存在的种种现象，首要的问题既是如何行之有效地对出租汽车日常服务进行监管，如何更好地规范行业运营管理，因此信息化不可避免的将引入出租汽车行业的日常服务与监管中来。
2.需求分析1.1. 面向行业管理部门行业管理部门将通过信息化手段有效打击套牌车，避免拒载、甩客、宰客、不打发票等违规行为的发生；可以通过信息化手段对IC卡从业资格证进行管理，包括初始化、制卡、发放、换证等业务；通过出租车从业资格证的使用，对全市范围内的出租车运营行驶状态进行监督，并全程记录每个出租车的运营行驶信息；通过信息化手段获得行业相关信息为行业监管和决策提供数据支持；在重大节庆假日、外事活动等应急运力保障方面利用信息化技术提供有效的运力调配手段；同时行政执法人员应可利用信息化手段进行移动稽查，可对假证、年审年检、包括道路运输证和从业资格证，克隆车和非法运营车辆等违规行为进行监督稽查，并可实时自动记录违规车辆及人员信息。
1.2. 面向驾驶员通过信息化的手段为出租汽车驾驶员提供人身财产安全保障，满足驾驶员的需求，具体包括：防劫报作者简介：孙玉光，（1973-），主要研究方向：现代物流、交通运输信息化、智能交通、物联网、云计算等方面的研究。
滴滴出行大中台业务架构
滴滴出行大中台业务架构经历了5 年的发展，滴滴出行现已拥有4.5 亿用户、超过2100 万车主，业务覆盖400+ 城市。
在创业初期，为了快速拥抱业务，架构的建设在体系化、完善度等方面会有所不足。
随着时间的推移，架构在可持续性、稳定性等方面不断进步。
2017 年12 月 1 日，在51CTO 主办的WOTD 2017 全球软件开发技术峰会主会场上，滴滴出行执行总监赖春波做了主题为《如何构建滴滴出行业务中台》的精彩演讲。
从中我们可以了解到滴滴出行构建业务中台的原因及在发展过程中遇到的问题和应对的策略。
构建业务中台的四个原因2015 年末，滴滴出行在短时间内形成了包括快车、出租车、专车、顺风车、代驾等多业务的垂直化架构。
随之，滴滴启动了中台战略整合业务系统。
决定构建业务中台主要出于四方面考虑：专业深度、人力资源、用户体验、全局打通。
专业深度。
由于是多业务垂直化的架构，会有多个团队开发同样的架构，这就需要很多的工程师。
每个团队都是用最快速的方式构建流程，所以技术很难做深。
这样一来，导致客户端的流畅度不高，后端不稳定，影响可扩展性。
人力资源。
从原则上来说把每个团队加到足够的人，每个架构都能有很好的发展。
但工程师的薪资都非常高，招聘大量工程师来做同样的架构，研发成本高昂。
还有些时候，即使你愿意花钱，也招聘不到合适的人。
用户体验。
流畅度、稳定性、扩展性、界面、交易流程等都是影响用户体验的重要因素。
在当时的组织结构和研发情况下，会出现业务的应用场景不同，交易流程却相同的问题，这样很影响用户的体验。
全局打通。
所有业务本质都是出行，出行本质具有协同效应。
但在各自独立发展情况下，业务间完全没有协同性，在构建中台过程中，我们可以逐步把协同性建立起来。
构建出行业务中台的挑战构建出行业务中台并不是只有好处，也一定会带来很多问题，最大的问题是软件复杂度。
从业务角度来说，把所有业务合并到一个体系下，本身就是很难的事，再加上滴滴出行是实时性O2O 业务，场景差异很大，而且作为互联网公司，不仅有很多需求不明确，还会不断持续变化。
大数据-滴滴业务实时监控系统架构及实践
Holt-Winters时间序列分析模型介绍
议程
• 滴滴实时监控系统演变历程 • 当前架构及服务介绍 • 系统优化方向
Lambda架构的问题
• 同样的业务逻辑需要维护实时和离线计算两套代码 • 重新处理数据只能依赖离线计算，计算较慢
优化方向
• 实现“端到端”的Exactly-Once实时数据处理，不再需要离线修正 Ø Samza Local Cache Ø 智能感知Kafka Partiton变化 Ø Druid Kafka Indexing Service
Samza Unified ETL Job
• 数据格式转换 • 数据去重
Samza Metrics Computing
Samza HDFS Producer
HDFS
当前系统架构特点
• 高可用 • 易扩展 • 高性能 • 支持有状态的实时计算
为何选用Kafka？
Kafka 是一个高性能、高可用、易扩展的 分布式日志系统
Samza数据处理流程介绍
输入流
Partition 0
Partition 1
Partition 2
本地状态存储 (RocksDB)
Container 1
Task 0
Task 1
Task 2
Container 2
job
Checkpoint Stream
输出流
Changelog Stream
Samza的高可用性
缓存
客户端请求
Segements 查询
缓存
元数据
Druid Kafka Indexing Service介绍
Overlord
控制流 数据流
Middle Managers
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 缺点
– 方案抽象度过高，超出团队可接受水平 – 遗留系统代码完全不可复用，整体开发量巨大 – 服务端框架全部自研，缺乏必要的工具链支持
最终半途而废……
服务器 API 拆分 Plan B：
• 2016 年方案
– 回归现实，先从遗留代码拆分开始，以面向对象思路进行拆分 – 保持接口不变、数据存储不变，将一次函数调用变成多次 RPC 调用 – 小步快跑，多次分城市灰度上线
业务线代码
Web App 方案
• 实现一系列公共组件，提供贴近客户端的交互体验
– – – – – – – – 字体和颜色规范 按钮 导航栏 弹层 地址列表 时间选择器 进度条 ……
服务端 API 怎么拆？
服务器 API 拆分 Plan A：可拼接的业务组件
• 2015 年方案
– 将业务按照抽象的可复用 的组件进行拆分 – 基于长连接的应答式可靠 安全的自定义通信协议 – 基于“消息”的订阅 / 发 布模式，每一个 worker 都是一个最小业务单元， 可通过配置服务随意拼接 worker 顺序、插入新 worker、复制流量 – 统一的订单系统 optimus – 统一的账号、支付、分单 引擎等核心组件
乘客 App 跨页面解耦
乘客 App 组件化
乘客 App 业务集成方案
对外发版 apk / ipa 部门 A
部门 B
部门 C
Web App 怎么拆？
Web App 方案
• 实现一个新的业务框架，提供入口调用 规范 • 用 scrat / webpack 管理组件依赖 • 动态加载业务代码，支持离线缓存和分 级灰度 • 控制每个业务代码加载时间和未捕获异 常，避免造成全局性灾难
业务数量爆炸性增长
企业 出租车
专车 快车 代驾 顺风车 海外
豪车
小巴
试驾
公交
积压大量难以解决的问题
乘客 App
业务高耦合
服务端
服务分层少
Web App
入口高耦合
组件封装少
重复代码多
黑魔法遍布
测试消耗大
数据表混乱
体验不一致
发版周期长
迭代速度慢
技术栈分裂
现状是什么？
2015 年下半年系统架构
用户应用 Web App 乘客 App 司机 App 企业 App
核心关注点 代码治理 + 模块下沉
关键动作 按照产品逻辑，重新划分模块 将不同模块拆分到不同仓库之中 消除模块间的循环依赖 提供模块下沉所需要的工具和流程 全新的基于模块的构建系统 控制模块下沉所需成本
独立的模块开发、测试、上线流程
临时的全公司需求管控
核心设计思想
无状态 客户端 Web App 服务端 互相独立无依赖的界面流程 业务互不干扰的并发加载 易于扩容的无状态服务单元 异步化 异步获取共享数据 异步获取共享数据 用订阅 / 发布模型解耦
API
存储
该从何入手？
重构思路
将类似的模块归类及合并，再逐步优化
从前到后、从粗到细
• v0.5：2015 年 Q3/Q4
– 乘客 App 代码按业务拆分 – Web App 首页代码按业务拆分 – 提供各种方便组件下沉的构建流程和开发工具
• v1.0：2016 年 Q1/Q2
– API 服务化改造 – 平台服务下沉
大纲
• • • • • • • • 挑战在哪里？ 现状是什么？ 该如何入手？ 客户端怎么拆？ Web App 怎么拆？ 服务端 API 怎么拆？ 效果怎么样？ 如何避免重蹈覆辙？
挑战在哪里？
公司规模指数级增长
2016/6：累计融资超过 100 亿美元 2015/9：更名“滴滴出行”，全面出击 2015/2：滴滴和快的合并 2014/1：D 轮 7 亿美元及补贴大战 2012/12：A 轮 300 万美元 2012/6：公司成立
ArchSummit 全球架构师峰会 深圳站 2016
滴滴出行业务系统的架构升级
滴滴出行 / 杜欢
关于 · 我
• 2015 年 5 月加入滴滴，第一个 项目即负责公司级业 • 熟悉前后端各种工程类技术栈， 对各种新技术持续保持关注 • 喜欢对事物进行抽象，寻找其中 优雅简洁的本质
需求表达
支付费用
匹配供给
提供服务
形成从客户端到服务端的 Feature Team
平台业务 账 号 组 件 支 付 组 件 消 息 组 件 垂直业务
App
…
业 务 A
业 务 B
业 务 C
…
服务端
账 号 服 务
支 付 服 务
消 息 服 务
…
业 务 A 服 务
业 务 B 服 务
业 务 C 服 务
…
提供一个标准化组件平台
A pp
co n n
d ch at
ro u ter kafka
resp o n se
w o rker1
w o rker2
o p ti m us
Plan A 的优缺点
• 优点
– 函数式编程思想，类似 erlang 的 actor 模型，每个 worker 都是逻辑十 分单纯的功能，极高的逻辑内聚性 – Worker 的上下游可方便的通过配置修改或添加 – 所有请求可追踪、重放、复制、进行实时大数据分析 – 天然支持灰度上线、动态容量伸缩、有损服务
业务独立开发测试，互不干扰 每个组件都可做到独立仓库管理，独 立更新周期 任何修改对编译速度的影响都非常有 限，能极快的完成编译 稳定两周一个版本，很有节奏感
Crash 率
> 1%
< 0.3%
Web App
重构前 业务开发 组件化 加载速度 用户体验
业务的首页功能开发依赖于出租车团 队排期
基本靠代码拷贝，无法组件化 弱网环境下，first rendering 时间长
接入层
VIP
Nginx
TCP 接入层
Push 服务 坐标流分发
业务层
Web 集群
策略引擎
司机调度
数据层
KV 集群
MySQL 集群
任务队列
特征存储
2015 年下半年乘客 App 结构
• 基本情况
– iOS 曾经历过一次大规模重 构，已经沉淀出一些公共组 件，但是依赖关系过于混乱 – Android 一直野蛮生长，没 有公共框架和特别的设计
• 缺点？
效开发 组件化 构建速度 迭代速度
业务间代码互相影响，经常因为业务 一个修改全局 build break
基本靠代码拷贝，无法组件化 改动代码经常会造成全部重新编译， 一次编译 30 分钟 基本两周一个版本，半年内曾两次因 为业务间互相等待造成重大延期
重构后
重构后
业务独立开发测试上线，互不干扰 每个组件都可做到独立仓库管理，独 立更新周期 全部资源离线缓存按需加载，first rendering 时间大幅提升
跟乘客 App 相比过于简单的地址选择、 极度贴近原生乘客 App 的各种控件体 时间选择、导航栏等控件 验
如何避免重蹈覆辙？
重新思考业务模型：抽象、抽象、再抽象
•
iOS 模块依赖分析
– – – – 分析 #import 和 #include 一个物理目录算作一个模块 存在循环依赖，标为红色 单向依赖，标为蓝色
2015 年下半年 Web App 结构
• 基本情况
– 由于历史原因，所有业务入口耦合在出租 车代码中，业务修改入口需要更改出租车 的仓库 – 发送订单之后页面跳转到各个业务 – 前端代码没有模块化，仅做了简单的代码 合并 – 所有渠道使用同一份代码，充斥着黑魔法 – 没有公共组件，也没有机制来沉淀组件
业务模型的理想形态
匹配策略
能力模型
需求方
服务者
交通工具
计价模型
高度可配置的出行工具
客户端怎么拆？
乘客 App 方案
• 所有业务都作为独立仓库从主工程抽离出来，可单独运行 • iOS 采用 Cocoapods；Android 采用 gradle + maven • 暂时不关注业务内部的代码质量问题，由业务自行演进，只通过制定 一些规则来引导
重构前的 Web App 首页
2015 年下半年 API 结构
• 基本情况
– API 层仅存在业务线级别的划分 – 业务内缺乏模块划分，所有 API 混合在 一个仓库中 – API 和后台通过数据库直接共享信息， 没有 model 封装 – API 的日志没有统一规范，监控、大数 据分析、反作弊等不统一 – API 函数长度惊人，且存在大量重复代 码 – 快车 API 项目总代码量达到百万行