高德打车稳定性建设

简介： 高德打车是高德地图首创的“聚合打车”模式，一键全网叫车，轻松全网比价，让用户打车更快、更省；推出“好的出租”计划，帮助传统巡游出租车数字化升级，帮助出租车司机增加收入。

作者 | 亮言
来源 | 阿里技术公众号

一 业务简介

高德打车是高德地图首创的“聚合打车”模式，一键全网叫车，轻松全网比价，让用户打车更快、更省；推出“好的出租”计划，帮助传统巡游出租车数字化升级，帮助出租车司机增加收入。

高德打车在运力类型上有网约车、出租车、巡改网、城际拼车等；同时订单类型又有实时单、预约单、代叫单、接送机、市内拼车等；当然在车型和价格上也有一定区分。

聚合打车在交易场景下，有众多的状态（乘客下单、司机接单、司机已到达乘车点、开始行程、行程结束、确认费用、支付成功、订单取消、订单关闭等）、多样的车型（有专车、快车、出租车等几种车型，而专车又分舒适型、豪华型、商务型等）、丰富的场景（接送机、企业用车、城际拼车、代驾等），同时对于高德聚合打车模式来说，又有多个KA接入方（每个接入方可能有不同的些许差异）。

（高德打车通用可编排订单状态机引擎设计）

1 稳定性特色

打车业务是有一些明显的业务特色的，在稳定性方面，我总结为两个方面，一个是可预知，另一个是不可抗。

什么是可预知的，比如打车有明显的节假日效应，越是节假日期间用户的出行量越大、对应的打车单量也就越高，尤其是假期的前一天、比如930（十一前一天）、1230（元旦前一天）；还有一个大家都比较熟知的早晚高峰效应，上下班的时间是出行的高峰；另外一个是重要考试&会议相关，就是一些大型集中的考试或者一些重要的会议等都会带来出行的高峰。

什么是不可抗呢，比如一家打车APP忽然故障打不了车了，那么用户就会大量涌入到其他出行app上。为什么这么说呢，因为大家的出行意愿是固定的。还有一个就是天气效应，经常会听到一个词，做打车就是『靠天吃饭』的，虽然是一句调侃的话，其实也说明了一旦出行一些恶劣天气，一些用户就会放弃公共交通、步行等方式，而选择打车。

二 稳定性问题

将线上事故或者稳定性问题不完全分个类，大概可分为：变更导致、系统依赖&架构设计问题、意识问题、DB等中间件问题。

三 解决方案

针对以上的稳定性问题，我们整理了从预防、主动发现、自愈、应急等几个方面的一些稳定性建设的解决方案和方向。

四 监控治理

详细监控治理方案可参见：高德打车构建可观测性系统实践

稳定：制定监控重保规范并推广实施，确保核心监控稳定不降级。

监控不准：自研监控日志sdk，耗时逻辑统一实现，规范数据属性：线上流量，压测，测试。统一结果码成功，业务失败，异常，推广接入应用18个。

监控降噪：制定报警规范和技巧，制定降噪方案，推广实施，核心监控准确率90%以上
快：核心秒级+分钟级覆盖，具备1分钟发现问题能力。

统一基础监控模板，应用接入X个，0成本接入新应用，解放生产力。

统一中间件监控，建立各中间件监控模板，0成本克隆即可复用，提效解放生产力。

统一业务指标，请求量(秒级，分钟级)，耗时(avg,tp99,max)，成功率(接口成功率，业务成功率)，秒级指标探查瞬时流量洪峰，耗时tp99解决毛刺问题。

实现复杂联合运算监控，sunfire功能限制，只能做到量级监控，只支持列与列之间的简单运算，研究分析，基于数据的binlog，清洗后规范化输出，利用sls的查询语法和分析语法，聚合计算出实时和准实时的转化率，业务漏斗指标，还实现了钉钉和电话报警，统一收口到故障防御平台。

实现数据&资损监控能力：主要监控能力是基于鹰眼的日志实现，应用不报错不代表服务正常，缺少数据和资损的监控。通过数据和核心日志为数据源。集成精卫，tt，adb，bcp，mac的能力，打通了从数据/日志到故障防御平台的实时，准实时，离线核对能力，提供对数据和资损的监控，并统一收口错误结果，定时钉钉提醒。

解决看不清业务全貌的问题，以交易核心全链路为试点，建立标准统一的监控大盘15+。具备1-5-10能力。

最终实现覆盖核心交易全链路的全方位多维度立体监控体系：

五 故障防御

为了解决变更引发的故障，以及为日常的一些故障定位和快速恢复提效，我们研发了故障防御平台。

