“ 天下武功 唯快不破 ”。
随着近几年好大夫在线全面转向微服务化,服务间调用复杂度急剧上升,故障难定位,技术债务难量化等相关问题随之而来,如服务稳定性没有统一衡量标准,服务容量配比是否合适等等。面对这些问题,好大夫在线基础架构部积极探索落地全链路监控系统,主要包括链路诊断、容量监控、应用运行时健康画像、实时告警及应用风险评估模型。本系列文章将从不同点切入,对好大夫在线落地全链路监控系统做一个介绍。
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。
慢接口分析模型设计原理
日志存储本地磁盘,基于Flume异步收集,推送到Kafka,日志分析系统Snow(自研)订阅Kafka消息进行流式处理,准实时分析;
每条日志携带的信息比较丰富,日志分析系统采用Goroutine,按照目前定义的规则(如慢接口、异常事件、慢SQL、循环远程调用等)进行并发分析;
分析后,生成风险指标Metrics,判断系统(Dolphin,见:好大夫在线监控系统答辩的60分钟)周期性拉取Metrics存入Prometheus,通过预设的判定规则,触发生成风险事件;
Task任务追踪系统(自研)订阅风险事件,生成可追踪的任务后,下发到各个事业部的开发人员名下(直接生成对应的JIRA任务);
测试同学管理自己部门相关的改进任务 -> 开发同学进行优化后上线 -> 测试同学线上验证后关闭;
整个流程从风险评估系统发起,到风险评估系统持续追踪验证,形成闭环;
宏观架构如下:
我们如何找到慢接口
我们将所有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,也就是说,入口方法本身还存在优化空间。
其他的风险点都可以采用类似的方法进行分析,从而制定自己的优化方案。
总结一下分析步骤
选择应用,查看任务,分析调用链;
分析链路每一个请求的时序图;
按风险进行过滤筛选;
分析耗时时间线;
找出主要可优化的点,然后去评估是否、如何去优化;
后续系列文章,我们会在以下几个方面继续探讨如何建设全链路应用风险分析系统,如:
如何按某个业务应用提炼相关的拓扑图,让相关负责人能够一目了然的看到宏观架构,理清系统边界和耦合度;
如何持续发现和制定线上系统运行态的各个维度的Metrics,让整个“风险评估系统”更加聪明的识别出来更多的风险;
如何做线上容量评估,以帮助各系统负责人提前发现系统瓶颈,更早介入优化或者扩容;
......
敬请期待!
【作者简介】
方勇:好大夫在线系统开发工程师,专注于微服务、中间件的稳定性和可用性建设,整体负责好大夫风险评估系统的设计和搭建;
翟康奇:好大夫在线系统开发工程师,专注于分布式任务调度,RabbitMQ高可用解决方案,负责全链路应用风险分析建模;
刘伟:好大夫在线系统开发工程师,主要负责统一推送平台,中间件运行时指标的监控挖掘及调优,主导RabbitMQ多集群管理平台建设。
更多好大夫技术人一手干货文章,请关注“HaoDF技术团队”微信公众号,让我们一起用“科技创造优质医疗”!
好大夫在线创立于2006年,是中国领先的互联网医疗平台之一。已收录国内10496家正规医院的69.2万名医生信息。其中,23万名医生在平台上实名注册,直接向患者提供线上医疗服务。“让行医简单,看病不难” ,始终追求“成为值得信赖的医疗平台”。