【橙子老哥】.NetCore 管道模型源码深度解读

hello，大家好，今天又是橙子老哥的分享时间，希望大家一起学习，一起进步。

欢迎加入.net意社区，第一时间了解我们的动态，地址：ccnetcore.com

最近遇到很多小伙伴们问我，自己会.netframework想学.netcore，到底难不难，思考一下，其实基本大同小异，区别比较大的，主要是.netcore的管道模型

所以这篇文章，我们针对管道模型来玩一下，来看看它到底是个啥？

1、理论

说到管道模型，那我就不得不搬出下面这种经典图了：

.netcore的管道模型，类似一个俄罗斯套娃，从请求进来到请求出去，依次按照我们添加管道模型的顺序去执行

它的本质是属于一种特殊的 责任链 设计模式，不熟悉的人可以多去了解一下这个设计模式，真的很实用，主要是用于处理大量的if else等流程类型的业务，平替面向过程的不二之选

对于http请求，用管道模型，可谓是再合适不过了。

同时，每一个管道，又可以叫做中间件，对请求做了一个aop的操作，不就是中间件做的事情吗？很多中间件的功能都可以直接做成一个nuget包，引入到程序内部的管道模型中。微软考虑了这一点，也是用心了。

至于管道模型如何使用，网上资料很多，这里就不赘述了，本文主要以底层原理如何实现为主。

2、源码实现

入口：
在创建一个.netcore的web api程序，我们可以在program中build之后添加自己的管道

var app = builder.Build();
app.Use((context,next) =>
{
    Console.WriteLine("执行管道1");
    return next();
});
app.Use((context,next) =>
{
    Console.WriteLine("执行管道2");
    return next();
});

我们往use里面看看，我们自定义的管道模型是如何跑到进去的

	WebApplication:
	
    public IApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware)
    {
      this.ApplicationBuilder.Use(middleware);
      return (IApplicationBuilder) this;
    }

调用的WebApplication.use方法，走到this.ApplicationBuilder

如果熟悉.net5的伙伴们，肯定清楚WebApplication是后来新增的类，其实就是对ApplicationBuilder等元素包了一层，更方面我们使用，所以我们看看ApplicationBuilder内，use是做了什么

	ApplicationBuilder:

    public IApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware)
    {
        _components.Add(middleware);
        _descriptions?.Add(CreateMiddlewareDescription(middleware));

        return this;
    }

好像，没有做什么，只是把传入的Func<RequestDelegate, RequestDelegate> middleware一个委托丢到了_components，临时存储了起来而已

那我们刚好看看，存起来之后，如在哪里使用了，看到它的build方法，核心

    public RequestDelegate Build()
    {
        RequestDelegate app = context =>
        {
            // If we reach the end of the pipeline, but we have an endpoint, then something unexpected has happened.
            // This could happen if user code sets an endpoint, but they forgot to add the UseEndpoint middleware.
            var endpoint = context.GetEndpoint();
            var endpointRequestDelegate = endpoint?.RequestDelegate;
            if (endpointRequestDelegate != null)
            {
                var message =
                    $"The request reached the end of the pipeline without executing the endpoint: '{endpoint!.DisplayName}'. " +
                    $"Please register the EndpointMiddleware using '{nameof(IApplicationBuilder)}.UseEndpoints(...)' if using " +
                    $"routing.";
                throw new InvalidOperationException(message);
            }

            // Flushing the response and calling through to the next middleware in the pipeline is
            // a user error, but don't attempt to set the status code if this happens. It leads to a confusing
            // behavior where the client response looks fine, but the server side logic results in an exception.
            if (!context.Response.HasStarted)
            {
                context.Response.StatusCode = StatusCodes.Status404NotFound;
            }

            // Communicates to higher layers that the request wasn't handled by the app pipeline.
            context.Items[RequestUnhandledKey] = true;

            return Task.CompletedTask;
        };

        for (var c = _components.Count - 1; c >= 0; c--)
        {
            app = _components[c](app);
        }

        return app;
    }

