Время жизни клиента Flurl в ASP.Net Core 2.1 и IHttpClientFactory - PullRequest
Новая
       18

Время жизни клиента Flurl в ASP.Net Core 2.1 и IHttpClientFactory

0 голосов
/ 26 июня 2018

Flurl утверждает, что рекомендуется использовать одноэлементный клиент:

HttpClient предназначен для создания экземпляра один раз и его повторного использования в течение всего жизненного цикла приложения.Особенно в серверных приложениях создание нового экземпляра HttpClient для каждого запроса приведет к исчерпанию количества сокетов, доступных при больших нагрузках.Это приведет к ошибкам SocketException.

Но, начиная с Asp.Net Core 2.1, в Net Core 2.1 обновлены правила для времени жизни HttpClient.

Когда вы используете HttpClientFactory для запроса HttpClient, вы фактически каждый раз получаете новый экземпляр, что означает, что нам не нужно беспокоиться об изменении его состояния.Этот HttpClient может (или не может) использовать существующий HttpClientHandler из пула и, следовательно, использовать существующее открытое соединение.

Как изменить Flurl для использования IHttpClientFactory под капотом?Должен ли я создать собственный Flurl's settings.HttpClientFactory и создать HttpClient через MS IHttpClientFactory?

1 Ответ

0 голосов
/ 01 июля 2018

Во-первых, следует отметить, что новый MS HttpClientFactory предназначен для использования в сочетании с ASP.NET Core 2.1 и его встроенным контейнером DI. Если вы не вводите FlurlClient s в контроллеры или классы обслуживания и вместо этого используете Flurl следующим образом: 

await url.GetJsonAsync();

тогда это даже не актуально. Вы должны не реализовать IHttpClientFactory Flurl , чтобы использовать MS. У него нет подходящего контекста для использования контейнера DI, и вы в конечном итоге прибегнете к сервисному расположению, которое является анти-паттерном. Эти новые функции пула сокетов, которые вы хотите использовать в действительности, живут на более низком уровне: System.Net.Http.SocketsHttpHandler. Flurl по умолчанию использует HttpClientHander в качестве обработчика сообщений, но, к счастью, он был переписан в .NET Core 2.1 для переноса всей его работы на SocketsHttpHandler по умолчанию. Другими словами, если вы используете Flurl в приложении .NET Core 2.1, вы уже получаете все новые возможности управления сокетами, над которыми MS работает над .

Если вы явно используете FlurlClient в приложении ASP.NET Core 2.1 как своего рода замену HttpClient и хотели бы внедрить его в свои классы, воспользовавшись тем, что HttpClientFactory от MS предлагает, я бы предложил настроить HttpClientFactory в ConfigureServices точно так, как предписано MS, а когда вам нужен экземпляр FlurlClient, используйте конструктор, который принимает экземпляр HttpClient. Например, при использовании шаблона типизированных клиентов ваш класс обслуживания может выглядеть следующим образом: 

public class MyService
{
    private readonly IFlurlClient _flurlClient;

    public MyService(HttpClient httpClient)
    {
        _flurlClient = new FlurlClient(httpClient);
    }
}
...