桔妹导读:为了满足不同用户在价格、体验等方面的差异化诉求,滴滴提供了越来越丰富的品类,这些品类大体流程是类似的,在一些细节体验上有差异,一套架构如何兼顾隔离和复用,同时支持这些品类,且看滴滴服务端技术的湾流平台怎么做。
流量染色:识别和定义接入流量中的品类、场景、功能,并转义标识为统一的业务特征。
流程串接:根据不同事件/请求按照相应的逻辑和流程调用下游服务,以完成具体的功能。
复用:what(复用什么,复用到什么级别), how(怎么实现复用)
隔离:what(隔离的是什么),how(隔离机制是什么)
配置化依赖于功能抽象,需要一套统一的抽象方法
宏观上,根据核心数据&职能对服务进行了拆分,将一个大模块拆分成多个垂直闭环的子模块,即领域化。通过分治的方式,降低了整体的复杂度,同时也解决了所有团队成员在一个模块开发导致的上线冲突和排队情况。
未做系统性的框架约束,迭代容易破坏原有结构
//配置文件,管理流程环节,以及提供给不同品类注册各自transport
{
"name": "ConfirmOrder,
"transports": {
"default": "\\DuKang\\Transport\\ConfirmOrderaseTransport",
"express": "\\DuKang\\Express\\Transport\\ConfirmOrderExpressTransport",
"luxury": "\\DuKang\\Luxury\\Transport\\ConfirmOrderLuxuryTransport",
"taxi": "\\DuKang\\Taxi\\Transport\\ConfirmOrderTaxiTransport",
},
"steps": [
{
"step_id": "fetchInfoStep",
"description": "获取基本信息"
},
{
"step_id": "confirmTravelStep",
"description": "确认行程信息"
},
{
"step_id": "confirmBillStep",
"description": "确认计价信息"
},
{
"step_id": "checkStep",
"description": "成单检查"
},
{
"step_id": "fillOrderDetailStep",
"description": "订单维度填充"
},
{
"step_id": "sendOrderCommandStep",
"description": "订单处理操作"
},
{
"step_id": "sendDriverCommandStep",
"description": "司机处理操作"
},
{
"step_id": "sendSchedulingCommandStep",
"description": "调度处理操作"
},
{
"step_id": "buildResponseStep",
"description": "构建响应"
},
{
"step_id": "asyncOperationStep",
"description": "异步操作"
},
{
"step_id": "writeLogStep",
"description": "日志处理"
}
]
}
// dukang框架核心执行过程
try {
// 加载并解析接口配置,包括BizConfig、StepConfig
$oBizConf = BizConfig::load($sConfigStr);
// 获取输入源数据,包括Request和基础数据获取
$oInputSource = new ConfirmOrdernputSource();
// 构造StepRuntime
$oStepRuntime = new ConfirmOrdertepRuntime($oInputSource);
// 将接口配置对象、StepRuntime放入流程调度器
$oFlowScheduler = new FlowScheduler($oBizConf, $oStepRuntime);
// 初始化传输器路由因子
$oTransportSelectFactor = new ConfirmOrderTransportSelectFactor($oInputSource);
if($oFlowScheduler->selectTransport($oTransportSelectFactor))
{
// 执行流程调度
$oFlowScheduler->run();
}
// 异常处理原则:接口外层只处理DuKangException和Exception,Step或者Ability处理异常则先处理逻辑再抛异常
} catch (DuKangException $e) {
$aResp = [
'errno' => $e->getCode(),
'errmsg' => $e->getMessage(),
];
echo json_encode($aResp);
} catch (\Exception $e) {
$aResp = [
'errno' => $e->getCode(),
'errmsg' => $e->getMessage(),
];
echo json_encode($aResp);
}
接下来,再展开对dukang的一些核心概念进行讲解
◎ 定义
针对单接口内不同运力(或品类)进行抽象得来的流程载体
任一业务必有其承载的流程和执行顺序
◎ 约束
BaseTransport覆盖当前接口业务的通用流程
任一接口内有且只有一个BaseTransport
XxxTransport覆盖不同运力(或品类)的差异化实现
任一接口内的差异化XxxTransport必须继承自BaseTransport
◎ 定义
针对单接口内的业务进行抽象出来的环节载体
单一Step是某一段业务环节或功能的具体实现
◎ 特性
单一Step是大粒度差异化(如豪华车/出租车)的有效手段, 可通过Override Step实现
Step间的通信通过统一运行时数据总线StepRuntime串联,理论上可实现热拔插
◎ 图例
业务流程驱动型接口:以串联各个处理流程为主
◎ 定义
流程串联运行时数据总线
◎ 约束
StepRuntime只能作为Ability的输入,不能在Ability及下层逻辑中对StepRuntime的业务特征和数据进行修改
◎ 定义
外部输入数据源,为TransportFactor准备数据
◎ 约束
进入Step之后具有只读属性,被StepRuntime引用,后续业务逻辑不可修改其包含的所有特征及数据内容
◎ 定义
业务传输器Transport决策因子
不同接口可能会采取不同的因子进行Transport决策
目前实现的有针对订单维度product_id,针对司机维度car_level
可选择端来源作为决策因子,如滴滴出行app、开放平台、礼橙专车app等
◎ 约束
Factor必须是确定可选择的几类因子,不能由RD同学自由编写
◎ 定义
◎ 设计原则
面向可复用设计
面向可扩展差异化设计
业务表达:播单计划 = $sStartAddDuseTime + $bIsDelayBroadcast + $bIsRepeatAssign+ $iBroadcastAssignType + $iBroadcastExpire
规范业务属性或字段语义,避免歧义和未知语义
// 模块根目录
├── Dukang // 新引入的内容,区隔老代码,未来将替代hermes
│ ├── Ability // 能力目录
│ │ ├── Common // 公用能力
│ │ │ ├── DispatchOrder
│ │ │ │ └── DispatchOrderComponent.php
│ │ │ └── VirtualPhone
│ │ │ └── VirtualPhoneComponent.php
│ │ └── Express // 品类特有能力扩展
│ │ └── DispatchOrder
│ │ └── DispatchOrderComponent.php
│ ├── Config // 接口配置
│ │ └── ConfirmOrder.json
│ ├── InputSource // 接口输入
│ │ └── ConfirmOrderInputSource.php
│ ├── StepRuntime // 全局数据总线
│ │ └── ConfirmOrderStepRuntime.php
│ ├── Model // 公用model
│ │ ├── Dao
│ │ ├── Driver
│ │ │ └── DriverModel.php
│ │ └── Order
│ │ └── OrderModel.php
│ ├── Service // 公用service
│ │ └── Driver
│ │ └── DriverService.php
│ ├── TransportFactor // Transport因子
│ │ └── ConfirmOrderTransportFactor.php
│ └── Transport // 流程串接
│ ├── Base
│ │ └── ConfirmOrderBaseTransport.php
│ └── Taxi
│ └── ConfirmOrderTaxiTransport.php
└── vendor
└── dukang
└── framework
├── idl // 数据字典(Dimensions,标准dto)
└── src // 框架代码
团队招聘
▬
滴滴服务端技术团队是滴滴网约车核心后台研发团队,负责网约车核心出行、品类技术、开放平台、业务架构与创新业务、业务中间件等公司级核心项目的研发,支持快车、专车、优步、优享、豪华车、拼车、出租车等出行业务。在这里,你将面对高并发、大流量、复杂业务的极限挑战;你将和顶级工程师一起打造分钟级接入新业务、新功能的技术实现方案。
滴滴服务端技术团队长期招高级后端研发工程师职位,欢迎有兴趣的小伙伴加入,可投递简历至 diditech@didiglobal.com,邮件请邮件主题请命名为「姓名-投递岗位-投递团队」。
扫码了解更多岗位