.NET Core API使用IHttpClientFactory时用户并发上升出现性能问题如何排查

问题1：X-Ray结果是否说明第三方接口耗时30秒 #

你代码中统计的Stage 1耗时覆盖了从调用SendAsync到拿到响应的全流程，这个耗时并不完全等同于第三方接口的实际处理时间，还包含了本地HTTP请求排队、TCP连接建立、网络传输的时间。如果第三方确认他们侧的响应耗时在毫秒级，大概率是请求在你本地的HTTP连接池排队导致的等待时间过长，暂时不需要优先联系第三方，先排查本地HttpClient配置问题。如果调整完本地配置后耗时仍然异常，再拿对应时间区间的请求信息找第三方核对他们侧的请求接收、处理日志即可。

问题2：HttpClient注册方式是否存在问题 #

你的注册方式确实存在导致并发受限的隐患：

• 默认情况下，IHttpClientFactory创建的HttpClient对应的处理器，对同一目标域名的最大并发连接数（MaxConnectionsPerServer）如果没有显式配置，部分场景下默认值仅为2，当并发请求量上升后，大量请求会阻塞等待可用的HTTP连接，直接表现就是SendAsync总耗时极高，但第三方实际收到请求后处理很快，和你遇到的现象完全吻合。
• 你当前的写法每次实例化瞬态的IMyAuthenticationProvider都会新建一个HttpClient实例，虽然IHttpClientFactory会复用底层的处理器池，但没有配置连接数上限的问题依然存在。

修复建议如下：
修改Startup中的配置，显式给命名客户端设置合理的最大连接数：

// 先配置命名客户端的参数
services.AddHttpClient("3RDPARTYAUTHCLIENT")
    .SetHandlerLifetime(TimeSpan.FromMinutes(5)) // 可根据需求调整处理器生命周期
    .ConfigurePrimaryHttpMessageHandler(() => 
    {
        return new SocketsHttpHandler
        {
            MaxConnectionsPerServer = 100, // 可根据你的并发量级调整，通常50-200即可覆盖绝大多数场景
            PooledConnectionLifetime = TimeSpan.FromMinutes(2)
        };
    });

// 简化服务注册，不用自己写工厂方法创建实例
services.AddTransient<IMyAuthenticationProvider, MyAuthenticationProvider>();

调整后MyAuthenticationProvider的构造函数直接接收IHttpClientFactory和IMetricCollector即可，由框架自动注入参数。

问题3：Redis缓存方案是否可行 #

方案完全可行，是非常典型的降本提优思路：
只要相同请求的返回结果在一定时间内是固定的，就可以将认证结果以请求特征（比如用户唯一标识+认证类型）作为Key存入Redis，设置符合业务安全要求的过期时间（比如15分钟到1小时），可以大幅减少对第三方API的调用量，从根源上降低并发冲突的概率。
需要注意两点：一是认证结果属于敏感数据，存入Redis时建议做加密处理，避免数据泄露；二是要做好缓存击穿的兜底逻辑，缓存失效时依然可以正常调用第三方接口获取结果。

内容的提问来源于stack exchange，提问作者Ctrl_Alt_Defeat