指数级增长背后，滴滴出行业务系统的架构升级

基于这样的想法,我们就思考如何设计真正高度抽象的工具.简单起见,我们把滴滴出行的过程抽象成一个框架(见上图),这并不是完整的框架.有颜色的地方表示出租车、快车、专车、代驾共同的流程,只要组合各种流程就可以实现整个业务形态的能力.在这个框架里可以定制所有业务形态的车标、提示语、匹配的模型、计价模型等功能.

当时梳理这个抽象的时候,我们感觉非常兴奋,因为这意味着在这个基础之上就可以简易扩展出滴滴未来的业务形态.只要滴滴还是在做需求和服务的匹配,基本上就离不开这样一种套路.

客户端怎么拆?

首先就是客户端,最重要的是需要将业务拆出来.以前所有业务放在同一个仓库里,如果不小心提交了一段错误代码就会带来灾难性的后果,所有业务工作可能都会受到影响.以前编译速度也很糟糕,大家可以想象,每次下载代码都会有几个头文件发生改变,由于循环依赖的缘故几乎所有文件都要重编,二三十分钟后才能重新调试,这个过程让人极度崩溃.

对于iOS,我们用cocoapods把业务拆到不同的pod里面；对于安卓,我们把业务拆分打包并用Maven管理起来.我们拆分方法如下图所示,其中虚线框部分展示的是公共框架,最开始没有很细致分割,只是把它放在一个独立仓库里,保证依赖关系充分清楚,后面就可以随时把代码独立出来,使其变成单独的模块.

同时,我们也在开发构建系统.原生的构建系统使用起来会有很多问题,它并不支持多人并行开发,如果要实现一个舒适的工作流就需要定制.我们还做了网络和日志的封装,将其放在下层.还有一个业务整合的基础框架,包括滴滴出行的App界面框架、首页导航栏,各种业务可以注册自己的入口,并在导航栏里进行切换.

业务之间没有任何代码耦合,比如出租车和专车业务没有关联性,那么代码也没有任何相关的地方,这意味着开发出租车业务的时候,完全没有必要实时更新专车代码,集成的时候也不会因为专车代码而造成问题.

最顶层的One Travel可以通过简单的配置分业务包,比如可以输出只有出租车业务的包,在这上面开发测试速度比较快,整体也会比较灵活.One Travel里面只有极少的代码,未来会改成没有代码、通过脚本就可以生成的项目.

怎么做页面的解耦?上图中是一种类似数据库缓存的设计.从客户端角度来看,如果把服务器当做一个数据库,最终状态存储在服务器,而客户端里存着的是跟服务器同步过的最新状态的缓存.客户端不太可能做到精确的数据同步,一定是每隔一段时间同步一次,或者是在关键节点上靠服务器推送得到订单状态变化.

（编辑：东莞站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!