“延迟”指标如何作用于应用风险识别系统

随着近几年好大夫在线全面转向微服务化，服务间调用复杂度急剧上升，故障难定位，技术债务难量化等相关问题随之而来，如服务稳定性没有统一衡量标准，服务容量配比是否合适等等。面对这些问题，好大夫在线基础架构部积极探索落地全链路监控系统，主要包括链路诊断、容量监控、应用运行时健康画像、实时告警及应用风险评估模型。本系列文章将从不同点切入，对好大夫在线落地全链路监控系统做一个介绍。

SRE（Site Reliability Engineering）在选择指标SLI（Service Level Indicator）时，有四个黄金指标：延迟、流量、错误和饱和度（取自 Google SRE 的书籍）。

本期我们分析一下“延迟”指标如何作用于应用风险识别系统。

接口请求响应时间指示着应用单机峰值的QPS/TPS（在机器硬件配置相同的情况下）。

响应越快能并发处理的用户请求也就越多，水平扩展时收益也越大，能减少获客成本和机器成本。

请求慢有很多因素，从用户角度来看，CDN回源、css/js/html渲染、网络抖动、微服务接口粒度过细、局域网内部请求过多、机器硬件、依赖中间件等等都会影响请求的耗时，接下来我们从微服务局域网请求角度来分析。

应用出现慢接口有哪些表现和危害

• 用户的耐心是有限的，过慢的请求，会流失用户，将用户导向响应更快的竞品；
• php应用会导致php-fpm进程数被耗尽，单机处理能力大幅度下降，请求会被积压，从而导致QPS/TPS下降，从而造成大量5xx错误；
• 线程、进程阻塞，应用CPU负载因为大量的context切换而飚高，导致应用响应越来越慢，甚至出现整个系统雪崩；
• 由于大量线程/进程变慢，资源没有及时释放，导致各种连接池、中间件等连接数被耗尽，触发过载保护，造成客户端连接断开，出现错误数据或者流程中断；

什么是慢接口(高延迟)？

慢接口：直观来看就是接口慢。那接口耗时多少算慢呢？统计接口平均耗时大于某个阈值？一次响应慢就算吗？

MessageQueue消费事件算吗？定时任务里面的方法执行慢算吗？链路入口的慢接口又是如何判定的？基于这些疑问，我们根据经验总结出慢接口的具体说明。

慢接口：当服务发起方单次RPC请求响应耗时大于当前应用95%请求耗时计数累加1，一个分析周期后，当前应用累计数排名TOPK的接口标记为慢接口。

名词解释：

• 单次请求，指的是一个请求周期内的响应耗时，比如入口链路耗时时间就是处理完这次请求的总耗时，任何请求都是上游方法请求下游方法的聚合；
• 响应耗时 = 网络传输耗时 + 应用处理耗时；
• 每个应用职责不一样，所在链路位置也不一样，每个接口的耗时也不一样，如果取平均耗时，由于长尾效应，分析的数据会失真，根据公司现状分析，取95%百分位的接口响应时间记为参考值；
• 为了避免网络抖动和消除突发异常，我们采用累计数，调用量大的系统，看累加总数，调用量小的看请求占比；
• 一个分析周期，也是为了消除抖动或者突发异常，目前我们采用一个小时为分析周期；

为什么不用平均耗时

因为通常对于延迟这个指标，我们不会直接做所有请求延迟的平均，因为整个延迟的分布也符合正态分布，所以通常会以类似 “90% 请求的延迟 <= 80ms，或者 95% 请求的延迟 <=120ms ”这样的方式来设定延迟 SLO(Service Level Objective) ，熟悉数理统计的同学应该知道，这个 90% 或 95% 我们称之为置信区间。

为什么每个应用的耗时指标设置不一样

由于每个系统目前的机器分布不均衡，调用量不相同，再加上历史遗留代码，改造成本也不一样。为了让优化收益最大化，我们目前的规则是：按应用内接口横向比较，取应用的p95耗时，再根据调用频率，优先改排名前5的接口。优化是一个持续的过程，如果所有的应用都卡一个指标去优化，对那些老系统来说，短期内很难达成目标。先优化收益高的任务，有效果了，再优化新生成的任务，形成积极的正反馈。

