继上一集里说到遇到的各种问题并且弄了 n 个解决方案之后, 特别是对于问题 4 的解决方案对于切换了 HttpClientFactory
我用了你家 netcore 2.1 下专门解决之前 HttpClient 口病已久的灵丹妙药了, 信心满满的上线..... 然后挂了, 该超时的继续超
其中这个问题比较诡异在于超时的主要集中在两台机器上(俗称两兄弟了)
由于不明真相到底是什么导致的, 而且接下来又要到五一了, 为了欢度五一这么一个伟大艰巨的任务, 为了证明迁移 core 的伟大光荣正确, 怎么也要解决掉这个问题
步骤一, 先确认问题的复现
首先直接放弃在任何测试环境复现的想法, 因为之前在测试 HttpClientFactory 的时候已经在测试环境里进行过多批次各种场景的压测, 无论是长时低压, 长时高压, 短时高压都进行过都没发生过
而且就算是线上也就 2 台机器有问题
所以让运维提供 ip, 指向到这台服务器后, 使用 superbenchmarker 对其进行压测
压测中发现这个.... 很稳定
稳定 5 分钟, 挂个 2 分钟
绿色线为 RPS 每秒请求数, 紫色是请求响应时间, 发现绿色线稳定 5 分钟后, 会突然没有了 (请求卡住了), 等个 2 分钟后突然紫色线突然冒个刺(等待已久的请求终于响应了) 然后绿色线又起来了(请求恢复正常)
步骤二, 确认超时的时候发生了什么
第二天, 开好压测, 因为确认了每 5 分钟后会超时 2 分钟这个时间, 等着个四分钟左右跑到运维那坐着, 看下超时期间到底发生了什么.
然后我就绝望了.
常规的比如 CPU / 内存之类一切正常, 考虑到 HttpClient 有过的历史缺陷比如 .NET HttpClient 的缺陷和文档错误让开发人员倍感沮丧 https://www.infoq.cn/article/2016/09/HttpClient 也特意关注过端口号之类的, 也一切正常.
步骤三, 迁移前的 Framework 怎么没有问题, 是 Core 的锅吗
为了证明这个事情, 准备了 2 个 console
一个 Framework 下使用静态的 HttpClient 每 100ms 调用某外部接口
一个 Core 下使用 HttpClientFactory 也是每 100ms 调用某外部接口
这个结果让我绝望的平方
结果显示 Framework 下一切正常, 只有 Core 有问题
后续在补充了几个不同姿势的 Core 版本的 console 来测试
包括
1. 将 SetHandlerLifetime 设置为 InfiniteTimeSpan
2. 不用 HttpClientFactory 直接 new 一个静态 HttpClient(和 Framework 一摸一样的姿势)
依然都会又超时的问题
由于网上 google 翻了个遍没找到类似的说法
此时的内心想法: 难道我要开历史的倒车了么(难道只有我有问题么? 还是说我哪里姿势有问题? 别人怎么都好好的? 难道别人都是假的? 网上吹的那么厉害全都是瞎 BB?.... 各种草泥马奔腾而过)
柳暗花明, 绝望的时候找下组织吧
然后就在某微信群里发出求救信号
最后得到一个看起来有点靠谱的方案
(截图里的内容,)
文字版描述: 创建 HttpClient 的时候设置 UseProxy 为 false, 此值默认值是 true
然后使用这个改造后在打包一个 console 进行测试, 这次结果终于看到了希望的曙光了
由于根据之前的规律每 5 分钟之后会挂 2 分钟, 能活个 10 分钟基本证明修改有效
跟着这个将站点都修改了 UseProxy=false 打包上去, 进行压测
跑了好几个小时, 目前为止并没有发生再超时的问题了, 现在基本实锤问题解决了
最后总结
无论你是 new 一个静态 HttpClient 还是通过 HttpClientFactory 去创建 HttpClient, 记得要将 UseProxy=false(当然, 除非你要用 proxy 那就没辙)
当然, 最后有几个疑点我也不是太清楚
比如
为什么线上就 2 台机器恒定有问题?
而其他机器则比较稳定(实际线上服务器接近 30 台)?
为什么是稳 5 分钟后超时 2 分钟(这个 5 和这个 2 是哪里设置的)?
UseProxy 在这里又是起到了什么样的作用?
群里小伙伴给了这么一个解释
然而我依然不是太理解 T-T
.Net 世界真是博大精深...
来源: https://www.cnblogs.com/leolaw/p/10776451.html