2. 程式人生 > 其它 >ASP.NET Core 6框架揭祕例項演示[17]：利用IHttpClientFactory工廠來建立HttpClient

ASP.NET Core 6框架揭祕例項演示[17]：利用IHttpClientFactory工廠來建立HttpClient

阿新 • • 發佈：2022-03-09

在一個採用依賴注入框架的應用中，我們一般不太推薦利用手工建立的HttpClient物件來進行HTTP呼叫，使用的HttpClient物件最好利用注入的IHttpClientFactory工廠來建立。前者引起的問題，以及後者帶來的好處，將通過如下這幾個演示程式展現出來。IHttpClientFactory型別由“Microsoft.Extensions.Http”這個NuGet包提供，“Microsoft.NET.Sdk.Web”SDK具有該包的預設引用。如果採用“Microsoft.NET.Sdk”這個SDK，需要新增該包的引用。(本篇提供的例項已經彙總到《ASP.NET Core 6框架揭祕-例項演示版

》）

[S1201]頻繁建立HttpClient物件呼叫API（原始碼）
[S1202]以單例方式使用HttpClient（原始碼）
[S1203]利用IHttpClientFactory工廠建立HttpClient物件（原始碼）
[S1204]直接注入HttpClient物件（原始碼）
[S1205]定製HttpClient物件（原始碼）
[S1206]強型別客戶端（原始碼）
[S1207]基於Polly的失敗重試（原始碼）

[S1201]頻繁建立HttpClient物件呼叫API

HttpClient型別實現了IDisposable介面，如果採用在每次呼叫時建立新的物件，那麼按照我們理解的程式設計規範，呼叫結束之後就應該主動呼叫Dispose方法及時地將其釋放。如下的演示程式就採用了這種程式設計方式，我們啟動了一個ASP.NET應用，它提供了一個返回“Hello World”的終結點。

using System.Diagnostics;

var app = WebApplication.Create(args);
app.MapGet("/", () => "Hello World!");
await app.StartAsync();

while (true)
{
    using (var httpClient = new HttpClient())
    {
        try
        {
            var reply = await httpClient.GetStringAsync("http://localhost:5000");
            Debug.Assert(reply == "Hello World!
 
");
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex.Message);
        }
    }
}

ASP.NET應用啟動之後，我們在一個無限迴圈中對它發起呼叫。每次迭代的建立的HttpClient物件會在完成呼叫之後被釋放。當我們的程式執行之後，初始階段都沒有問題。當呼叫次數累積到一定規模之後，程式會大量地丟擲HttpRequestExcetion異常，並提示“Only one usage of each socket address (protocol/network address/port) is normally permitted”。


圖1　頻繁建立HttpClient導致的異常

[S1202]以單例方式使用HttpClient

這個演示例項表明頻繁建立HttpClient物件是不可取的。如果我們需要自行建立HttpClient物件並頻繁地使用它們，應該儘可能地複用這個物件。如果將演示程式改寫成如下的形式使用單例的HttpClient物件就不會丟擲上面這個異常，但是這又會帶來一些額外的問題。HttpRequestExcetion異常在前面的例項中為何會出現，後面的例項究竟又有哪些問題，我們將在後面回答這個問題。

using System.Diagnostics;
var app = WebApplication.Create(args);
app.MapGet("/", () => "Hello World!");
await app.StartAsync();

var httpClient = new HttpClient();
while (true)
{
    try
    {
        var reply = await httpClient.GetStringAsync("http://localhost:5000");
        Debug.Assert(reply == "Hello World!");
    }
    catch (Exception ex)
    {
        Console.WriteLine(ex.Message);
    }
}

[S1203]利用IHttpClientFactory工廠建立HttpClient物件

引入IHttpClientFactory工廠將會使一切變得簡單，我們只需要在需要進行HTTP呼叫的時候利用這個工廠創建出對應的HttpClient物件就可以了。雖然HttpClient型別實現了IDisposable介面，我們在完成了呼叫之後根本不需要去呼叫它的Dispose方法。在下面的演示程式中，我們呼叫ServiceCollection物件的AddHttpClient擴充套件方法對IHttpClientFactory工廠進行了註冊，並利用構建出來的IServiceProvider物件得到了這個物件。在每次進行HTTP呼叫的時候，我們利用這個IHttpClientFactory工廠實時地將HttpClient物件創建出來。

using System.Diagnostics;

var app = WebApplication.Create(args);
app.MapGet("/", () => "Hello World!");
await app.StartAsync();

var httpClientFactory = new ServiceCollection()
    .AddHttpClient()
    .BuildServiceProvider()
    .GetRequiredService<IHttpClientFactory>();

while (true)
{
    try
    {
        var reply = await httpClientFactory.CreateClient().GetStringAsync("http://localhost:5000");
        Debug.Assert(reply == "Hello World!");
    }
    catch (Exception ex)
    {
        Console.WriteLine(ex.Message);
    }
}

[S1204]直接注入HttpClient物件

上面介紹的CreateClient擴充套件方法還註冊加針對HttpClient型別的服務，所以HttpClient物件可以直接作為注入的服務來使用。在如下所示的演示程式中，我們直接利用IServiceProvider物件來創提供HttpClient物件，它與上面演示的程式是等效的（S1204）。

using System.Diagnostics;

var app = WebApplication.Create(args);
app.MapGet("/", () => "Hello World!");
await app.StartAsync();

var serviceProvider = new ServiceCollection()
    .AddHttpClient()
    .BuildServiceProvider();
while (true)
{
    try
    {
        var reply = await serviceProvider.GetRequiredService<HttpClient>().GetStringAsync("http://localhost:5000");
        Debug.Assert(reply == "Hello World!");
    }
    catch (Exception ex)
    {
        Console.WriteLine(ex.Message);
    }
}

[S1205]定製HttpClient物件

呼叫IServiceCollection介面的AddHttpClient擴充套件方法進行服務註冊的時候可以對HttpClient作相應的定製，比如可以設定超時時間、預設請求報頭和網路代理等。如果應用會涉及針對眾多不同型別API的呼叫，呼叫不同的API可能需要採用不同的設定，比如區域網內部呼叫就比外部呼叫需要更小的超時設定。為了解決這個問題，我們對提供的設定賦予一個唯一的名稱，在使用的時候針對這個標識提取對應的設定來建立HttpClient物件，為了方便描述，我們將這個唯一標識HttpClient設定的名稱就稱為HttpClient的名稱。在接下來演示的例項中，我們將設定兩個HttpClient來呼叫指向“www.foo.com”和“www.bar.com”這兩個域名的API。為此我們需要在host檔案中添加了如下的對映關係

127.0.0.1 www.foo.com
127.0.0.1 www.bar.com

在如下所示的演示例項中，我們為ASP.NET應用註冊的終結點會返回包含請求的域名和路徑。我們呼叫IServiceCollection介面的AddHttpClient方法註冊了兩個名稱分別為“foo”和“bar”的HttpClient，並對它們的基礎地址進行鍼對性的設定（S1205）。

using System.Diagnostics;

var app = WebApplication.Create(args);
app.Urls.Add("http://0.0.0.0:80");
app.MapGet("/{path}" , (HttpRequest resquest, HttpResponse response) =>response.WriteAsync($"{resquest.Host}{resquest.Path}"));
await app.StartAsync();

var services = new ServiceCollection();
services.AddHttpClient("foo", httpClient => httpClient.BaseAddress = new Uri("http://www.foo.com"));
services.AddHttpClient("bar", httpClient => httpClient.BaseAddress = new Uri("http://www.bar.com"));
var httpClientFactory = services
    .BuildServiceProvider()
    .GetRequiredService<IHttpClientFactory>();

var reply = await httpClientFactory.CreateClient("foo").GetStringAsync("abc");
Debug.Assert(reply == "www.foo.com/abc");
reply = await httpClientFactory.CreateClient("bar").GetStringAsync("xyz");
Debug.Assert(reply == "www.bar.com/xyz");

我們將HttpClient的註冊名稱作為引數呼叫IHttpClientFactory工廠的Create方法得到對應的HttpClient物件。由於基礎地址已經設定好了，所以在進行HTTP呼叫時只需要指定相對地址（“abc”和“xyz”）就可以了。

[S1206]強型別客戶端

所謂“強型別客戶端”指的針對具體場景自定義的用於呼叫指定API的型別，強型別客戶端直接使用注入的HttpClient進行HTTP呼叫。對於上一個例項的應用場景，我們就可以定義如下兩個客戶端型別FooClient和BarClient，並使用它們分別呼叫指向不同域名的API。如程式碼片段所示，我們直接在其建構函式中注入了HttpClient物件，並在GetStringAsync方法中使用它來完成最終的HTTP呼叫。

public class FooClient
{
    private readonly HttpClient _httpClient;
    public FooClient(HttpClient httpClient) => _httpClient = httpClient;
    public Task<string> GetStringAsync(string path) => _httpClient.GetStringAsync(path);
}

public class BarClient
{
    private readonly HttpClient _httpClient;
    public BarClient(HttpClient httpClient) => _httpClient = httpClient;
    public Task<string> GetStringAsync(string path) => _httpClient.GetStringAsync(path);
}

由於FooClient和BarClient對使用的HttpClient具有不同的要求，所以我們採用如下的方式呼叫IServiceCollection介面的AddHttpClient<TClient>針對客戶端型別對HttpClient進行鍼對設定，具體設定的依然是基礎地址。由於AddHttpClient<TClient>擴充套件方法會將作為泛型引數的TClient型別註冊為服務，所以我們可以直接利用IServiceProvider物件提取對應的客戶端例項（S1206）。

using App;
using System.Diagnostics;

var app = WebApplication.Create(args);
app.Urls.Add("http://0.0.0.0:80");
app.MapGet("/{path}", (HttpRequest resquest, HttpResponse response)=> response.WriteAsync($"{resquest.Host}{resquest.Path}"));
await app.StartAsync();

var services = new ServiceCollection();
services.AddHttpClient<FooClient>("foo", httpClient=> httpClient.BaseAddress = new Uri("http://www.foo.com"));
services.AddHttpClient<BarClient>("bar", httpClient=> httpClient.BaseAddress = new Uri("http://www.bar.com"));
var serviceProvider = services.BuildServiceProvider();
var foo = serviceProvider.GetRequiredService<FooClient>();
var bar = serviceProvider.GetRequiredService<BarClient>();

var reply = await foo.GetStringAsync("abc");
Debug.Assert(reply == "www.foo.com/abc");
reply = await bar.GetStringAsync("xyz");
Debug.Assert(reply == "www.bar.com/xyz");

[S1207]基於Polly的失敗重試

在任何環境下都不可能確保次HTTP呼叫都能成功，所以在失敗重試是很有必要的。失敗重試是要講究策略的，返回何種響應狀態才需要重試？重試多少次？時間間隔多長？一提到策略化自動重試，大多數人會想到Polly這個開源框架，“Microsoft.Extensions.Http.Polly”這個NuGet包提供了IHttpClientFactory工廠和Polly的整合。在添加了這個包引用之後，我們將演示程式做了如下的修改。如程式碼片段所示，我們註冊的終結點接收到的每三個請求只有一個會返回狀態碼為200的響應，其餘兩個響應碼均為500。如果客戶端能夠確保失敗後至少進行兩次重試，那麼就能保證客戶端呼叫100%成功（S1207）。

using Polly;
using Polly.Extensions.Http;
using System.Diagnostics;

var app = WebApplication.Create(args);
var counter = 0;
app.MapGet("/", (HttpResponse response) => response.StatusCode = counter++ % 3 == 0 ? 200 : 500);
await app.StartAsync();

var services = new ServiceCollection();
services
    .AddHttpClient(string.Empty)
    .AddPolicyHandler(HttpPolicyExtensions.HandleTransientHttpError().WaitAndRetryAsync(2, _ => TimeSpan.FromSeconds(1)));
var httpClientFactory = services
    .BuildServiceProvider()
    .GetRequiredService<IHttpClientFactory>();

while (true)
{
    var request = new HttpRequestMessage(HttpMethod.Get, "http://localhost:5000");
    var response = await httpClientFactory.CreateClient().SendAsync(request);
    Debug.Assert(response.IsSuccessStatusCode);
}

如上面的程式碼片段所示，呼叫AddHttpClient擴充套件方法註冊了一個預設匿名HttpClient（名稱採用空字串）之後，我們接著呼叫返回的IHttpClientBuilder物件的AddPolicyHandler擴充套件方法設定了失敗重試策略。AddPolicyHandler方法的引數型別為IAsyncPolicy<HttpResponseMessage>的引數，我們利用HttpPolicyExtensions型別的HandleTransientHttpError靜態方法建立一個用來處理偶發錯誤（比如HttpRequestException異常和5XX/408響應）的PolicyBuilder<HttpResponseMessage>物件。我們最終呼叫該物件的WaitAndRetryAsync方法返回所需的IAsyncPolicy<HttpResponseMessage>物件，並通過引數設定了重試次數（兩次）和每次重試時間間隔（1秒）。

在利用代表依賴注入容器的IServiceProvider物件得到IHttpClientFactory之後，我們在一個無限迴圈中利用它建立的HttpClient對本地承載的API發起呼叫，雖然服務端每三次呼叫只有一次是成功的，但是2次重試足以確保最終的呼叫是成功的，我們提供的除錯斷言證實了這一點。

相關推薦

ASP.NET Core 6框架揭祕例項演示[17]：利用IHttpClientFactory工廠來建立HttpClient

在一個採用依賴注入框架的應用中，我們一般不太推薦利用手工建立的HttpClient物件來進行HTTP呼叫，使用的HttpClient物件最好利用注入的IHttpClientFactory工廠來建立。前者引起的問題，以及後者帶來的好處，將通過如

ASP.NET Core 6框架揭祕例項演示[11]：診斷跟蹤的幾種基本程式設計方式

在整個軟體開發維護生命週期內，最難的不是如何將軟體系統開發出來，而是在系統上線之後及時解決遇到的問題。一個好的程式設計師能夠在系統出現問題之後馬上定位錯誤的根源並找到正確的解決方案，一個更好的程式設

ASP.NET Core 6框架揭祕例項演示[13]：日誌的基本程式設計模式[上篇]

《診斷跟蹤的幾種基本程式設計方式》介紹了四種常用的診斷日誌框架。其實除了微軟提供的這些日誌框架，還有很多第三方日誌框架可供我們選擇，比如Log4Net、NLog和Serilog 等。雖然這些框架大都採用類似的設計，但是

ASP.NET Core 6框架揭祕例項演示[14]：日誌的進階用法

為了對各種日誌框架進行整合，微軟建立了一個用來提供統一的日誌程式設計模式的日誌框架。《日誌的基本程式設計模式》以例項演示的方式介紹了日誌的基本程式設計模式，現在我們來補充幾種“進階”用法。

ASP.NET Core 6框架揭祕例項演示[18]：HttpClient處理管道

我們知道ASP.NET的核心就是由中介軟體組成的請求處理管道，HttpClient也採用了類似的設計。HttpClient管道由一組HttpMessageHandler物件構成，這些HttpMessageHandler相當於ASPNET的中介軟體。如下這些示例演示幫助我

ASP.NET Core 6框架揭祕例項演示[19]：資料加解密與雜湊

資料保護（Data Protection）框架旨在解決資料在傳輸與持久化儲存過程中的一致性（Integrity）和機密性（confidentiality）問題，前者用於檢驗接收到的資料是否經過篡改，後者通過對原始的資料進行加密以避免真實的內

ASP.NET Core 6框架揭祕例項演示[22]：如何承載你的後臺服務[補充]

藉助 .NET提供的服務承載（Hosting）系統，我們可以將一個或者多個長時間執行的後臺服務寄宿或者承載我們建立的應用中。任何需要在後臺長時間執行的操作都可以定義成標準化的服務並利用該系統來承載，ASP.NET Core應

ASP.NET Core 6框架揭祕例項演示[23]：ASP.NET Core應用承載方式的變遷

ASP.NET Core應用本質上就是一個由中介軟體構成的管道，承載系統將應用承載於一個託管程序中執行起來，其核心任務就是將這個管道構建起來。從設計模式的角度來講，“管道”是構建者（Builder）模式最典型的應用場景，

ASP.NET Core 6框架揭祕例項演示[24]：中介軟體的多種定義方式

ASP.NET Core的請求處理管道由一個伺服器和一組中介軟體組成，位於 “龍頭” 的伺服器負責請求的監聽、接收、分發和最終的響應，針對請求的處理由後續的中介軟體來完成。中介軟體最終體現為一個Func<RequestDeleg

《ASP.NET Core 6 框架揭祕》第三章讀書筆記 - 依賴注入（下）

整個 ASP.NET Core 是建立在依賴注入框架之上的。 3.1 利用容器提供服務 本章主要介紹這個獨立的基礎框架，不涉及它在 ASP.NET Core 框架中的應用。

《ASP.NET Core 6 框架揭祕》第四章讀書筆記 - 檔案系統

IFileProvider 物件構建了一個抽象的檔案系統，我們不僅可以利用該系統提供的統一 API 讀取各種型別的檔案，還能及時監控目標檔案的變化。

Asp.Net Core MVC 框架 實現釘釘掃碼登入

第一步：https://open-dev.dingtalk.com/ 登入釘釘開放後臺建立掃碼登入應用授權 第二步：登入介面前端二維碼展示：

Asp.Net Core SignalR獲取集線器例項，從集線器外部發送訊息

https://blog.csdn.net/u011127019/article/details/90812008 一、從控制器中獲取IHubContext 操作傳送訊息

在 ASP.NET Core 6.0 中使用 Serilog

本文基於Serilog.AspNetCore 4.1.0 版本。 對於之後的版本，Serilog.AspNetCore可能會有針對.NET6更新更加方便讀者呼叫，請讀者悉知

三種方法解決ASP.NET Core 6中的依賴項

依賴性注入是一種技術，它允許我們注入一個特定類的依賴物件，而不是直接建立這些例項。

【實戰】ASP.NET Core 6 部署在 ARM 樹莓派實現 DDNS 和網路喚醒

家裡有個樹莓派3B（Raspberry Pi 3B Arm 架構 32 位），放在家裡一直在吃灰，由於 .NET Core 程式能跨平臺，所以準備寫個網站部署到樹莓派上面。家裡寬頻有公網 IP 地址，但是每次重啟路由器後 IP 地址都會發生變化，

ASP.NET Core 6 Minimal API的模擬實現

Minimal API僅僅是在基於IHost/IHostBuilder的服務承載系統上作了小小的封裝而已，它利用WebApplication和WebApplicationBuilder這兩個型別提供了更加簡潔的API，同時提供了與現有API的相容。要成分理解Minimal API的

ASP.NET Core 6 的效能改進

受到 由Stephen Toub 釋出的關於 .NET 效能的部落格的啟發，我們正在寫一篇類似的文章來強調ASP.NET Core 在6.0 中所做的效能改進。

ASP.NET Core 6.0 新增 JWT 認證和授權

序言 本文將分別介紹 Authentication（認證） 和 Authorization（授權）。 並以簡單的例子在 ASP.NET Core 6.0 的 WebAPI 中分別實現這兩個功能。

ASP.NET Core 6.0 中使用 Autofac

1. 引用NuGet包 Install-Package Autofac -Version 6.3.0 Install-Package Autofac.Extensions.DependencyInjection -Version 7.2.0