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

作者 | 亮言

来源 | 阿里技术公众号

一 业务简介

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

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

聚合打车在交易场景下，有众多的状态（乘客下单、司机接单、司机已到达乘车点、开始行程、行程结束、确认费用、支付成功、订单取消、订单关闭等）、多样的车型（有专车、快车、出租车等几种车型，而专车又分舒适型、豪华型、商务型等）、丰富的场景（接送机、企业用车、城际拼车、代驾等），同时对于高德聚合打车模式来说，又有多个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、自定义错误关键字、错误信息，都为非必填项。

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

六 自愈能力建设

自愈能力主要从系统强弱依赖治理入手，对可能出现问题的场景进行构建，通过混动工程的手段训练和完善平台自愈能力、避免严重故障事件发生。

1 强弱依赖治理

强弱依赖是服务降级、预案的必要条件。只有强弱依赖梳理清楚了，才能确定哪些依赖是弱依赖可以进行降级、自动容错，或者需要进行预案评估。

什么是强弱依赖？

强依赖：当下游依赖服务异常，当前业务流程被中断，系统不再发生后续调用或业务动作无法完成，定义为强依赖。

弱依赖：当下游依赖服务异常，当前业务流程可继续，系统可继续调用并完成业务请求，定义为弱依赖。

怎么识别强弱依赖？

  1. 人工读代码、逐个接口判断链路上的强弱依赖。
  2. 使用凤凰/灭霸等工具（通过故障注入来识别）：

（1）注入异常后，故障没有被捕获，直接抛到了外层入口，则认为该依赖是一个强依赖。

（2）注入异常后，异常被捕获，后续调用链路被阻断，则认为该依赖是强依赖。

（3）注入异常后，异常被捕获，返回调用错误码，则认为该依赖是强依赖。

识别强弱依赖后，如果处理？

1.判断强弱依赖是否合理。

2.对调整后的弱依赖，做熔断限流、自动降级、预案等处理。

3.注意：需考虑降级预案对业务是否有损。

强弱依赖和预案梳理

通过对强弱依赖的梳理，以及对弱依赖增加自动容错降级、预案等，有效避免了几次线上问题。

如：乘客管控redis因服务器故障某分片oom，因此前播单接口已将乘客管控接口超时时间设置为500ms，并设置了自动降级逻辑，避免了播单服务的故障。

2 降级方案的思考

1.历史很多降级限流等都是本地代码实现

如trycatch，redis计数限流，for循环重试等等，这种代码久而久之就不知道这个系统有哪些地方有降级，什么样的实现方案。

所以我们现在逐步把代码层面的降级方案往sentinel迁移。

2.有损降级

所有有损的降级，在方案定义前就需要同产品沟通一致，具体采用什么样的方案，可能产生的损失情况，哪些可以自动降级，哪些需要手工执行预案。

同时要提前准备好对应的话术，周知到客服等。

3.其他一些细节

redis能不能降。

超时时间的设置。

3 故障注入和演练

故障注入目的：

通过对固定场景做破坏性试验，发现系统的潜在问题，及时修正，并做好限流、降级熔断等预防措施。

两个基本要求：

1.必须是真实发生的事件。

2.必须是生产环境或者等同于生产环境

高德打车实践

我们经过一年多的积累，共覆盖了运力、下单、播单、完单、支付等XX个各核心业务场景，共XX个故障场景，这些场景经过五一、十一、元旦等大促的演练验证和避免了多个真实线上事故的发生。

故障注入和混沌工程演练使用的是集团的MonkeyKing，其实现故障注入的原理可以简单总结如下：

4 演练的目标

梳理服务可能的风险点；

利用故障注入能力，对风险场景进行实验验证；

观察风险影响面、监控有效性、预案有效性、人员操作熟练程度；

进而 提升服务韧性、完善配套工具、沉淀流程规范、锻炼人员能力、提升对系统的了解程度；

七 智能运维

1 应用流量评估

  • 成本方面，基础设施成本中，服务器占绝对大头，日常靠人力驱动的成本治理难以为继
  • 效率方面，主要体现在日常应对突发流量、节假日容量准备及快上快下等，对自动化容量评估及弹性伸缩有较大需求
  • 容量评估说到底就是想搞明白每个应用的瓶颈指标是谁，以及瓶颈指标与吞吐(QPS)间的关系是怎样的。

容量模型系统是如何适配新接入的业务的模型类型呢？又是如何进行容量模型训练的？

2 弹性扩缩容

节假日服务保障的主要工作集中在节前的准备阶段，高德打车场景涉及到的核心应用有几十个，每个应用的流量预估和扩容是其中的重中之重，预估的过高会导致资源浪费，预估过低则有稳定性风险。

以高德打车为例，可能影响流量高低的因素有很多，如：

  • 用户侧因素：用户自然增长、节假日出行需求