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

我们也做了很多控件,这是内网发布的一些控件(见上图),每个业务只要关注自己的业务逻辑即可,公共的功能都可以使用控件.特别是选择地址的控件,它把前端界面交互和后端API都打包在一起,和客户端一样,只要引用它,就可以直接在Web App使用,无需任何服务端的开发.

服务器API怎么拆?

关于服务器API的拆分,我们最开始希望一次性实现理想方案,但是这个理想方案遇到一些问题.

我先来谈谈理想方案是什么.首先,滴滴业务一般都是基于订单流转推动各种业务动作.为什么会发生订单流转?是因为对乘客和司机做了一些操作,如果想象成一个客户端系统,就有点类似于触发各种用户事件.客户端动作根本上决定了信息该如何流转,所有事情都应该在客户端触发,触发之后来到了组件这一层,所有动作进行消费,然后进行下一步操作.

比如,用户提出一个需求,发单对需求进行过滤,判断是哪种需求,然后进行一些检查.快车有拼车和不拼车两种,发单的时候就可以知道是拼车还是不拼车,对于统一订单系统来说这就是个标志.无论拼不拼,这个单对用户都一样,无非就是消耗多少人民币、消耗几个座位还是消耗整辆车的问题.

之后分单系统会进行订单的匹配.一旦匹配成功,客户端有很多动作,司机确认接单,乘客可以看到确认.如果直接做成消息,客户端和服务端用一条总线连接,问题就解决了.

这里有一个很大的优点——可拼接,所有东西都组件化了.但是最大的问题在于抽象程度非常高.这是函数式的思想,要求所有的Worker都是纯函数,纯函数是非常高的要求,上下文状态必须要通过参数才行.我们发现很难做到这一点,因为所有系统必须有状态,一旦这样这个纯函数就不是纯函数了,要依赖外部的变量.

与面向对象设计的思路差异非常大,做函数式设计时很容易陷入一些抉择当中,如何定义输入、输出,如何划分流程.有一些流程划分成三段式,中间的流程异步调出去,又异步调回来继续后续流程,这种设计让人很纠结.

函数很依赖异步化,异步化会让数据流变得复杂.我们思考数据流的流向,以及每次数据流在流转的时候都需要设置的输入、输出.最终,这个方案并没有实施,虽然我们开发了接近半年的时间.

2016年,我们又重新思考了这个问题,这次是比较简单和现实的方法.首先我们进行了一些代码的隔离,把代码分开,之后对系统按照刚才讲的模块进行面向对象的抽象,比如发单就是单独的系统,订单也是一个单独的系统,支付的收银体系是一个系统,评价体系是一个系统.每一个系统变得很简单,互相之间用RPC调用关联起来.

这会有什么缺点呢?长期来讲缺点还是比较明显的,就是不容易扩展.现在我们设计的模型是来源于当前业务现状,如果业务发生改变,比如多了一种车型,就会遇到该如何扩展的抉择：应该提供更多API接口满足新的业务功能,还是在原有API修改上提供更多参数.

两种方法看起来都可以,但是本质上我认为无论用哪种方案都会使模块本身变得越来越臃肿,其实都是把很多种东西融合在一起,并不是很理想.当一个服务臃肿到一定程度之后又会出现以前的问题,又要再次做拆分和重构,甚至整个RPC调用流程都会发生很大震动.

从项目整体实施效果上来讲,这次重构最主要是解决了开发迭代的问题,能够让迭代速度更快.让我们比较意外的情况是,重构前客户端crash率非常高,重构中我们对代码进行了非常多的修改,同时还在用户体验上做了很多优化,但最终crash率反而大幅下降,从以前1%降低到0.3%.

重构后各个业务团队的开发模式发生了根本的变化,以前是各个业务各耦合在一起进行开发,现在各个业务都能独立开发,互不干扰,同时平台还会不断产出更多的公共组件.

如何避免重蹈覆辙?

（编辑：辽源站长网）

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