开工第一天,这个超时问题把我干趴下了
开端
基于表面问题分析
多方位填坑
修改 http 调用方式,引入 http 连接池
第一个方案就万事大吉了吗?支持请求超时分级,线程隔离
这里还要提醒下大家 HttpClinet 使用过程中一般会配置连接池使用,切记搭配连接池使用时超时参数要配置三个,分别为 ConnectionRequestTimeout 获取连接池连接的超时时间(这个大家最容易忽略了)
ConnectTimeout 连接超时时间
SocketTimeout socket 读取超时时间
合理应用重试(消费者重试)
尽管在提供者服务上已进行代码优化,但是为了提升业务成功率,合理的使用重试也是很有必要的。此处要注意如果服务响应较慢千万避免消费者的多级重试,如果我们的整个业务调用链每一层都做了重试那么就会导致链路中响应慢的服务压力愈发增长,严重的引发重试风暴,直接压垮服务,所以合理设置重试也是很关键的一环,这里我们后续也要考虑引入熔断降级方案,避免意外发生。
问题再起
纠结求解
![图上部分为此域名解析出的香港 ip,下半部分为该域名解析出的北京 ip,同一台机器上响应时长差距明显](https://filescdn.proginn.com/2859f34d63707d746923f7fcec6a0b32/351d54e0af62813e98e1cc5bdbc42b81.webp)
![该图为腾讯云默认 dns 统计脚本的日志信息,第三个 ip 地址为香港,虽然较少出现,但是访问耗时长,且不定时会丢包](https://filescdn.proginn.com/35ed1d29edfeb92effeff7c25155d606/4c2c843b1c8d5c6d407038a08e626f31.webp)
![dns 切换后依据 kong 统计计算的 SLA 信息,会比较明显看出效果](https://filescdn.proginn.com/bda1e1bdfd622290da82882a3119c11a/43ea7f49a7b171cb8cf8a09319ac4d5a.webp)
小插曲,kong 网关的 dns 解析器是写在 kong.conf 配置文件中的,如果未配置该项则会读取系统的 /etc/resolv.conf 文件,每次 kong 启动后会读取配置并缓存到内存中,如果启动 kong 后再修改系统的 nameserver 对 kong 是不管用的!还好我们之前有在专门的机器中测试 dns 更换效果,所以才敢肯定是 kong 配置问题,但是来回也折腾了不少时间才找到问题。 在这里我也想告诉大家,和别人协作,如果可以请一定准备好对比数据,避免他人因质疑而不配合,或者合作结果并不如预期时可以有个对照。
终是踏平
有道无术,术可成;有术无道,止于术
欢迎大家关注Java之道公众号
好文章,我在看❤️
评论