五年磨一剑：滴滴顺风车服务端之稳定性规范

桔妹导读：本文给出其中稳定性相关的规范，这些规范都是顺风车成立五年来，对大量真实线上故障复盘、总结获得的，但愿对你们服务的稳定性提高有所帮助。

服务端做为顺风车技术部内最大的工程团队，随着人员的扩张和迭代，流程规范在其中扮演着原来越重要的角色。一方面规范化能够提升咱们的交付质量、交付效率，另外一方面，咱们也但愿在一次次的实战中不断的总结，探索出适用于咱们团队的最佳实践。

基于此，咱们制定并推广了一套适用于服务端开发的可执行、最小限制的工程规范，包括研发流程、稳定性、性能成本等多个方面。

本文给出其中稳定性相关的规范，这些规范都是顺风车成立五年来，对大量真实线上故障复盘、总结获得的，但愿对你们服务的稳定性提高有所帮助。

1. 名词解释

下文的描述中，会用到不少的技术名词，为更容易的理解，在这里对这些名词作下简要说明：

• 服务分级： 根据业务须要，通常的咱们须要针对最小系统划分为一级服务，一旦出问题须要第一优先级跟进。咱们将影响业务核心指标（好比发单量、成单量等）的服务定义为一级服务，其余为二级服务。
• 预览集群： 和线上生产环境的部署彻底一致的一套环境，只是无线上流量，能够内部访问，集群内流量闭环。
• 小流量集群： 和线上生产环境的部署彻底一致的一套环境，经过流量控制，只有个别城市的流量会落到此集群，集群内流量闭环。
• 灰度发布： 将发布过程分为预览集群、灰度城市集群、10%流量、50%流量、100%流量的发布机制，确保安全上线过程。
• 全链路压测： 在不影响线上服务的前提下，对生产环境进行压力测试的解决方案。用以摸清生产环境的容量、瓶颈点等。
• 机房多活： 经过多机房部署，当一个机房出现故障时，能够快速将流量切到其余机房，以减小损失。涉及流量路由、流量闭环、数据同步、数据一致性、灾难应对等诸多环节的整套解决方案。

2. 稳定性规范

稳定性设计

• 【强制】调用方必须设置超时时间，且调用链路超时从上往下递减，建议超时时间设置以下：

• 【强制】核心流程新增依赖默认为弱依赖，如需新加强依赖，须要通过评审决议；
• 【强制】下游服务如提供服务发现，全部服务必须经过服务发现访问该服务，方便服务发现控制下游节点和超时时间；
• 【强制】全部内部服务必须接入服务发现，外部服务尽可能推进接入服务发现；
• 【建议】建议框架支持依赖服务手动一键熔断；
• 【建议】服务设计优先考虑无状态设计；
• 【建议】写接口建议考虑防重入；
• 【建议】系统设计原则简单可靠，优先使用成熟技术；
• 【建议】核心服务强制，其余建议，接口建议设置合理的限流配置。

部署和运维

1. 【强制】严禁在临时脚本中未经过接口或封装方法，直接操做线上数据，若有须要，必须通过QA测试；
2. 【强制】服务上线必须经过上线平台，并接入质量平台（功能包括自动化case、核心曲线图及其余上线checklist），强制停留观察’
3. 【强制】一级服务须要包含预览集群、小流量集群（除部分特殊服务）而且双机房部署；
4. 【建议】非一级线上服务建议包含预览集群；
5. 【建议】新服务上线建议进行容量规划，建议经过接口压测或全流量压测验证模块容量。

监控告警

1. 【强制】线上服务机器必须有基础监控报警，包含CPU、IO、内存、磁盘、coredump、端口；
2. 【强制】线上服务必须有基础的服务监控，包括接口qps、fatal数量、耗时；
3. 【建议】核心业务指标(发单量、抢单量、支付量等)必须有监控和报警；
4. 【建议】须要有服务总体大盘，可以涵盖该方向核心模块监控，方便快速定位服务问题。

变动管理

1. 【强制】任何一级服务变动，均须要走灰度发布机制；
2. 【强制】任何一级服务变动，包括服务变动、配置变动，均须要有相应的回滚预案，保证变动异常时能够快速回退；
3. 【建议】尽可能避免代码搭车上线；
4. 【建议】服务回滚时建议同时回滚相应的代码和配置，保证主线代码的正确性；
5. 【建议】配置变动，特别是复杂的配置变动时，建议增长相应的配置校验机制。

预案管理

