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

《指数级增长背后，滴滴出行业务系统的架构升级》要点：
本文介绍了指数级增长背后，滴滴出行业务系统的架构升级，希望对您有用。如果有疑问，可以联系我们。

成立四年,估值已超260亿美元,公司指数级发展、业务爆炸式增长,在此背景下,滴滴出行业务系统的架构升级是怎样进行的?本文根据滴滴出行平台产品中心技术总监——杜欢在2016ArchSummit全球架构师(深圳)峰会上的演讲整理而成.

老司机简介

杜欢,滴滴平台产品中心技术总监.2015年加入滴滴,负责公司公共业务、客户端/前端架构和新业务孵化,致力于用技术手段解决业务痛点和提升研发效率,曾作为技术负责人主导公司技术架构升级以支撑公司业务快速迭代的需求.在加入滴滴前有长达五年的创业经历,具有丰富的团队管理经验,熟悉移动互联网应用的整个技术栈.

今天给大家主要介绍的是去年滴滴内部做的一次重大架构升级,滴滴快速发展的过程中,系统的迭代速度和其他方面的设计遇到了很多困难,这次升级就是为了解决这些困难.

去年我们做了一次非常大的重构.上面图中是今天要讲的大纲,我会从问题本身出发,回顾一下整个过程,包括如何发现问题、分析问题和解决方案.最后,我也会提出一些想法,如何规避重蹈这样的覆辙.

挑战在哪里?

首先,我们看一下挑战在哪里.滴滴在出行领域是非常独特的公司,它的独特不在于业务模式多复杂,而在于它的发展非常快.滴滴的成立时间是2012年的6月,到现在为止才经过了四年的时间.

滴滴的成长速度十分惊人,到今天它的估值已经超过260亿美元,融资轮次非常多.如果不是因为竞争非常恶劣,滴滴也不会一直用融资的方法为自己开路.在这样的压力之下,滴滴所有的动作可能都会走形,所有的想法可能因为现在一些短期利益不得不进行一些权衡.

同时,公司的业务也在爆炸式地增长.如果滴滴只做一个业务,原本可以做得非常深入.滴滴从2014年开始加入了专车业务,2015年业务数量增加到七条,2016年已经超过十条.业务急速发展之中大家会思考,到底怎么做才能使这些还不稳定或者还没有想清楚的业务很好地迭代起来.

想到最简单的方法是,如果新业务跟某个旧业务非常类似但又不完全一样,我们就把旧业务的旧代码复制并修改,这样新业务就做出来了.之前,这种情况经常发生,就造成了很大的问题.

在2015年上半年,滴滴整个系统已经积累了很多问题,分布在乘客App、服务端、Web App之中.特别值得一提的是,服务端的问题并不是性能,而是在于巨大的耦合导致数据紊乱和迭代速度越来越慢.

滴滴的独特性迫使我们独立思考这些问题,所有的解法都要针对滴滴现状,而不是看哪个大公司是怎么做的,然后直接复制过来.

现状是什么?

在解决问题之前,我们需要了解现状是怎样的.如图所示,在2015年下半年,滴滴的系统架构分为四层.最顶层是用户应用,每一个用户应用就是一个端,也就是用户所能看到的入口.然后是接入层,这是非常传统的结构,我们用了Nginx,还专门做了TCP接入层.

在业务层,Web是非常大的集群,有非常大的代码量,我们只对业务做了分割,有策略引擎、司机调度.在数据层,有KV集群、MySQL集群、任务队列、特征存储.这是任何一个初创公司应该有的架构,我们对这个架构并没有做特殊的策划,仅仅在这个技术体系里面把业务逻辑实现出来.

上面这张图可能会比较有趣.右边这个红色的球,代表的是重构之前App依赖的关系.当时我很想梳理一下App在模块之间是如何进行依赖的,然后我就写了一个脚本运行了一下,得到的结果让我很惊讶.我用蓝色的线表示正常的依赖,就是模块A依赖于模块B,A是B的上一层,B不会反过来依赖A,用红色的线表示异常的依赖,即A依赖B、B通过各种手段反过来依赖A,最后发现基本上都是红色的.

做任何模块的拆分,发现不得不面临这样的问题：把任何一个模块取出来就等于把所有模块都取出来,实际上没有做拆分.所以,关键是需要解耦模块结果.这是iOS的情况.安卓的情况更糟糕.

对于Web App来讲,最大的问题在于耦合性.以前滴滴只有出租车这个业务,最开始的Web App只有出租车,后来专车上线了,就在出租车里面加了专车入口,只是业务名不同界面会有小区别,后来加入了快车、代驾,都跟出租车差不多,没遇到太大问题.

再后来有了顺风车,顺风车跟其他功能不一样,整体界面是预约型的,有乘客和车主两种模式.如果在老首页里面开发顺风车成本太大了,需要和出租车业务线的人一起开发业务模块,如果未来做迭代,这种开发模式将非常痛苦.老首页的模块也没有做拆分,代码散落各地,只是通过打包工具拼接在一起,没有做模块化,所以整体情况也比较糟糕.

（编辑：辽源站长网）

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