ASP.NET Core 2.1 中的 HttpClientFactory (Part 3) 使用Handler实现传出请求中间件

原文：https://www.stevejgordon.co.uk/httpclientfactory-aspnetcore-outgoing-request-middleware-pipeline-delegatinghandlers  
发表于：2018年4月

    先前的系列文章中我介绍了一些核心概念，并且展示了ASP.NET Core 2.1中新的IHttpClientFactory的一些示例。前面两个帖子开始已经有一段时间了，我想通过讨论带有handler的“传出请求中间件”的概念来继续本系列。

DelegatingHandlers

    首先我们要知道，这部分功能中涉及的许多部件已经存在了很长时间。HttpClientFactory通过更加灵活和清晰的API简化了这些部件的使用。

    在发起HTTP请求时，您可能希望通过给定的HttpClient将所有请求实现cross cutting concerns（AOP基于切面的设计）。诸如处理重试失败的信息，记录诊断信息或者实现一个缓存层以减少HTTP的调用次数。

    对于熟悉ASP.NET Core的人，您也可能熟悉中间件概念。 DelegatingHandlers提供了几乎相同的概念，但相反，是在发出传出请求时。

    您可以将一组处理程序（Handlers）定义为管道，在发送之前，它们（Handlers）会处理传出的HTTP请求。这些处理程序可以以编程方式修改标头，检查请求的主体或者记录有关请求的一些信息。

    HttpRequestMessage在它到达最终内部处理程序（final inner handler）之前依次流经每个处理程序。这个处理程序实际上将通过网络分派HTTP请求。这个内部处理程序也将是第一个接收响应的人。此时，响应以相反的顺序通过处理程序的回切线传回。同样，每个处理程序都可以根据需要检查，修改或使用响应。例如，对于某些请求路径，您可能希望应用返回数据的缓存。

图中您可以看到可视化的管道

    与ASP.NET Core中间件非常相似，处理程序也可以使流程短路来立即返回响应。这在强制执行某些规则时比较有用。例如，您可以创建一个处理程序，检查传出请求的中是否存在API密钥头（key header）。如果缺少这个，程序将不会把请求传递给下一个处理程序（避免实际的HTTP调用），程序会生成一个失败响应返回给调用者。

    在使用IHttpClientFactory之前，您需要将处理程序实例（可以是多个）传递到HttpClient实例的构造函数中。然后，HttpClient将通过这些处理程序处理传出请求。

    我们可以为不同的“命名化客户端”或“类型化客户端”使用不同的处理程序配置。

创建处理程序（Creating a handler）

    我们先定义两个handler，为了保持代码简单，它们的功能不会特别逼真，仅为了展示关键概念。后面的例子中有一些方法可以实现类似的结果，而无需编写我们自己的处理程序。

    要创建一个处理程序，我们可以简单地创建一个继承于DelegatingHandler抽象类的类。我们可以覆盖SendAsync方法来添加我们自己的功能。

public class TimingHandler : DelegatingHandler
{
    private readonly ILogger<TimingHandler> _logger;

    public TimingHandler(ILogger<TimingHandler> logger)
    {
        _logger = logger;
    }

    protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, 
        CancellationToken cancellationToken)
    {
        var sw = Stopwatch.StartNew();

        _logger.LogInformation("Starting request");

        var response = await base.SendAsync(request, cancellationToken);

        _logger.LogInformation($"Finished request in {sw.ElapsedMilliseconds}ms");

        return response;
    }
}

    我们的例子展示的是传出请求。在发起请求前，StopWatch开始执行，接下来异步执行基类的SendAsync方法并返回一个HttpResponseMessage。

    为了让事情变得有趣，让我们创建第二个处理程序。它将检查是否存在特定的header，如果没有，则返回立即响应，通过“短路”来避免不必要的HTTP调用。

public class ValidateHeaderHandler : DelegatingHandler
{
    protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request,
        CancellationToken cancellationToken)
    {
        if (!request.Headers.Contains("X-API-KEY"))
        {
            return new HttpResponseMessage(HttpStatusCode.BadRequest)
            {
                Content = new StringContent("You must supply an API key header called X-API-KEY")
            };
        }

        return await base.SendAsync(request, cancellationToken);
    }
}

注册处理程序（Registering handlers）

    现在我们准备好了处理程序，最后一步是使用依赖注入容器注册它们并定义一个客户端。我们在Startup类中的ConfigureServices方法做这些工作。

public void ConfigureServices(IServiceCollection services)
{
    services.AddTransient<TimingHandler>();
    services.AddTransient<ValidateHeaderHandler>();

    services.AddHttpClient("github", c =>
    {
        c.BaseAddress = new Uri("https://api.github.com/");
        c.DefaultRequestHeaders.Add("Accept", "application/vnd.github.v3+json");
        c.DefaultRequestHeaders.Add("User-Agent", "HttpClientFactory-Sample");
    })
    .AddHttpMessageHandler<TimingHandler>() // This handler is on the outside and executes first on the way out and last on the way in.
    .AddHttpMessageHandler<ValidateHeaderHandler>(); // This handler is on the inside, closest to the request.
}

    前两行将处理程序分别注册到Service Collection，并且使用 transient，以便在每次创建新的HttpClient时都会提供一个新实例。

    接下来定义一个客户端。为方便演示，我们使用命名化客户端（named client）。在这个例子中，AddHttpClient方法返回一个IHttpClientBuilder。我们再调用IHttpClientBuilder的泛型扩展方法AddHttpMessageHandler，此方法将处理程序的类型作为泛型参数。

    注册顺序很重要。我们首先注册最外层的处理程序（TimingHandler）。该处理程序将第一个检查请求，并最后一个检查响应。在我们的例子中，我们希望timing handler能够记录整个请求流（request flow）的完整时间，包括任何内部处理程序所用时间，因此我们首先添加它。接着，我们再次调用AddHttpMessageHandler，注册ValidateHeaderHandler。它是内部HttpClientHandler传递请求之前最后的自定义处理程序。

    至此，我们在“github”客户端（named client）上定义了一个传出中间件管道。当发起请求时，首先经过TimingHandler，然后是ValidateHeaderHandler。如果请求中包含指定的header，则它将被允发送到请求中的URI。当响应返回时，它将首先经过ValidateHeaderHandler，然后传递给TimingHandler记录用时，最后返回调用的代码。

总结

    虽然我已经展示了创建DelegatingHandler并将其添加到HttpClient是多么容易，但在大多数情况下，团队并未意识到可以这样做。一些诸如日志记录的常见需求，已经在IHttpClientFactory中考虑到了（将在后面文章中介绍）。对于更复杂的需求，例如失败后重试，更好的选择是使用名叫Polly的第三方库。微软团队已决定与Polly实现整合。