把HttpClient换成IHttpClientFactory之后,放心多了

4,778 阅读9分钟

前言

关于HttpClient的使用,个人在很多场景都派上用场了,比如在Winform或后台服务中用其调用接口获取和上传数据、微服务中用其进行各服务之间的数据共享等,到目前来看,似乎还没有出现过什么问题,但当我看到官方文档介绍使用方式时,再回顾之前项目的代码,只能说没出问题比较庆幸。

官方文档介绍的大概意思如下:

HttpClient类使用比较简单,但在某些情况下,许多开发人员却并未正确使用该类;虽然此类实现 IDisposable,但在 using 语句中声明和实例化它并非首选操作,因为释放 HttpClient 对象时,基础套接字不会立即释放,这可能会导致套接字耗尽问题,最终可能会导致 SocketException 错误。要解决此问题,推荐的方法是将 HttpClient 对象创建为单一对象或静态对象

看到这,有一点点小不安(因为有些项目就是用using的方式),虽然目前的并发量还不至于导致SocketException异常的发生,但优化得马不停蹄的安排上;先来探探HttpClient,再来说说IHttpClientFactory。

正文

1. HttpClient好像一直没用对

这里创建了一个控制台程序进行测试(.NetCore3.1),代码比较简单,如下:

image-20210612233306352

注:代码中访问的地址是用Nginx搭建在阿里云上搭建的站点,没有做负载,所以看Socket状态比较直观。

上面代码执行完成之后就退出了,理论情况来说,上面程序执行完毕之后,就不应该占用资源啦,但通过netstat查看,的确还有Socket被占用,测试如下:

  • Windows 测试

    执行如下命令看结果:

    netstat -ano | findstr TIME_WAIT
    

    image-20210612234018012

  • Linux测试

    我的云服务器之前就把.NetCore运行环境安装好了,所以创建一个目录,将编译之后的文件通过Xftp将文件传到云服务器,执行以下命令即可:

    # 注意,这里指定启动的是dll文件
    dotnet HttpClientConsoleDemo.dll
    

    image-20210613000123727

    查看端口情况,执行以下命令即可:

    netstat -ant | grep TIME_WAIT # 查看端口占用情况,找到状态为TIME_WAIT
    

    image-20210613000449843

    TIME_WAIT 是主动关闭 TCP 连接的那一方出现的状态,系统会在 TIME_WAIT 状态下等待 2MSL(maximum segment lifetime )后才能释放连接(端口),目的是为了在TCP 四次挥手关闭连接机制中,保证 ACK 重发和丢弃延迟数据。按照解释来看,这种做法也算是合情合理,保证数据传输嘛,但的确就是占用资源啦;具体关于网络的相关知识,小伙伴们再去查阅一下。

经过Windows和Linux的测试,大概差不多两分钟的时间Socket才完全被释放,可想,如果是在高并发情况下,每台机器的能开的连接数是有限的,使用这种方式进行服务和服务之间交互数据,那肯定会出现问题。

而从理论上来讲,只要HttpClient继承了IDisposable接口,using块执行完就可以释放掉资源,而HttpClient确实是间接继承了IDisposable(直接继承HttpMessageInvoker ,而HttpMessageInvoker继承了IDisposable接口)。但在这里,使用HttpClient分配的Socket端口没有得到及时释放,为避免这个问题,官方推荐用静态变量的方式使用HttpClient。

2. HttpClient换种方式好多啦

按照官方建议,将HttpClient变量定义为静态变量,代码如下:

image-20210613224709180

运行程序,执行netstat命令可以看到,资源占用情况明显减少了。

如果使用静态变量,看似解决了对应的问题,但若想针对不同的请求设置不同的头信息时就显得不太方便,至于其他问题我暂时还没遇见过(官方说这种方式不支持 DNS 变更)。先忽略其他问题,在.NetCore2.1开始出现了IHttpClientFactory ,据说是可以解决之前HttpClient面临的一些问题,所以有需要用HttpClient的场景,直接用IHttpClientFactory 就妥啦,不信就来试试。

3. IHttpClientFactory用起来很给力

IHttpClientFactory是在.NETCore 2.1 开始提供的,默认实现为 DefaultHttpClientFactory ,专门用于创建在应用程序中用到的 HttpClient实例,自动维护内部的HttpMessageHandler池及其生命周期。主要功能如下:

  • 支持命名化、类型化配置,集中管理配置,避免冲突;
  • 出站请求管道配置灵活,轻松实现对请求生命周期的管理;
  • 合理管理内部HttpMessageHanlder的生命周期,避免资源占用和DNS刷新等问题
  • 内置日志记录器

接下来就来看看IHttpClientFactory到底有多给力;

3.1 控制台演示

由于内部需要使用了一些服务,并且是采用DI的形式注入的,所以首先要把依赖注入的相关的包引入进来,代码如下图:

image-20210614211552521

先来简单看一下需要注册的服务,后续会好好说:

image-20210614212416641

运行程序,然后通过以下命令查看端口占用情况;

