把HttpClient换成IHttpClientFactory之后，放心多了-轻识

前言

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

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

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

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

正文

1. HttpClient好像一直没用对

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

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

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

Windows 测试
执行如下命令看结果：
```
netstat -ano | findstr TIME_WAIT
```
Linux测试
我的云服务器之前就把.NetCore运行环境安装好了，所以创建一个目录，将编译之后的文件通过Xftp将文件传到云服务器，执行以下命令即可：
```
# 注意，这里指定启动的是dll文件
dotnet HttpClientConsoleDemo.dll
```
查看端口情况，执行以下命令即可：
```
netstat -ant | grep TIME_WAIT # 查看端口占用情况，找到状态为TIME_WAIT
```
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变量定义为静态变量，代码如下：

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

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

3. IHttpClientFactory用起来很给力

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

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

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

3.1 控制台演示

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

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

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

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

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

3.2 WebApi项目演示

创建一个API项目，注册上相关服务即可
增加一个测试控制器和测试接口
运行看结果
在API项目中是不是使用很简单，因为项目本身就内置了依赖注入相关功能，直接注册上服务就可以使用；但这还体现不出有多给力，接下来继续看看其他扩展方式的使用。

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

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

命名模式
注册服务时代码如下：
增加一个测试接口，运行结果和上面一样，只是HttpClient实例带的头信息不一样啦，如下：
类型模式
其实类型模式原理和命名模式是一样的，只是通过指定的类型名称作为对应HttpClient的名称，减少了单独定义名称的步骤，所以显得比较方便，个人比较喜欢这样用。
首先定义一个业务处理类，直接使用HttpClient，代码如下：
在Startup中注册服务时代码如下：
增加一个测试接口，运行结果和上面一样，调用过程如下：
进入TypeHttpClientService对应的方法，看到在注册时设置的头信息已经生效了，如下：
执行完毕后，正常返回结果。类型模式不用单独为HttpClient起名，而是直接用指定类型的类名作为默认名，这样就相对方便啦；摘取获取类型名的源码如下：
小扩展：自定义的管道类没有在Startup中手动注册，为什么能直接注入使用？
答案：在services.AddHttpClient注册时，内部已经将对应Type注册好了，摘取代码如下：
除了能轻松区分不同HttpClient之外，如果需要在请求过程中加入其它公共业务处理，可以通过增加自定义管道逻辑轻松实现。

3.4 在请求管道中增加自定义管道逻辑

先定义一个管道类(CustomDelegatingHandler)，继承DelegatingHandler，然后重写SendAsync方法
在Startup中注册对应的服务，根据需要在HttpClient上加上自定义管道
运行看效果，只有用到类型模式的HttpClient才会加入自定义管道，因为在配置的时候进行了针对性的配置
这种方式是不是感觉和.NetCore的中间件管道很类似，编写自定义管道其实就类似于在编写一个中间件(至于原理，后续单独扒扒源码)，轻松实现在请求前和响应后做相关业务处理，就像上面加的RequestID，对分析分布式事务及微服务调用链跟踪都有很大的帮助，所以小伙伴可以根据自己的需要封装自己想要的HttpClient。

4. IHttpClientFactory 搭配Polly就完美了

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

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