这里其实就是管道模型的核心，看起来很多，其实大部分都是在做校验，我们简化一下

    public RequestDelegate Build()
    {
        RequestDelegate app = context =>return Task.CompletedTask;
        //倒叙遍历
        for (var c = _components.Count - 1; c >= 0; c--)
        {
        	//_components是我们之前新增的中间件存储的地方
            app = _components[c](app);
        }
        return app;
    }

哈哈，是不是一目了然，先创建一个初始化的节点，将我们之前传入的_components中间件委托进行一个倒叙的遍历

不过，到这里，我们的中间件并不会执行，这里很巧妙，由于我们传入的是Func<RequestDelegate, RequestDelegate> middleware，委托入参、委托出参，传入初始化的委托RequestDelegate app，返回的还是一个委托，刚好通过倒叙遍历的方式，将执行顺序调转回来

所以这个方法返回的是public RequestDelegate Build()RequestDelegate，只有在真正去执行RequestDelegate的地方才会去真正执行

这里刚好和我们的管道模型执行流程对应上了，我们给管道模型新增中间件的时候，并不会执行，而只有到有请求进来的时候，才会执行这个委托

然后呢？没了。。管道模型看起来复杂，其实真的很简单，实现起来就是一个集合一个倒叙遍历

扮猪吃老虎？并不是，我们只是站在巨人的肩膀上。
不是因为它看起内容少，所以简单；而是因为它设计的巧妙，所以看起来内容少简单

3、扩展

学以致用，管道模型不光只是在启动的时候使用，可以看到.netcore源码内，有着非常非常多的管道，每个管道的职责不一样，我们当然可以通过自己创建管道，来解决我们的业务，下面自定义管道模型使用：

1：中间件接口
首先，我们定义一个中间件接口 IMiddleware。

public interface IMiddleware
{
    Task InvokeAsync(HttpContext context, Func<HttpContext, Task> next);
}

HttpContext 类
接下来，我们定义一个简单的 HttpContext，用于存储请求上下文信息。

public class HttpContext
{
    public string Request { get; set; }
    public string Response { get; set; }
}

示例中间件
我们创建几个示例中间件来处理请求。

public class Middleware1 : IMiddleware
{
    public async Task InvokeAsync(HttpContext context, Func<HttpContext, Task> next)
    {
        Console.WriteLine("Middleware1 before");
        await next(context);
        Console.WriteLine("Middleware1 after");
    }
}

public class Middleware2 : IMiddleware
{
    public async Task InvokeAsync(HttpContext context, Func<HttpContext, Task> next)
    {
        Console.WriteLine("Middleware2 before");
        await next(context);
        Console.WriteLine("Middleware2 after");
    }
}

中间件管道
接下来，我们要创建一个管道类，负责执行中间件。

public class MiddlewarePipeline
{
    private readonly List<IMiddleware> _middlewares = new List<IMiddleware>();

    public void Use(IMiddleware middleware)
    {
        _middlewares.Add(middleware);
    }

    public async Task ExecuteAsync(HttpContext context)
    {
        Func<HttpContext, Task> next = null;

        // 构建next委托
        next = async (ctx) =>
        {
            // 如果还有中间件未执行，则继续下一个中间件
            var index = 0;
            await ExecuteMiddleware(ctx, index);
        };

        await next(context);
    }

    private async Task ExecuteMiddleware(HttpContext context, int index)
    {
        if (index < _middlewares.Count)
        {
            var middleware = _middlewares[index];
            await middleware.InvokeAsync(context, async (ctx) =>
            {
                // 调用下一个中间件
                await ExecuteMiddleware(ctx, index + 1);
            });
        }
    }
}

使用示例
最后，我们使用以上创建的管道和中间件。

class Program
{
    static async Task Main(string[] args)
    {
        var pipeline = new MiddlewarePipeline();

        pipeline.Use(new Middleware1());
        pipeline.Use(new Middleware2());

        var context = new HttpContext { Request = "Request Data" };

        await pipeline.ExecuteAsync(context);
    }
}

运行结果

Middleware1 before
Middleware2 before
Middleware2 after
Middleware1 after

学会这个，速速将屎山重构吧！