把HttpClient換成IHttpClientFactory之后，放心多了

本文轉載自查看原文 2021-06-18 08:50 1124 微服務那些事/ .NetCore

前言

關於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自己封裝，不過微軟已經把輪子造好了，拿來用即可，如下步驟：