一个项目要想抗住越大的压力,那么每个API都得在最短的时间内响应,这样吞吐量才高。

在很多时候,开发压根没有去做过优化,等到某天压力上来时,系统就扛不住了。

举一个最常见的例子:

大家上班都会做地铁(土豪可以开车哈)吧,地铁都有固定的几个入口,每个入口有几个固定的闸机可以扫码进入。

如果每个人扫码进站的时间都控制在2秒内,那么一个闸机一分钟可以过30个人。如果有一个人他在那磨蹭半天,花了20秒,也就是这个闸机这一分钟只能过21个人,吞吐量立马就下降了。

这种生活中的案例在程序的世界中也是同样适用的,而且是一个原理,只要有一个慢接口,就会影响整体的性能。总的来说就是队友都要很给力,不要有Pig队友。

下面看真实案例:

正在划水看美女的时候,突然收到告警,有几个接口响应时间超长,高达几十秒。慌得一批,估计哪里又出问题了。

赶紧上Cat看看详情情况,商品服务的一个RPC接口响应太慢了,而且也没啥调用量,泪奔。。。

仔细看其实并不是有很长的耗时操作,但是整体耗时却很长,肯定是请求被阻塞了。

然后去看对应机器的监控,发现CPU很高,几乎100%的状态。

看了下GC情况,也挺正常的,后面看了线程池的情况才发现原因。

上面只是表面现象,告警的时候是有几个慢接口的,排查的时候就选了第一个在看,忽略了其他的接口,以为是同一个问题。

真正慢的是另一个慢接口被Job大量调用了,服务线程都被打满了。导致其他接口很慢。

优化方案:

  • 定时任务时间调整,尽量在凌晨执行
  • 单独提供一个服务,只对Job提供服务,连从库,影响降到最小
  • 对慢接口进行性能优化

关于作者:尹吉欢,简单的技术爱好者,《Spring Cloud 微服务-全栈技术与案例解析》, 《Spring Cloud 微服务 入门 实战与进阶》作者, 公众号 猿天地 发起人。

有收获,不要吝啬你的点赞。

PS:对于Job类型的接口调用,大家会做隔离?限流?时间调整?文末留言讨论讨论吧!

版权声明:本文为yinjihuan原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/yinjihuan/p/14245802.html