1. 【强制】必须有多活切流预案，且须要保障有效性，必须按期组织演练，建议1月1次；
2. 【强制】全链路压测通道须要保证有效性，按期组织压测；
3. 【强制】一键限流预案须要保障有效性，按期review和演练；
4. 【强制】强依赖降级预案须要保障有效性，按期演练。

故障处理原则

1. 【强制】线上出现故障时，必须第一优先级进行处理；
2. 【强制】线上出现故障时，若是有变动，第一时间回滚；
3. 【强制】线上出现故障，必须组织复盘；
4. 【强制】须要有复盘规范，复盘按照规范执行。

3. 稳定性反模式

本章节主要是基于大量的线上故障case，以具体实例驱动，加上研发全流程中各个环节容易犯的一些稳定性问题，提取一些反模式出来，供你们参考，尽可能避免后续的工做中犯一样的问题，提升线上服务的稳定性。

3.1.容灾和容错设计

反模式3.1.1
过分的节点熔断策略

【实例】
为了提升请求成功率，在下游故障时对下游节点采起熔断措施，好比1分钟内连续出现5次访问出错，则将该节点熔断，再也不调用（过一段时间后再恢复），某天网络抖动，下游服务4个实例中的3个均进入熔断模式，致使访问下游的全部流量均落到剩余的这个实例上，压力过大，将该实例压垮。下游服务雪崩，整个系统不可用。

【解决方案】
熔断模式下，还须要有熔断保护措施，避免过分熔断带来的稳定性问题。

**反模式3.1.2
固定的重试序列**

【实例】
每次重试序列都为“下一台”。

【后果】
一个是雪崩：假设某一类 query 的重试序列为A B,当 A 出现故障时,B 要承受两倍的压力,若是 B 扛不住,那么 B 的下一个也会被压垮；一个是上线损失流量：假设重试次数是2，上线时若是 A 和 B 同时重启,那么重试序列为 A B的 query 必然无结果。

【解决方案】
评估新的重试算法，好比随机重试。不过相对于固定的重试序列，随机重试序列也可能给系统带来风险，例如可能会下降下游模块的cache命中率，下降系统性能。

**反模式3.1.3
不合理的超时设置**

【实例】
上游服务超时时间设置不合理，下游出现问题时，直接把上游服务拖垮。

【解决方案】
应该根据链路的99分位耗时来设置超时时间，同时按期对链路的通讯相关配置进行review。

**反模式3.1.4
未考虑同一请求中屡次调用下游的影响**

【实例】
服务调用下游时超时时间设置没有问题，但同一请求中会串行屡次调用某个下游服务，下游服务故障时，也会把上游服务直接拖垮。

【解决方案】
除了考虑对下游服务的单次超时，还须要考虑对下游服务的整体超时。

**反模式3.1.5
不合理的重试逻辑**

【实例】
整条链路多个地方有重试，下游服务故障时，重试被放大，致使服务雪崩。

【解决方案】
评估重试机制，梳理请求处理的整个链路，保证重试收敛在一个地方。

**反模式3.1.6
没有考虑到业务毛刺的影响**

【实例】
某业务形态有个特色，在半点和整点时刻有请求尖刺，某次受节假日影响，访问下游的流量瞬间暴增，致使下游服务雪崩。

【解决方案】
对业务尖刺进行平衡处理，减小对下游服务的峰值流量冲击。

**反模式3.1.7
没有对异常输入进行容错处理**

【实例】
业务没有对异常输入进行容错处理，仍然按照正常逻辑处理，致使数据混乱。

【解决方案】
业务特别是业务入口，必须对不合理的异常输入进行容错处理，保证整个系统的健壮性。

**反模式3.1.8
接口不支持幂等性设计**

【实例】
接口不支持幂等性，网络故障时引起大量的重试，致使核心数据大量出错。

【解决方案】
接口设计的时候就须要考虑幂等性的需求。

**反模式3.1.9
没有对非核心流程弱依赖化**

【实例】
没有对流程进行弱依赖化，致使系统总体上比较脆弱，每一个依赖单元故障都会致使整个业务瘫痪。

【解决方案】
按期对系统的流程进行梳理，最小系统化，非必须流程尽可能弱依赖化。

**反模式3.1.10
没有考虑ID溢出的影响**

【实例】
某ID使用int32，超出后ID溢出，导出服务异常。

【解决方案】
增长资源相关的ID字段时要考虑ID的范围，是否有溢出风险
按期对资源相关的ID字段进行review，提早预防，最大限度防止故障的发生

3.2.部署和运维

**反模式3.2.1
部署时未考虑网段因素**

【实例】
服务部署时未考虑网段因素，服务的多个实例都部署到一个交换机下，致使交换机故障时，服务的多个实例不可用，服务所在集群雪崩