慢接口优化的SLO

对延迟有一定了解之后，我们要怎么做呢，也就是说我们的目标是什么，延迟SLO(Service Level Objective) 优化目标，根据前面的分析，我们选择为应用接口访问量大耗时大于当前应用95%请求的接口。这样随着优化的进行，p95 在逐渐下降 等p95达标后，可以优化p99，p99.9。

慢接口分析模型设计原理

a. 日志存储本地磁盘，基于Flume异步收集，推送到Kafka，日志分析系统Snow(自研)订阅Kafka消息进行流式处理，准实时分析；

b. 每条日志携带的信息比较丰富，日志分析系统采用Goroutine，按照目前定义的规则（如慢接口、异常事件、慢SQL、循环远程调用等）进行并发分析；

c. 分析后，生成风险指标Metrics，判断系统（Dolphin，见：好大夫在线监控系统答辩的60分钟）周期性拉取Metrics存入Prometheus，通过预设的判定规则，触发生成风险事件；

d. Task任务追踪系统（自研）订阅风险事件，生成可追踪的任务后，下发到各个事业部的开发人员名下（直接生成对应的JIRA任务）；

e. 测试同学管理自己部门相关的改进任务 -> 开发同学进行优化后上线 -> 测试同学线上验证后关闭；

f. 整个流程从风险评估系统发起，到风险评估系统持续追踪验证，形成闭环；

宏观架构如下：

我们如何找到慢接口?

我们将所有RPC请求的耗时，记录到日志（从发出请求 到 接收到请求 一个来回），辅助诊断工具“APM链路分析”，标注风险点。

任务是如何分配的

现在的风险评估模型，分析出来的任务都统一分配给了服务调用方，即分给了上游服务，我们认为，应用负责人应该感知自己调用下游的健康状态，对影响接口的因素要做到心中有数，如果链路跨度比较大， 比如 SystemA::methodA()调用SystemB::methodB()而SystemB::methodB()又调用了SystemC::methodC()，如果SystemC::methodC() 耗时超过100ms。这时候SystemA，SystemB，SystemC 都会生成任务，SystemA，SystemB负载人 推动SystemC负责人 去优化SystemC::methodC()。

任务追踪系统状态流转

任务状态流转，从创建到关闭形成闭环：

任务优先级是如何划分的

每个应用面临的状态不一样，我们会优先选择收益高的慢接口生成任务，应用方再结合调用量，和修改难易程度和项目排期自己合理安排。

系统抖动产生的任务如何处理

由于网络抖动产生的临时事件，或者依赖的框架异常，中间件突发异常生成的任务，可以直接静默该任务，默认静默一个月。

如何处理(优化策略)

有些应用历史包袱比较重，调用跨度深，或者准备重构的均可以参考以下思路处理。

• 不管是重构还是要优化，先分析链路调用关系，画出时序图，看看依赖是否合理，应该能发现一些可优化项；
• 可以从产品层面思考一下，比如用户提交订单 在支付回调的过程中，给用户显示系统处理中页面，让同步请求转成异步请求，减少依赖；
• 分析慢接口的源头，基于时间线分布，查看是下游慢，还是自己当前应用处理逻辑慢；
• 判断是否依赖第三方接口，比如依赖微信，上传/下载附件等，考考是否转成异步处理；
• 是否存在循环调用，频繁的调用下游同一个方法除了徒劳浪费带宽外没啥意义；
• 是否存在多次依赖，这时候主要考虑是否存在接口粒度过细的情况，如果依赖下游方法过多可以考虑是否需要聚合，当然根据单一职责设计原则，不要盲目聚合；
• 调用跨度是否过大，RPC请求如果链路超过100次，假设每次请求耗时20ms,整条链路耗时也会超过2000ms；
• 是否可以考虑并发请求，对于跨度大的，请求返回值不相互依赖的可以考虑并发请求；
• 片段缓存被穿透，导致出现慢sql；
• 脚本或者mq消费者，大量并发操作中间件，导致中间件过载防护，或超载 阻塞连接或拒绝连接，考虑延迟消费，减少并发量，定时任务分片，分时段执行；
• get 等幂等请求，是否考虑增加片段缓存；
• 对条件查询数据库的操作，是否可以转化为查询主键；
• 高频调用中间件，是否可以调整为批量操作，如批量发布消息，和Redis交互 增加Pipline 减少网络I/O；
• 查看应用依赖是否合理，基础应用不应该依赖高层应用，应用间的交互可以基于契约，高层应用也不直接依赖基础应用，大家通过异步回调实现；
• 代码组织形式是否合理，可以基于设计模式 重构代码，对接口做基准测试 对核心接口的QPS/TPS 要做到心中有数；

