今天，我們深度研究一下IHttpClientFactory。
一、前言
最早，我們是在Dotnet Framework中接觸到HttpClient。
HttpClient給我們提供了與HTTP互動的基本方式。但這個HttpClient在大量頻繁使用時，也會給我們丟擲兩個大坑：一方面，如果我們頻繁建立和釋放HttpClient例項，會導致Socket套接字資源耗盡，原因是因為Socket關閉後的TIME_WAIT時間。這個問題不展開說，如果需要可以去查TCP的生命週期。而另一方面，如果我們建立一個HttpClient單例，那當被訪問的HTTP的DNS記錄發生改變時，會丟擲異常，因為HttpClient並不會允許這種改變。
現在，對於這個內容，有了更優的解決方案。
從Dotnet Core 2.1開始，框架提供了一個新的內容：IHttpClientFactory。
IHttpClientFactory用來建立HTTP互動的HttpClient例項。它通過將HttpClient的管理和用於傳送內容的HttpMessageHandler鏈分離出來，來解決上面提到的兩個問題。這裡面，重要的是管理管道終端HttpClientHandler的生命週期，而這個就是實際連線的處理程式。
除此之外，IHttpClientFactory還可以使用IHttpClientBuilder方便地來定製HttpClient和內容處理管道，通過前置配置建立出的HttpClient，實現諸如設定基地址或新增HTTP頭等操作。
為防止非授權轉發，這兒給出本文的原文連結：https://www.cnblogs.com/tiger-wang/p/13752297.html
先來看一個簡單的例子：
public void ConfigureServices(IServiceCollection services)
{
services.AddHttpClient("WangPlus", c =>
{
c.BaseAddress = new Uri("https://github.com/humornif");
})
.ConfigureHttpClient(c =>
{
c.DefaultRequestHeaders.Add("Accept", "application/vnd.github.v3+json");
c.DefaultRequestHeaders.Add("User-Agent", "HttpClientFactory-Sample");
});
}
在這個例子中，當呼叫ConfigureHttpClient()或AddHttpMessageHandler()來配置HttpClient時，實際上是在向IOptions的例項HttpClientFactoryOptions新增配置。這個方法提供了非常多的配置選項，具體可以去看微軟的文件，這兒不多說。
在類中使用IHttpClientFactory時，也是同樣的方式：建立一個IHttpClientFactory的單例例項，然後呼叫CreateClient(name)建立一個具有名稱WangPlus的HttpClient。
看下面的例子：
public class MyService
{
private readonly IHttpClientFactory _factory;
public MyService(IHttpClientFactory factory)
{
_factory = factory;
}
public async Task DoSomething()
{
HttpClient client = _factory.CreateClient("WangPlus");
}
}
用法很簡單。
下面，我們會針對CreateClient()進行剖析，來深入理解IHttpClientFactory背後的內容。
二、HttpClient & HttpMessageHandler的建立過程
CreateClient()方法是與IHttpClientFactory互動的主要方法。
看一下CreateClient()的程式碼實現：
private readonly IOptionsMonitor<HttpClientFactoryOptions> _optionsMonitor
public HttpClient CreateClient(string name)
{
HttpMessageHandler handler = CreateHandler(name);
var client = new HttpClient(handler, disposeHandler: false);
HttpClientFactoryOptions options = _optionsMonitor.Get(name);
for (int i = 0; i < options.HttpClientActions.Count; i++)
{
options.HttpClientActions[i](client);
}
return client;
}
程式碼看上去很簡單。首先通過CreateHandler()建立了一個HttpMessageHandler的處理管道，並傳入要建立的HttpClient的名稱。
有了這個處理管道，就可以建立HttpClient並傳遞給處理管道。這兒需要注意的是disposeHandler:false，這個引數用來保證當我們釋放HttpClient的時候，處理管理不會被釋放掉，因為IHttpClientFactory會自己完成這個管道的處理。
然後，從IOptionsMonitor的例項中獲取已命名的客戶機的HttpClientFactoryOptions。它來自Startup.ConfigureServices()中新增的HttpClient配置函式，並設定了BaseAddress和Header等內容。
最後，將HttpClient返回給呼叫者。
理解了這個內容，下面我們來看看CreateHandler(name)方法，研究一下HttpMessageHandler管道是如何建立的。
readonly ConcurrentDictionary<string, Lazy<ActiveHandlerTrackingEntry>> _activeHandlers;;
readonly Func<string, Lazy<ActiveHandlerTrackingEntry>> _entryFactory = (name) =>
{
return new Lazy<ActiveHandlerTrackingEntry>(() =>
{
return CreateHandlerEntry(name);
}, LazyThreadSafetyMode.ExecutionAndPublication);
};
public HttpMessageHandler CreateHandler(string name)
{
ActiveHandlerTrackingEntry entry = _activeHandlers.GetOrAdd(name, _entryFactory).Value;
entry.StartExpiryTimer(_expiryCallback);
return entry.Handler;
}
看這段程式碼：CreateHandler()做了兩件事：
- 建立或獲取
ActiveHandlerTrackingEntry； - 開始一個計時器。
_activeHandlers是一個ConcurrentDictionary<>，裡面儲存的是HttpClient的名稱（例如上面程式碼中的WangPlus）。這裡使用Lazy<>是一個使GetOrAdd()方法保持執行緒安全的技巧。實際建立處理管道的工作在CreateHandlerEntry中，它建立了一個ActiveHandlerTrackingEntry。
ActiveHandlerTrackingEntry是一個不可變的物件，包含HttpMessageHandler和IServiceScope注入。此外，它還包含一個與StartExpiryTimer()一起使用的內部計時器，用於在計時器過期時呼叫回撥函式。
看一下ActiveHandlerTrackingEntry的定義：
internal class ActiveHandlerTrackingEntry
{
public LifetimeTrackingHttpMessageHandler Handler { get; private set; }
public TimeSpan Lifetime { get; }
public string Name { get; }
public IServiceScope Scope { get; }
public void StartExpiryTimer(TimerCallback callback)
{
// Starts the internal timer
// Executes the callback after Lifetime has expired.
// If the timer has already started, is noop
}
}
因此CreateHandler方法要麼建立一個新的ActiveHandlerTrackingEntry，要麼從字典中檢索條目，然後啟動計時器。
下一節，我們來看看CreateHandlerEntry()方法如何建立ActiveHandlerTrackingEntry例項。
三、在CreateHandlerEntry中建立和跟蹤HttpMessageHandler
CreateHandlerEntry方法是建立HttpClient處理管道的地方。
這個部分程式碼有點複雜，我們簡化一下，以研究過程為主：
private readonly IServiceProvider _services;
private readonly IHttpMessageHandlerBuilderFilter[] _filters;
private ActiveHandlerTrackingEntry CreateHandlerEntry(string name)
{
IServiceScope scope = _services.CreateScope();
IServiceProvider services = scope.ServiceProvider;
HttpClientFactoryOptions options = _optionsMonitor.Get(name);
HttpMessageHandlerBuilder builder = services.GetRequiredService<HttpMessageHandlerBuilder>();
builder.Name = name;
Action<HttpMessageHandlerBuilder> configure = Configure;
for (int i = _filters.Length - 1; i >= 0; i--)
{
configure = _filters[i].Configure(configure);
}
configure(builder);
var handler = new LifetimeTrackingHttpMessageHandler(builder.Build());
return new ActiveHandlerTrackingEntry(name, handler, scope, options.HandlerLifetime);
void Configure(HttpMessageHandlerBuilder b)
{
for (int i = 0; i < options.HttpMessageHandlerBuilderActions.Count; i++)
{
options.HttpMessageHandlerBuilderActions[i](b);
}
}
}
先用根DI容器建立一個IServiceScope，從關聯的IServiceProvider中獲取關聯的服務，再從HttpClientFactoryOptions中找到對應名稱的HttpClient和它的配置。
從容器中查詢的下一項是HttpMessageHandlerBuilder，預設值是DefaultHttpMessageHandlerBuilder，這個值通過建立一個主處理程式（負責建立Socket套接字和傳送請求的HttpClientHandler）來構建處理管道。我們可以通過新增附加的委託來包裝這個主處理程式，來為請求和響應建立自定義管理。
附加的委託DelegatingHandlers類似於Core的中介軟體管道：
Configure()根據Startup.ConfigureServices()提供的配置構建DelegatingHandlers管道；IHttpMessageHandlerBuilderFilter是注入到IHttpClientFactory建構函式中的過濾器，用於在委託處理管道中新增額外的處理程式。
IHttpMessageHandlerBuilderFilter類似於IStartupFilters，預設註冊的是LoggingHttpMessageHandlerBuilderFilter。這個過濾器向委託管道新增了兩個額外的處理程式：
- 管道開始位置的
LoggingScopeHttpMessageHandler，會啟動一個新的日誌Scope； - 管道末端的
LoggingHttpMessageHandler，在請求被髮送到主HttpClientHandler之前，記錄有關請求和響應的日誌；
最後，整個管道被包裝在一個LifetimeTrackingHttpMessageHandler中。管道處理完成後，將與用於建立它的IServiceScope一起儲存在一個新的ActiveHandlerTrackingEntry例項中，並給定HttpClientFactoryOptions中定義的生存期(預設為兩分鐘)。
該條目返回給呼叫者（CreateHandler()方法），新增到處理程式的ConcurrentDictionary<>中，新增到新的HttpClient例項中（在CreateClient()方法中），並返回給原始呼叫者。
在接下來的生存期（兩分鐘）內，每當您呼叫CreateClient()時，您將獲得一個新的HttpClient例項，但是它具有與最初建立時相同的處理程式管道。
每個命名或型別化的HttpClient都有自己的訊息處理程式管道。例如，名稱為WangPlus的兩個HttpClient例項將擁有相同的處理程式鏈，但名為api的HttpClient將擁有不同的處理程式鏈。
下一節，我們研究下計時器過期後的清理處理。
三、過期清理
以預設時間來說，兩分鐘後，儲存在ActiveHandlerTrackingEntry中的計時器將過期，並觸發StartExpiryTimer()的回撥方法ExpiryTimer_Tick()。
ExpiryTimer_Tick負責從ConcurrentDictionary<>池中刪除處理程式記錄，並將其新增到過期處理程式佇列中：
readonly ConcurrentQueue<ExpiredHandlerTrackingEntry> _expiredHandlers;
internal void ExpiryTimer_Tick(object state)
{
var active = (ActiveHandlerTrackingEntry)state;
_activeHandlers.TryRemove(active.Name, out Lazy<ActiveHandlerTrackingEntry> found);
var expired = new ExpiredHandlerTrackingEntry(active);
_expiredHandlers.Enqueue(expired);
StartCleanupTimer();
}
當一個處理程式從_activeHandlers集合中刪除後，當呼叫CreateClient()時，它將不再與新的HttpClient一起分發，但會保持在記憶體存，直到引用此處理程式的所有HttpClient例項全部被清除後，IHttpClientFactory才會最終釋放這個處理程式管道。
IHttpClientFactory使用LifetimeTrackingHttpMessageHandler和ExpiredHandlerTrackingEntry來跟蹤處理程式是否不再被引用。
看下面的程式碼：
internal class ExpiredHandlerTrackingEntry
{
private readonly WeakReference _livenessTracker;
public ExpiredHandlerTrackingEntry(ActiveHandlerTrackingEntry other)
{
Name = other.Name;
Scope = other.Scope;
_livenessTracker = new WeakReference(other.Handler);
InnerHandler = other.Handler.InnerHandler;
}
public bool CanDispose => !_livenessTracker.IsAlive;
public HttpMessageHandler InnerHandler { get; }
public string Name { get; }
public IServiceScope Scope { get; }
}
根據這段程式碼，ExpiredHandlerTrackingEntry建立了對LifetimeTrackingHttpMessageHandler的弱引用。根據上一節所寫的，LifetimeTrackingHttpMessageHandler是管道中的“最外層”處理程式，因此它是HttpClient直接引用的處理程式。
對LifetimeTrackingHttpMessageHandler使用WeakReference意味著對管道中最外層處理程式的直接引用只有在HttpClient中。一旦垃圾收集器收集了所有這些HttpClient，LifetimeTrackingHttpMessageHandler將沒有引用，因此也將被釋放。ExpiredHandlerTrackingEntry可以通過WeakReference.IsAlive檢測到。
在將一個記錄新增到_expiredHandlers佇列之後，StartCleanupTimer()將啟動一個計時器，該計時器將在10秒後觸發。觸發後呼叫CleanupTimer_Tick()方法，檢查是否對處理程式的所有引用都已過期。如果是，處理程式和IServiceScope將被釋放。如果沒有，它們被新增回佇列，清理計時器再次啟動：
internal void CleanupTimer_Tick()
{
StopCleanupTimer();
int initialCount = _expiredHandlers.Count;
for (int i = 0; i < initialCount; i++)
{
_expiredHandlers.TryDequeue(out ExpiredHandlerTrackingEntry entry);
if (entry.CanDispose)
{
try
{
entry.InnerHandler.Dispose();
entry.Scope?.Dispose();
}
catch (Exception ex)
{
}
}
else
{
_expiredHandlers.Enqueue(entry);
}
}
if (_expiredHandlers.Count > 0)
{
StartCleanupTimer();
}
}
為了看清程式碼的流程，這個程式碼我簡單了。原始的程式碼中還有日誌記錄和執行緒鎖相關的內容。
這個方法比較簡單：遍歷ExpiredHandlerTrackingEntry記錄，並檢查是否刪除了對LifetimeTrackingHttpMessageHandler處理程式的所有引用。如果有，處理程式和IServiceScope就會被釋放。
如果仍然有對任何LifetimeTrackingHttpMessageHandler處理程式的活動引用，則將條目放回佇列，並再次啟動清理計時器。
四、總結
如果你看到了這兒，那說明你還是很有耐心的。
這篇文章是一個對原始碼的研究，能夠幫我們理解IHttpClientFactory的執行方式，以及它是以什麼樣的方式填補了舊的HttpClient的坑。
有些時候，看看原始碼，還是很有益處的。
 |
微信公眾號：老王Plus 掃描二維碼，關注個人公眾號，可以第一時間得到最新的個人文章和內容推送 本文版權歸作者所有，轉載請保留此宣告和原文連結 |