前言

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

4.1 引入對應版本的包

引入Microsoft.Extensions.Http.Polly包，這里使用的是.NetCore3.1，所以引入對應的版本為3.X都行。

4.2 Startup中注冊服務的時候指定策略

4.3 新增測試接口

4.4 運行看效果

在瀏覽器訪問接口的時候，對比控制臺打印的消息，會按照設定的時間間隔進行重試，效果很明顯的。

對于IHttpClientFactory集成Polly的使用就先說到這，關于其他策略的演示，和單獨使用Polly是一樣的，相信小伙伴參照上面案例演示一定能搞定。對于Polly的其他策略使用，可以參考《Polly-故障處理和彈性應對很有一手》這篇文章，說的挺詳細。

總結

IHttpClientFactory的應用暫時就先說到這，上面提到的功能只是平時自己常用的，其他功能小伙伴可以去探究探究；后續單獨和小伙伴們一起扒扒源代碼，整理整理一下流程。

如果現有項目需要用到HttpClient，建議通過IHttpClientFactory的方式，用起來方便、靈活，主要是是能避免一些問題。

博文源代碼github地址：https://github.com/zyq025/DotNetCoreStudyDemo

一個被程序搞丑的帥小伙，關注"Code綜藝圈"，識別關注跟我一起學~~~

總結

以上是生活随笔為你收集整理的把HttpClient换成IHttpClientFactory之后，放心多了的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。