优化的误区

• 为了减少并发，直接在程序中添加延迟因子，如sleep(n)。

慢接口模型会分析出这类接口，在优化和平时写代码的时候一定要注意，如果要延迟处理部分逻辑。可以考虑提交事务后触发mq异步时间，如果是缓解并发问题可以利用加锁，而不是随机增加sleep时间。

• 强制分离自己的业务领域职责，将自己的依赖的下游往上层抛，让前台代码变的臃肿无法维护，并且没有解决延迟慢的问题，只是将自己的问题抛给了上游调用方。

如controller层调用接单服务，优化后，本来SystemB::AddItemToFlow() 属于SystemA::CreateOrder()的领域逻辑，拆到Controller后，虽然SystemA健康了，但整个链路耗时依然很大，并且破坏了SystemA的领域逻辑。

• 盲目申请更大的缓存存储空间，由于数据冷热分布不均，缓存命中率低，扩大缓存后命中率没有显著提升，只会徒增机器成本。

比如按用户展示推荐文章列表，如果直接按入参设计片段缓存，由于userid不一样，会大量申请缓存，命中率没有提高，相当于每次还是直接查询数据库。

如何验证优化效果，应用变好或变坏的信号? 关注应用风险评估系统的每周周报，关注风险评级指标，关注优化后的95线趋势，以及优化后的任务是否被重新打开。

分析实战

为了方便大家持续跟进任务，我们开发任务跟进系统：“dany”，如下图：

按事业部划分应用归属，既可以查看每个事业部的风险趋势，也可以选择自己应用的任务列表，选择慢接口类型，可以借助APM链路分析，更方便的定位问题，测试也可以根据任务状态推进开发优化。接下来我们具体来分析一个：

我们选一个循环调用的方法借助APM诊断工具，分析一下：

APM 诊断工具，会给出分析报告，绘出上下游拓扑图，绘出整个调用树，绘出每个方法的时间线，给不健康的方法加上标签 我们可以看出 这条链路中，存在3处双向依赖，循环调用15组，调用跨度75，总耗时1.4s左右。为了更好的用户体验，我们对界面做了很多支持动态配置的功能，比如筛选指定的风险点。

具体到1.4 这条链路中，我们可以看到总耗时147ms。

两处循环调用1.4.1 和 1.4.2 都是调用getByHostIdAndType总耗时21ms，优化建议可以合并成一次请求。

双向依赖有三处 1.4.4 -> 1.4.4.1 -> 1.4.4.2,我们可以看出层级关系，上游发起请求后，下游又回调了上游应用，这种交叉依赖，很容易形成依赖环，从而导致交叉故障，更早的到达故障临界点。优化建议，聚合接口，上游一次性把参数传给下游，剪掉双向依赖。

从时间线外面可以判断出，下游调用时间 一共消耗85ms, 去掉下游耗时，1.4 入口耗时62ms，也就是说，入口方法本身还存在优化空间。

其他的风险点都可以采用类似的方法进行分析，从而制定自己的优化方案。

分析步骤总结

• 选择应用，查看任务，分析调用链；
• 分析链路每一个请求的时序图；
• 按风险进行过滤筛选；
• 分析耗时时间线；
• 找出主要可优化的点，然后去评估是否、如何去优化；

作者介绍：

方勇：好大夫在线系统开发工程师，专注于微服务、中间件的稳定性和可用性建设，整体负责好大夫风险评估系统的设计和搭建；

翟康奇：好大夫在线系统开发工程师，专注于分布式任务调度，RabbitMQ高可用解决方案，负责全链路应用风险分析建模；

刘伟：好大夫在线系统开发工程师，主要负责统一推送平台，中间件运行时指标的监控挖掘及调优，主导RabbitMQ多集群管理平台建设。