netstat -ano | findstr TIME_WAIT    # 根据状态去找
netstat -ano | findstr 47.113.204.41 # 根据IP去找

最终没有见到很明显的资源占用情况,有没有给力一点;还有一些比较常用的方式,在WebApi项目中一一演示(毕竟微服务中服务间通信还是比较常用的)。

3.2 WebApi项目演示
  • 创建一个API项目,注册上相关服务即可

    image-20210614234351869

  • 增加一个测试控制器和测试接口

    image-20210614234115603

  • 运行看结果

    image-20210614233646831

    在API项目中是不是使用很简单,因为项目本身就内置了依赖注入相关功能,直接注册上服务就可以使用;但这还体现不出有多给力,接下来继续看看其他扩展方式的使用。

3.3 使用命名和类型模式区分不同HttpClient

使用步骤与3.2是一样的,只是在注册服务的时候不太一样而已。

  • 命名模式

    注册服务时代码如下:

    image-20210615001230877

    增加一个测试接口,运行结果和上面一样,只是HttpClient实例带的头信息不一样啦,如下:

    image-20210615001538406

  • 类型模式

    其实类型模式原理和命名模式是一样的,只是通过指定的类型名称作为对应HttpClient的名称,减少了单独定义名称的步骤,所以显得比较方便,个人比较喜欢这样用。

    首先定义一个业务处理类,直接使用HttpClient,代码如下:

    image-20210616174807761

    在Startup中注册服务时代码如下:

    image-20210616175313251

    增加一个测试接口,运行结果和上面一样,调用过程如下:

    image-20210616175603258

    进入TypeHttpClientService对应的方法,看到在注册时设置的头信息已经生效了,如下:

    image-20210616175932756

    执行完毕后,正常返回结果。类型模式不用单独为HttpClient起名,而是直接用指定类型的类名作为默认名,这样就相对方便啦;摘取获取类型名的源码如下:

    image-20210617091835065

    小扩展:自定义的管道类没有在Startup中手动注册,为什么能直接注入使用?

    答案:在services.AddHttpClient注册时,内部已经将对应Type注册好了,摘取代码如下:

    image-20210617091437591

    除了能轻松区分不同HttpClient之外,如果需要在请求过程中加入其它公共业务处理,可以通过增加自定义管道逻辑轻松实现。

3.4 在请求管道中增加自定义管道逻辑
  • 先定义一个管道类(CustomDelegatingHandler),继承DelegatingHandler,然后重写SendAsync方法

    image-20210616231200149

  • 在Startup中注册对应的服务,根据需要在HttpClient上加上自定义管道

    image-20210616231538671

  • 运行看效果,只有用到类型模式的HttpClient才会加入自定义管道,因为在配置的时候进行了针对性的配置

    image-20210616231900098

    这种方式是不是感觉和.NetCore的中间件管道很类似,编写自定义管道其实就类似于在编写一个中间件(至于原理,后续单独扒扒源码),轻松实现在请求前和响应后做相关业务处理,就像上面加的RequestID,对分析分布式事务及微服务调用链跟踪都有很大的帮助,所以小伙伴可以根据自己的需要封装自己想要的HttpClient。

4. IHttpClientFactory 搭配Polly就完美了

只要牵涉到网络,要想服务百分百稳定那是相当难,比如常遇到的网络不通、网络波动、远端服务挂了、远端服务响应慢等问题,都可能会影响用户对系统的体验,别慌,还记得之前说过专门为故障、弹性应变设计的Polly库吗(详情请看Polly-故障处理和弹性应对很有一手),如果HttpClientFactory能和Polly搭配使用岂不美哉;

其实是我们也能结合HttpClientFactory和Polly自己封装, 不过微软已经把轮子造好了,拿来用即可,如下步骤:

4.1 引入对应版本的包

引入Microsoft.Extensions.Http.Polly包,这里使用的是.NetCore3.1,所以引入对应的版本为3.X都行。

4.2 Startup中注册服务的时候指定策略

image-20210617001659629

4.3 新增测试接口

image-20210617002008925

4.4 运行看效果

image-20210617001439859

在浏览器访问接口的时候,对比控制台打印的消息,会按照设定的时间间隔进行重试,效果很明显的。

对于IHttpClientFactory集成Polly的使用就先说到这,关于其他策略的演示,和单独使用Polly是一样的,相信小伙伴参照上面案例演示一定能搞定。对于Polly的其他策略使用,可以参考《Polly-故障处理和弹性应对很有一手》这篇文章,说的挺详细。

总结

IHttpClientFactory的应用暂时就先说到这,上面提到的功能只是平时自己常用的,其他功能小伙伴可以去探究探究;后续单独和小伙伴们一起扒扒源代码,整理整理一下流程。

如果现有项目需要用到HttpClient,建议通过IHttpClientFactory的方式,用起来方便、灵活,主要是是能避免一些问题。

博文源代码github地址:github.com/zyq025/DotN…

一个被程序搞丑的帅小伙,关注"Code综艺圈",识别关注跟我一起学~~~