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

在创业初期，为了快速拥抱业务，架构的建设在体系化、完善度等方面会有所不足。随着时间的推移，架构在可持续性、稳定性等方面不断进步。

2017 年 12 月 1 日，在 51CTO 主办的 WOTD 2017 全球软件开发技术峰会主会场上，滴滴出行执行总监赖春波做了主题为《如何构建滴滴出行业务中台》的精彩演讲。

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

构建业务中台的四个原因

2015 年末，滴滴出行在短时间内形成了包括快车、出租车、专车、顺风车、代驾等多业务的垂直化架构。随之，滴滴启动了中台战略整合业务系统。

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

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

每个团队都是用最快速的方式构建流程，所以技术很难做深。这样一来，导致客户端的流畅度不高，后端不稳定，影响可扩展性。

人力资源。从原则上来说把每个团队加到足够的人，每个架构都能有很好的发展。但工程师的薪资都非常高，招聘大量工程师来做同样的架构，研发成本高昂。还有些时候，即使你愿意花钱，也招聘不到合适的人。

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

在当时的组织结构和研发情况下，会出现业务的应用场景不同，交易流程却相同的问题，这样很影响用户的体验。

全局打通。所有业务本质都是出行，出行本质具有协同效应。但在各自独立发展情况下，业务间完全没有协同性，在构建中台过程中，我们可以逐步把协同性建立起来。

构建出行业务中台的挑战

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

从业务角度来说，把所有业务合并到一个体系下，本身就是很难的事，再加上滴滴出行是实时性 O2O 业务，场景差异很大，而且作为互联网公司，不仅有很多需求不明确，还会不断持续变化。

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

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

针对软件复杂度的挑战，中台制定了最基本的实现目标：在业务多元化发展的组织中，去构建一套工程架构，构建一套组织结构及对应的管理机制，以保证业务可持续的又快又好的发展。

滴滴业务中台的架构实践

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

整个的架构设计分几个边界的上下文，好处在于把相关性不强的逻辑拆开，同时在一个相关性下面，通过分层对业务进行更好的建模。

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

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

服务化

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

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

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

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

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

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

异步化

对每个事件的非核心或不需要实时反馈给客户端的逻辑进行拆解，核心的主流程会变简洁。对非核心的逻辑在事件上做订阅之后，进行二级处理。

以结束订单为例，如下图：

结束订单的时候有很多逻辑要做，但是都是通过 MysqlBinlog 处理或 MQ 处理。

配置化

服务化和异步化能解决很多迭代效率的问题，但由于系统、业务的复杂性，各个业务都有些差异，体现在不同的产品线、城市、区域、时间等等。

配置化的核心是对这些进行建模，把每个对象模型化，抽象成 ID，在不同的服务化里把这些可配置的能力进行抽象。

具体抽象过程，如下图：

第一级抽象采用的是类 iptables 的规则引擎判定产品分类，第二级的规则引擎由模块自定义。

所有配置化都是用的自生成平台，要配置什么，自定义配置即可，这个过程是动态进行的。

当前业务中台已经可以支持上千个配置点，比如不同层次的计价规则不一样、不同产品线的车样子不同、不同的场景，如拼车和接送机，管控规则也不一样等等。

插件化

配置化解决的是业务线差异问题，但如遇到逻辑差异较大的情况，就要做插件，统称为 FPI。

在 FPI 的能力上，不同的团队可以开发很多插件，在特定的配置点下，对它的逻辑进行加载。

真正业务流程到这儿，可以调起它对应的插件做出来。对于一些没有差异化需求的业务，可以用开发的 default 逻辑，这是更极端的灵活性的体现。

有灵活性的体现后，团队还可以做一些组织上的调整，原来每个服务或者平台是一个垂直化的架构，有些团队是横向，是 FT，有些 FT 是接送机 FT，专门做接送机的事情。

通过插件的形式在每个系统加载它的插件，它就可以跟着业务思考、跟着产品思考这个业务该怎么走、这个产品怎么演化。

相对的逻辑是更加专注的，这也带来很好的组织结构对中台的适应性。

数据化

在大数据时代，数据是不得不考虑的问题，所以在业务中台，要实现全局打通，本质是要把数据打通。

所以我们制定了离线分析与在线决策的方案，如下图：

第一个是离线做分析，可以做数据血缘、模型训练，同时可以把它放到在线决策层面，构建很好的智能客户引擎和交易引擎，这个可以干预，因为干预可以让升舱或者多业务线的清单成为可能。

因为有这样的决策，使在线服务的管控和判断做得更加智能。

数据化方面，需要注意以下三方面：

• 让数据更加规范和标准化。

• 构建完整的数据流，从在线到离线，从日志到模型的在线使用。

• 引入机器学习的算法、人工智能的算法去构建在线数据智能的决策。

这是业务中台的五个对策，主要解决传统的系统架构问题，怎么做到高耦合和内聚，怎么提高迭代。

配置化和插件化解决灵活性问题，把灵活性开放给不同团队。数据化实际上是中台赋能业务，有中台的赋能才能变得更好。

经验总结

业务中台从无到有，到被应用的实践过程中，积累了很多实战经验。主要分享以下几点：

第一点：成功实现最大的业务孵化中台是滴滴出行构建业务中台最大的经验。

因为最大的业务最复杂，把最复杂的业务搞定，用最复杂的业务落地别的业务会容易。也就是从快车开始做，逐步整合专车、出租车、代驾等。

第二点：稳定，中台对业务有收益，最根本的是保证稳定，稳定是发展的前提和基础。

在整个构建中台的过程中非常重视稳定性，有各种机制，包括灰度发布、分层次发布、流量回放、全链路压测等等，保证代码的质量和系统的稳定。

第三点：加强沟通，平衡多业务的优先级。

滴滴出行有多个业务，有很多大区和城市，每个地方都有很多需求，要有一套机制和资源池。

如何保证相应每个业务都能按照所对应的在公司的重要性来获取部分资源，要保障它的灵活性和效率，所以要有很多沟通工作，有很多平衡的工作。

第四点：中台系统要不断演进，不能一成不变，要发现问题、解决问题。

业务中台不是一蹴而就，而是要在发展过程中不断的变化，持续迭代。

第五点： “没有最好，只有最合适”！

所有中台都一定是适合某个公司特点，最合适的中台是当你深入了解业务、产品、系统、组织，而且不仅了解今天在哪里，还要了解过去是怎么演变而来，未来又会怎么演化。

只有当了解所有的东西之后，才能做出最好的中台架构设计。