共计 5919 个字符，预计需要花费 15 分钟才能阅读完成。
简介：高德打车是高德地图独创的“聚合打车”模式，一键全网叫车，轻松全网比价，让用户打车更快、更省；推出“好的出租”打算，帮忙传统巡游出租车数字化降级，帮忙出租车司机增加收入。
作者 | 亮言
起源 | 阿里技术公众号
一 业务简介
高德打车是高德地图独创的“聚合打车”模式，一键全网叫车，轻松全网比价，让用户打车更快、更省；推出“好的出租”打算，帮忙传统巡游出租车数字化降级，帮忙出租车司机增加收入。
高德打车在运力类型上有网约车、出租车、巡改网、城际拼车等；同时订单类型又有实时单、预约单、代叫单、接送机、市内拼车等；当然在车型和价格上也有肯定辨别。
聚合打车在交易场景下，有泛滥的状态（乘客下单、司机接单、司机已达到乘车点、开始行程、行程完结、确认费用、领取胜利、订单勾销、订单敞开等）、多样的车型（有专车、慢车、出租车等几种车型，而专车又分舒适型、豪华型、商务型等）、丰盛的场景（接送机、企业用车、城际拼车、代驾等），同时对于高德聚合打车模式来说，又有多个 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）注入异样后，异样被捕捉，后续调用链路被阻断，则认为该依赖是强依赖。
（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 弹性扩缩容
节假日服务保障的次要工作集中在节前的筹备阶段，高德打车场景波及到的外围利用有几十个，每个利用的流量预估和扩容是其中的重中之重，预估的过高会导致资源节约，预估过低则有稳定性危险。
以高德打车为例，可能影响流量高下的因素有很多，如：
- 用户侧因素：用户天然增长、节假日出行需要强度（受节日长度、节日类型等影响）
- 运力因素：即便在用户肯定的前提下，运力短缺水平不同也会导致局部业务模块的流量高下不同
- 其它因素：天气因素、经营流动（红包、免佣等）、行程间隔长短等
最终的流量预估须要综合参考这些因素做考量。
3 精细化容灾
精细化容灾提供 HSF、MetaQ、Vipserver 疾速且优雅高低线能力，防止某台或几台服务器故障呈现问题无奈疾速摘流，或者防止上线一批后服务异样无奈疾速回滚，而导致的线上故障。目前提供 V1.0 版本，更易用的性能打磨中。
八 全链路压测
1 同 SP 联结压测，虚构运力仿真平台
高德打车作为聚合打车，全链路压测需联结上游 SP 一起进行压测验收。
为解决对运营商的强依赖问题，咱们测试团队搭建了一套虚构运力服务，可进行司机接单，司机达到目的地，行程开始，行程完结，收取费用等一系列司机端状态回调，解决了司机行为不可控的问题。
并且搭建了可视化仿真平台，可实现司机接单、司机达到、行程开始、行程完结等性能。同时也进步了日常回归测试主流程的效率。
2 影子链路革新细节
1. 共享目前张北两个机房（A、B），压测时切一个机房（A）用来压测。
2. 标准乘客 ID、司机 ID、订单 ID 的压测标识：
(1)乘客 ID 和司机 ID>XXXX
(2)订单 ID 以 ”X” 结尾。
3. 入库前由 mybatis 插件辨认 ”X” 结尾，
对立设置 EagleEyg.putUserData(“t”,1)，
避免标失落。
4.Metaq 应用不同的 topic（test_结尾）辨别生产环境音讯与压测音讯，通过 topic 进行隔离。
5. 影子表与影子库的抉择？
(1)压测对生产 DB 实例影响
(2) 老本问题
九 大促保障实战
高德十一出行节、双旦、五一等是高德共享出行的重要节日、单量峰值是平时的 N 倍，对系统和稳定性有极高的挑战。
大促保障次要从危险评估、压测预案、容量评估、巡检值班、作战应急等几个方面来介绍整体保障计划。
十 总结
高德打车业务通过一直的稳定性保障计划演讲，造成了一套残缺的流程、机制和方法论，实现了全链路压测能力、变更防御能力建设，具备初步的故障预防、被动发现、零碎自愈能力，保障了屡次大促无故障、无资损，用户打车体验丝般顺滑。
原文链接
本文为阿里云原创内容，未经容许不得转载。
