滴滴出行大中台业务架构.pdf

滴滴出行大中台业务架构

1

经历了5年的发展，滴滴出行现已拥有4.5亿用户、超过2100万车主，业务覆盖400+城市。

在创业初期，为了快速拥抱业务，架构的建设在体系化、完善度等方面会有所不足。随

着时间的推移，架构在可持续性、稳定性等方面不断进步。

2017年12月1日，在51CTO主办的WOTD2017全球软件开发技术峰会主会

场上，滴滴出行执行总监赖春波做了主题为《如何构建滴滴出行业务中台》的精彩演讲。

从中我们可以了解到滴滴出行构建业务中台的原因及在发展过程中遇到的问题和应对

的策略。

构建业务中台的四个原因

2015年末，滴滴出行在短时间形成了包括快车、出租车、专车、顺风车、代驾等多

业务的垂直化架构。随之，滴滴启动了中台战略整合业务系统。

决定构建业务中台主要出于四方面考虑：专业深度、人力资源、用户体验、全局打通。

专业深度。由于是多业务垂直化的架构，会有多个团队开发同样的架构，这就需要很多

的工程师。

每个团队都是用最快速的方式构建流程，所以技术很难做深。这样一来，导致客户端的

流畅度不高，后端不稳定，影响可扩展性。

2

人力资源。从原则上来说把每个团队加到足够的人，每个架构都能有很好的发展。但工

程师的薪资都非常高，招聘大量工程师来同样的架构，研发成本高昂。还有些时候，

即使你愿意花钱，也招聘不到合适的人。

用户体验。流畅度、稳定性、扩展性、界面、交易流程等都是影响用户体验的重要因素。

在当时的组织结构和研发情况下，会出现业务的应用场景不同，交易流程却相同的问题，

这样很影响用户的体验。

全局打通。所有业务本质都是出行，出行本质具有协同效应。但在各自独立发展情况下，

业务间完全没有协同性，在构建中台过程中，我们可以逐步把协同性建立起来。

构建出行业务中台的挑战

构建出行业务中台并不是只有好处，也一定会带来很多问题，最大的问题是软件复杂度。

从业务角度来说，把所有业务合并到一个体系下，本身就是很难的事，再加上滴滴出行

是实时性O2O业务，场景差异很大，而且作为互联网公司，不仅有很多需求不明确，

还会不断持续变化。

这种情况下，想要用一套相对稳定、相对固定的架构去支持所有业务，十分困难。

从组织角度来说，滴滴出行有多个事业部，业务涉及400多个城市，组织和个人的变

化更快。

3

针对软件复杂度的挑战，中台制定了最基本的实现目标：在业务多元化发展的组织中，

去构建一套工程架构，构建一套组织结构及对应的管理机制，以保证业务可持续的又快

又好的发展。

滴滴业务中台的架构实践

在谈体对策与实践之前，先来看看整个业务中台的架构设计，如下图：

整个的架构设计分几个边界的上下文，好处在于把相关性不强的逻辑拆开，同时在一个

相关性下面，通过分层对业务进行更好的建模。

调度层作为入口去牵引多个业务线，业务流程层为调度层做服务，状态智能层用来支持

上面的两层。

在对业务和产品进行更好建模的基础上，进行了“五化”：服务化、异步化、配置化、

插件化、数据化。

4

服务化

服务化很常见，以下单为例，如下图：

下单流程能够调用很多服务，在多个层次，以接口层次结果进行拆解。

这里需要提醒的是服务化要注意如下三：

服务之间的协议和规范要建立好。

注意控制力度，力度太小、太大都会有问题。

随着时间的发展，服务化本身要不断的进。

异步化

5

对每个事件的非核心