【解决方案】
服务部署时尽可能多考虑地理因素，同一服务的多个实例尽量部署到不一样的机房、交换机和网段下

**反模式3.2.2
服务混部时未作好资源隔离**

【实例】
多个服务混部，其中一个CPU占用太高，致使其余服务异常

【解决方案】
多个服务混部的状况下，必定要作好资源隔离，避免因一个服务占用资源太高，致使同一台机器上的其余服务不可用

**反模式3.2.3
没有作到对核心业务和隔离和保护**

【实例】
某非核心流程因为bug向mq写入大量消息，致使整个mq集群不可用，整个业务故障

【解决方案】
核心链路和非核心链路的mq隔离，分开部署，非核心流程的变化不会影响主流程，保证核心流程和业务的稳定性

3.3.容量管理

**反模式3.3.1
容量规划时未考虑故障因素**

【实例】
线上某服务qps不大，只部署了2个实例，一个实例高峰期出问题时，流量都落到另一个实例上面，把服务压垮

【解决方案】
容量估计时须要考虑容灾因素，预留必定的buffer
若是以为部署实例多，会浪费机器，能够考虑使用弹性云，比较灵活

**反模式3.3.2
上线新功能未合理进行容量规划**

【实例】
某服务，下游依赖众多，在进行容量规划时，重点都集中在某一依赖服务，未对全局全部依赖方进行全面评估，当其中某一依赖服务出现问题，致使总体服务不可用

【解决方案】
上线新功能时，须要对全部下游依赖服务进行容量规划，防止出现瓶颈点

3.4.变动管理

**反模式3.4.1
代码搭车上线**

【实例】
因为缺少有效的代码修改管理机制，某产品线因为代码搭车上线，出现过屡次线上故障
而且因为变动时涉及的修改比较多，致使问题定位和追查时很是困难

【解决方案】
创建严格的代码管理机制，严禁代码搭车上线，保证任什么时候刻主干没有未上线验证的代码

**反模式3.4.2
服务回滚时遗漏回滚代码**

【实例】
上线出现问题，服务回滚后没有第一时间把代码回滚掉。次日其余同窗上线时将未回滚的问题代码再次带上线，上线时致使连续两天出现系统故障

【解决方案】
服务回滚的时候同时第一时间回滚代码

**反模式3.4.3
太高的并发部署设置**

【实例】
部署配置的并发个数过高，致使同一时刻只有少数机器可用，引起集群雪崩

【解决方案】
服务部署配置的并发个数，要保证剩余机器可以承载业务所有流量

**反模式3.4.4
服务启动或回滚时间过长**

【实例】
服务上线异常，回滚时单个服务回滚时间太长，致使未能短期内快速止损

【解决方案】
按期检查服务的启动和回滚时间，保证出现故障时能够第一时间完成回滚操做

**反模式3.4.5
配置文件缺乏有效的校验机制**

【实例】
配置文件由模型产出，数据配送系统实时配送到线上服务，模型产生的配置文件有问题，引起线上故障

【解决方案】
针对配置文件，尤为是模型产出的配置文件，创建严格的检查和校验机制

**反模式3.4.6
配置变动没有灰度**

【实例】
配置相关修改，稳定性意识上重视度不够，没有进行足够的观察和灰度，致使故障

【解决方案】
全部变动，包括服务变动、配置变动、数据变动以及环境变动，都须要进行严格的观察和灰度，保证变动的质量

**反模式3.4.7
变动没有通过严格的测试**

【实例】
变动较小，感受没有必要进行测试，结果出现低级错误，致使故障

【解决方案】
任何变动都要测试、double check，修改一行代码，也可能致使线上的稳定性故障

**反模式3.4.8
变动时没有严格按照变动规范执行**

【实例】
上线时，小流量和A机房均严格按照规范检查，服务和各类曲线没有问题，上线B机房时没有进行检查。结果B机房出现故障。
经排查是由于B机房配置缺失

【解决方案】
任何变动都要严格按照变动规范严格检查，上线的每一个阶段都要检查服务的各类曲线和指标

**反模式3.4.9
离线直接经过sql更新db数据**

【实例】
直接经过sql进行离线更新数据库，没有作好限流保护，致使db压力大，线上服务访问时出现大量超时

【解决方案】
除非特殊状况，严禁直接经过sql操做db数据，修改需经过接口修改，方便经过曲线观察，也可下降直接改库的风险；

批量修改db数据须要通报dba，通过review，确认没有问题时才能够进行操做；

批量增改、增长数据务必作好限流措施。

