滴滴出行平台业务架构演进

桔妹导读：为了满足不同用户在价格、体验等方面的差异化诉求，滴滴提供了越来越丰富的品类，这些品类大体流程是类似的，在一些细节体验上有差异，一套架构如何兼顾隔离和复用，同时支持这些品类，且看滴滴服务端技术的湾流平台怎么做。

1. 

项目背景

在滴滴打车业务中，服务端API向上接收端上请求并组装返回，向下串接订单、计价、收银等业务中台的各个系统，完成整个打车流程，湾流平台项目期望在服务端API层打造一个「出行中台」。在已有业务中台的情况下，为什么还要在业务「前台」API层打造一个「出行中台」，这和出行业务的流量模式是分不开的。

▍1.1 流量模式

▎1.1.1 传统和业界常规的“锥状”流量分配模式

传统的典型中台架构是“大中台小前台”，造就这种架构的原因与流量分配模式相关。以电商领域为例，中台抽象了电商相关的业务实体如：订单、收银台、商品等，而不同业务线之间的流量入口是分开的，不同BU间能够以小前台的方式闭环实现。这种“大中台小前台”的架构，可以支持快速构建原型产品进行试错探索，中台提供电商标准的基础能力，前台各自闭合实现B2C、C2C等业务，而业务间互不影响。

流量分配模式表现为：多业务（或品类）开放的前台流量接入，转化至统一有限的业务中台，最终落至基础平台。

▎1.1.2 网约车独特的“菱形”流量分配模式

滴滴网约车业务核心是打车，为了满足不同用户的需求（定价、应答率、体验等），通过品类区分提供差异化服务能力，从最初的出租车、专车、快车延展到了如今几十个品类。而入口始终围绕在司乘两端、开放平台。

流量分配模式表现为：多品类由统一的端接入流量入口（API）并完成各品类的主要业务逻辑处理，再交由统一的业务中台，最终落至基础平台。

网约车的「菱形」流量分配模式注定：服务端API一方面需要支持一些跨BU的平台级需求，如：春节服务费、疫情停开服等；另一方面也要支持不同BU间的差异化需求，如出租车使用打表计价不用线上计价等。

随着品类越来越丰富，这些差异逻辑也越来越多，导致系统越来越臃肿，复杂度越来越高，迭代效率下降。所以需要将服务端API通用的部分下沉，并且开放差异定制的机制，同时兼顾隔离和复用，湾流平台项目应运而生。

▍1.2 服务端API职责定位

在开始前，需要先明确服务端API的核心职责。

◎　核心职责

• 流量染色：识别和定义接入流量中的品类、场景、功能，并转义标识为统一的业务特征。

• 流程串接：根据不同事件/请求按照相应的逻辑和流程调用下游服务，以完成具体的功能。

• 数据渲染：将处理结果数据按不同的端或品类/场景要求渲染成对应的数据视图。

◎　终极问题

• 复用：what（复用什么，复用到什么级别）, how（怎么实现复用）

• 隔离：what（隔离的是什么），how（隔离机制是什么）

▍1.3 湾流平台演进

在过去几年时间里，基于上述背景我们一直在不断探索，以下简单介绍下湾流平台项目前两个版本迭代的情况。

▎1.3.1 湾流平台1.0（2017-2018）

1.0阶段主要解决的是快速增加新品类和不同BU间代码隔离的问题，使用配置化和插件化解决。配置化主要是统一了上下游产品描述协议，形成产品描述N元组，并抽象一套通用的N元组到功能的映射规则；插件化利用插件包隔离不同BU间的代码，运行时插件选择器根据流量特征分发到对应插件包。

◎　遗留问题