故障防御平台旨在全方位即时主动发现线上问题和资损问题，通过共性能力沉淀为共享业务线提供简单快速标准的解决方案和接入模式。通过多维度指标监控、数据和资金核对、自动化巡检等手段，对变更和故障进行管控，自动化识别风险，智能化根因推荐，应急处置闭环的一体化平台。

1 变更防御

什么是变更防御？

变更防御是对线上变更进行管控，监听变更发生并对变更进行打标分类，针对不同类别的变更，通过不同维度的指标监控、数据和资金核对等手段，自动化识别风险，智能化根因推荐，并提供闭环的应急处置入口。

变更防御怎么做？

通过监听aone、diamond、mysql等变更消息，建立应用和业务的监控指标池(sunfire,sls,bcp,mac)，监控指标覆盖实时，准实时，离线，量级，转化率，漏斗等多维度。

将变更和指标池进行关联，在变更发生时，对关联指标进行指定窗口期的检查，发生报警或报警更新时，进行汇总提醒。

变更防御的效果？

线上变更X次，识别并拦截风险变更X次，有效X次，有效率62%，拦截线上问题X次，及时制止故障风险的发生。

2 故障识别

通过aone，diamond，诺曼底等取到变更信息，打标分类，再对监控指标进行分类，对不同的变更分类采用不同的监控指标进行核对。

当线上发生变更时，可以获悉准确的时间点，汇总上线开始时间段内的各种指标波动报警；通过指标异常监控和算法模型分析（同环比趋势、错误分布、排他性等）；主动判断评估，给出是否有风险的提示，生成一个防御工单，钉钉提示，进行准确的防御告警。

监控指标已经覆盖到sunfire，sls，bcp，mac等多种监控报警结果。

3 BCP实时业务校验

BCP是一个统一的业务数据实时校验分析平台，通过接收实时消息进行相关的规则校验，抓取线上脏数据并进行报警。

bcp原理就是接受一个数据源事件，对事件数据进行filter后再进行check。

打车业务的实践

根据打车业务特点，对共享交易的核心表数据和关键日志进行校验。通过精卫->metaq->bcp的方式把分渠道的订单表，子单表，账单表等多张表的binlog消息接过来，建设成一个bcpmq类型的数据源，命名“高德共享订单数据变更”，提炼出metaq消息中的msgId，topic，tag，对外暴露给filter和check，方便使用。

已封装事件：订单表，子订单表，账单表，发现打车数据类问题多类。

打通 关键Log->ttlog->bcp 的链路，应用只打日志就可以极低成本的接入bcp核对。

和线上主流程和流量隔离，不会污染和影响线上。

4 MAC数据核对

与mac数据核对平台联合开发，开放了准实时规则页面。

准实时核对是基于高并发实时分析型数据库ADB的准实时数据核对，我们的adb中实时的同步了订单表，子单表，账单表，订单状态流转日志表，基本覆盖了订单交易的核心生命周期。

离线核对是基于odps表，根据odps表时效性，最快做到核对延迟30分钟。
建立了“高德-共享出行”产品线，直接写adb和odps的sql进行核对，和线上数据和流量隔离，无风险。

5 BCS资金安全平台

BCS是自研的共享故障防御平台中的一部分、旨在核验共享各业务线的数据核对问题。
主要功能和特性

1、根据业务场景及数据源、支持实时/准实时/定时/多流/批量/的数据核对服务
2、支持准实时/秒级/分钟级/内容丰富/告警能力
3、支持Groovy、Java语法撰写核验规则表达式。
4、支持外调hsf接口数据源
5 、支持按照租户、业务线批量核验规则
6、提供异构后数据读HSF服务

BCS架构图

6 统一日志规范

痛点：日志格式五花八门，开发人员打的随心所欲，直接后果就是分析问题困难，监控不准确等。

监控日志：

格式采用 key-value + 竖线分隔符 的格式，固定采用竖线分隔符。

优点：灵活，取值准确！想要新增内容，可以在任意位置加，只要保证key唯一即可。

业务日志：

业务日志一般用于定位业务问题，日志内容上需要做如下区分：关键信息，非关键信息，附加信息。

关键信息一般为业务流程中的重要标识，如：订单ID、用户ID等，收集到日志平台后，关键信息一般会作为索引。非关键信息和附加信息不会作为索引。

错误日志：

如果某一项没有数据，会使用‘-’进行占位。

订单ID、UID、自定义错误关键字、错误信息，都为非必填项。

自定义错误关键字，建议使用简短英文，可作为查询日志的关键字使用。