3.5.监控报警

** 反模式3.5.1
缺乏基础监控**

【实例】
缺乏基础监控，致使出现故障，未能第一时间感知。

【解决方案】
梳理基础监控checklist，按期对服务的基础监控进行review和演练。

**反模式3.5.2
缺乏业务监控**

【实例】
缺乏业务监控，致使出现故障，未能第一时间感知。

【解决方案】
对核心流程和核心业务指标，都须要添加业务监控。

**反模式3.5.3
告警阈值设置有问题**

【实例】
因为业务bug致使线上大量告警，先临时将告警阈值从20调整到200，问题修复上线后忘了改回来，就一直维持这个阈值设置，致使后续业务出问题的时候，未能第一时间报出来。

【解决方案】
尽可能使用短暂屏蔽报警，而不是调高阈值。

**反模式3.5.4
监控告警当前已失效**

【实例】
业务迭代过快，致使监控告警信息和业务已经再也不匹配。

【解决方案】
按期对告警进行演练，保证其有效性。

重大业务迭代，须要将监控告警列入checklist。

3.6.预案管理

**反模式3.6.1
上游流量异常时没有相应的防雪崩预案**

【实例】
服务上游流量突增，致使服务瞬间被压垮，系统雪崩

【解决方案】
服务必须提早作好防雪崩预案，否则很容易致使整个系统级别的故障

**反模式3.6.2
服务没有防刷和防攻击预案**

【实例】
线上问题定位时，发现某个线上服务存在大量刷接口的现象，给线上系统的稳定性带来很大隐患，同时形成很大的资源和成本浪费。

【解决方案】
线上服务，特别是和端交互比较多的服务，设计时就须要考虑好防刷和防攻击策略，提早作好预案

**反模式3.6.3
下游故障时没有相应的处理预案**

【实例】
下游服务故障，上游服务没有相应的处理预案，致使被下游拖垮，由于这种状况致使的大型故障很是多

【解决方案】
下游故障，尤为是下游弱依赖服务故障，须要有相应的处理预案

**反模式3.6.4
故障时预案已失效**

【实例】
因为业务迭代比较快，当前对某下游已经从弱依赖变成强依赖，下游故障时，执行降级预案但业务故障并无恢复

【解决方案】
按期对预案进行演练，保证预案有效性

3.7.稳定性原则和意识

** 反模式3.7.1
对稳定性缺少敬畏之心**

【实例】
觉得服务出故障是正常的，对稳定性不觉得然

【解决方案】
技术同窗须要对代码、线上稳定性保持敬畏之心，不能有任何侥幸心理
一行代码的bug，就可能致使整个业务瘫痪掉

**反模式3.7.2
故障时没有第一时间止损**

【实例】
服务出现故障时，相关同窗第一时间在定位故障缘由，没有第一时间进行止损

【解决方案】
出现故障必须第一优先级处理，第一时间止损

**反模式3.7.3
使用未充分验证过的技术和方案**

【实例】
某服务使用了mq的广播特性，该特性在公司尚未在线上被使用过，上线后触发mq广播消费代码中的一个bug，致使mq集群不可用的故障

【解决方案】
尽可能避免使用未充分验证过的技术和方案
若是由于某些缘由必须使用，必定要有相应的兜底措施，同时控制好接入的节奏
在非关键服务上验证充分后，才能应用到核心链路上

**反模式3.7.4
使用新技术时未控制好接入节奏**

【实例】
某服务使用了mq的广播特性，在非核心服务验证时间不够的状况下，将此特性引入核心服务，核心服务的流量比较大，触发mq广播消费代码中的一个bug，致使mq集群不可用的故障

【解决方案】
引入新技术时必定要控制好接入的节奏
在非关键服务上验证充分后，才能应用到核心链路上

**反模式3.7.5
稳定性改进方案未及时落实**

【实例】
某服务出现故障，复盘时制定了相应的改进措施，可是未及时有效落实；后该问题再次爆发，又一次服务故障。

【解决方案】
创建改进措施落实的有效跟踪机制，保证改进措施的有效落实。

---

团队简介

顺风车服务端团队是由一群团结互助、乐观正直、追求极致的小伙伴汇聚而成，致力于构建一流的安全、交易、营销服务端技术体系，助力滴滴顺风车实现“分享出行让生活更美好”的使命 。

若是你想了解滴滴顺风车优质技术分享，欢迎关注「滴滴顺风车技术」公众号，阅读原文与更多技术干货。

---

欢迎关注滴滴技术公众号！

本文由博客群发一文多发等运营工具平台 OpenWrite 发布