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

模块下沉与代码治理息息相关.如果只是要求把所有代码拆分,而没有合适的拆分方法,这件事情是无法推进下去的.对于程序员来说,他们内心总有一种冲动想做有意思的事情,比如封装一个很有意思的模块给更多程序员用.大家并非不想做封装,只是如果封装并共享出来的代价太大,就会影响大家的热情.

模块下沉是一种机制,一方面我们应该鼓励,另一方面还应该让大家发现这是一件不得不做的事情.如果仅仅对内公开模块列表让大家自由选择,达不到模块下沉的目的.因为人都很懒,不想思考太多,只想尽快把事情完成,大家往往倾向于复制粘贴,也不愿意额外花时间做下沉.

怎么办呢?我们会给所有业务提供一个统一的SDK,里面包含所有能用的组件,大家必须使用它进行开发.如果业务模块稳定了并且比较通用,我们有工具和相应的简单机制把业务模块下沉下来,变成SDK的一部分,长期下去SDK会越来越大,只要SDK里做好分类和规划,上层就会越来越轻,我们可以真正专注于业务逻辑开发.

除了上面这些,最核心的一点在于,一定要把所有业务都做到“无状态”和“异步化”.

“无状态”这个概念在服务端比较容易理解.一般我们倾向于把各种业务做到无状态,这样容易做水平扩展.在客户端也是一个道理,也要考虑横向扩展性.一个简单的框架往往提供一些最基础的控件,比如按纽、列表,这些都不会耦合任何业务逻辑,所以很容易使用.

但是当业务做起来,大家习惯将一些状态放到业务控件里面,这在一定程度上方便了,但是一旦需要将业务进行重构或者进行模块化下沉的时候,就造成了非常大的困难.例如,一个模块如果大量通过全局变量或单例跟上下游耦合,那么这个模块就很难复用和重构,这些全局变量或单例就是状态.

所以,我们在客户端也提出使用“无状态”的方式,把存储的信息都放到外面.后面我会提到到底应该怎么样去做.

“异步化”也是解耦的方式.服务端的RPC类似于函数调用,如果参数变了,实现和调用的双方都要做改变,这很不透明,也不能够渐进式上线.我们用订阅/发布的模式对 RPC进行解耦,要求所有接口都要异步返回.

在客户端也是这样,比如做数据的缓存,想优化网络,我们不能够期待这个函数是一个同步函数,一定用回调的方式接受所有参数.所以做设计的时候,只要是有可能发生网络请求或者访问磁盘,在客户端也尽量异步请求数据.

刚刚讲的都是相对比较抽象的内容,接下来会说一下滴滴的业务形态本身.

滴滴是一个出行的平台,涵盖的是整个出行领域所有的出行需求.大家出行到底想要什么?就是到达自己想去的地方.实际上,我们的模型可以做得非常抽象和简单.比如,我想要打快车去机场,我就是一个需求方,我的需求会发到很多服务者那里去,服务者会根据特征进行一些匹配.

最基本的特征是服务能力,如果服务者能够开快车并通过了能力验证,这个需求就有可能发给他.如果开出租车的也有能力开快车,但是他还没有在平台上验证这个能力,就只能开出租车.一个人可以验证很多服务,白天可以开快车,晚上可以做代驾,做不同的事.

服务和需求的匹配是通过计价模型和匹配策略来实现的.发送需求的时候需要选择计价模型和车的类型.快车和专车服务过程大同小异,但是价格差别很明显,专车价格会贵很多.通过匹配策略可以实现各种需求的匹配.

例如,选择了拼车,这个需求会尽量匹配已经有拼友和顺路的车.如果选择专车,可以要求这辆车在指定时间来接人,这时候匹配策略会优化倾向这种方式.

滴滴所有的业务基本上都是以这种模式运转的,所有功能都是核心主干或者旁路,只要把业务模型抽象出来,基本上就能够满足大部分的业务了.

（编辑：辽源站长网）

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