ASP.NET Core 中的管道机制

àì夳堔傛蜴生んèń 2023-08-17 15:35 150阅读 0赞

![749711-20190718105721853-511996160.png][]

> 首先，很感谢在上篇文章 [C\# 管道式编程][C_] 中给我有小额捐助和点赞的朋友们，感谢你们的支持与肯定。希望我的每一次分享都能让彼此获得一些收获，当然如果我有些地方叙述的不正确或不当，还请不客气的指出。好了，下面进入正文。

## 前言 ##

在开始之前，我们需要明确的一个概念是，在 Web 程序中，用户的每次请求流程都是线性的，放在 ASP.NET Core 程序中，都会对应一个 **请求管道（request pipeline）**，在这个请求管道中，我们可以动态配置各种业务逻辑对应的 **中间件（middleware）**，从而达到服务端可以针对不同用户做出不同的请求响应。在 ASP.NET Core 中，管道式编程是一个核心且基础的概念，它的很多中间件都是通过 **管道式** 的方式来最终配置到请求管道中的，所以理解这里面的管道式编程对我们编写更加健壮的 DotNetCore 程序相当重要。

## 剖析管道机制 ##

在上面的论述中，我们提到了两个很重要的概念：**请求管道（request pipeline）** 和 **中间件（middleware）**。对于它俩的关系，我个人的理解是，首先，请求管道服务于用户，其次，请求管道可以将多个相互独立的业务逻辑模块（即中间件）串联起来，然后服务于用户请求。这样做的好处是可以将业务逻辑层级化，因为在实际的业务场景中，有些业务的处理即相互独立，又依赖于其它的业务操作，各个业务模块之间的关系实际上是动态不固定的。

下面，我们尝试着来一步步解析 ASP.NET Core 中的管道机制。

### 理论解释 ###

首先，我们来看一下官方的图例解释：

![749711-20190718113742611-1129726883.png][]

从上图中，我们不难看出，当用户发出一起请求后，应用程序都会为其创建一个请求管道，在这个请求管道中，每一个中间件都会按顺序进行处理（可能会执行，也可能不会被执行，取决于具体的业务逻辑），等最后一个中间件处理完毕后请求又会以相反的方向返回给用户最终的处理结果。

### 代码阐释 ###

为了验证上述我们的理论解释，我们开始创建一个 DotNetCore 的控制台项目，然后引用如下包：

*  Microsoft.AspNetCore.App

编写如下示例代码：

class Program
    {
        static void Main(string[] args)
        {
            CreateHostBuilder(args).Build().Run();
        }
    
        private static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args).ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
            });
    }
    
    public class Startup
    {
        public void Configure(IApplicationBuilder app)
        {
            // Middleware A
            app.Use(async (context, next) =>
            {
                Console.WriteLine("A (in)");
                await next();
                Console.WriteLine("A (out)");
            });
    
            // Middleware B
            app.Use(async (context, next) =>
            {
                Console.WriteLine("B (in)");
                await next();
                Console.WriteLine("B (out)");
            });
    
            // Middleware C
            app.Run(async context =>
            {
                Console.WriteLine("C");
                await context.Response.WriteAsync("Hello World from the terminal middleware");
            });
        }
    }

上述代码段展示了一个最简单的 ASP.NET Core Web 程序，尝试 F5 运行我们的程序，然后打开浏览器访问 [http://127.0.0.1:5000][http_127.0.0.1_5000] 会看到浏览器显示了 Hello World from the terminal middleware 的信息。对应的控制台信息如下图所示：

![749711-20190718164837125-868968306.png][]

上述示例程序成功验证了我们理论解释中的一些设想，这说明在 Configure 函数中成功构建了一个完成的请求管道，那既然这样，我们就可以将其修改为我们之前使用管道的方式，示例代码如下所示：

public class Startup
    {
        public void Configure(IApplicationBuilder app)
        {
            app.Use(async (context, next) =>
            {
                Console.WriteLine("A (int)");
                await next();
                Console.WriteLine("A (out)");
            }).Use(async (context, next) =>
            {
                Console.WriteLine("B (int)");
                await next();
                Console.WriteLine("B (out)");
            }).Run(async context =>
            {
                Console.WriteLine("C");
                await context.Response.WriteAsync("Hello World from the terminal middleware");
            });
        }
    }

这两个方式都能让我们的请求管道正常运行，只是写的方式不同。至于采用哪种方式完全看个人喜好。需要注意的是，最后一个控制台中间件需要最后注册，因为它的处理是单向的，不涉及将用户请求修改后返回。

同样的，我们也可以对我们的管道中间件进行条件式组装（分叉路由），组装条件可以依据具体的业务场景而定，这里我以路由为条件进行组装，不同的访问路由最终访问的中间件是不一样的，示例代码如下所示：

public class Startup
    {
        public void Configure(IApplicationBuilder app)
        {
            // Middleware A
            app.Use(async (context, next) =>
            {
                Console.WriteLine("A (in)");
                await next();
                Console.WriteLine("A (out)");
            });
    
            // Middleware B
            app.Map(
                    new PathString("/foo"),
                    a => a.Use(async (context, next) =>
                    {
                        Console.WriteLine("B (in)");
                        await next();
                        Console.WriteLine("B (out)");
                    }));
    
            // Middleware C
            app.Run(async context =>
            {
                Console.WriteLine("C");
                await context.Response.WriteAsync("Hello World from the terminal middleware");
            });
        }
    }

当我们直接访问 [http://127.0.0.1:5000][http_127.0.0.1_5000] 时，对应的请求路由输出如下：

![749711-20190718165126641-1304030059.png][]

对应的页面会回显 Hello World from the terminal middleware

当我们直接访问 [httP://127.0.0.1:5000/foo][httP_127.0.0.1_5000_foo] 时，对应的请求路由输出如下：

![749711-20190718165143762-364532396.png][]

当我们尝试查看对应的请求页面，发现对应的页面却是 **HTTP ERROR 404** ，通过上述输出我们可以找到原因，是由于最后一个注册的终端路由未能成功调用，导致不能返回对应的请求结果。针对这种情况有两种解决方法。

一种是在我们的 路由B 中直接返回请求结果，示例代码如下所示：

app.Map(
        new PathString("/foo"),
        a => a.Use(async (context, next) =>
        {
            Console.WriteLine("B (in)");
            await next();
            await context.Response.WriteAsync("Hello World from the middleware B");
            Console.WriteLine("B (out)");
        }));

这种方式不太推荐，因为它极易导致业务逻辑的不一致性，违反了 **单一职责原则** 的思想。

另一种解决办法是通过路由匹配的方式，示例代码如下所示：

app.UseWhen(
        context => context.Request.Path.StartsWithSegments(new PathString("/foo")),
        a => a.Use(async (context, next) =>
        {
            Console.WriteLine("B (in)");
            await next();
            Console.WriteLine("B (out)");
        }));

通过使用 **UseWhen** 的方式，添加了一个业务中间件对应的业务条件，在该中间件执行完毕后会自动回归到主的请求管道中。最终对应的日志输出入下图所示：

![749711-20190718171511115-2107402268.png][]

同样的，我们也可以自定义一个中间件，示例代码如下所示：

public class Startup
    {
        public void Configure(IApplicationBuilder app)
        {
            // app.UseMiddleware<CustomMiddleware>();
            //等价于下述调用方式
            app.UseCustomMiddle();
    
            // Middleware C
            app.Run(async context =>
            {
                Console.WriteLine("C");
                await context.Response.WriteAsync("Hello World from the terminal middleware");
            });
        }
    }
    
    public class CustomMiddleware
    {
        private readonly RequestDelegate _next;
        public CustomMiddleware(RequestDelegate next)
        {
            _next = next;
        }
    
        public async Task InvokeAsync(HttpContext httpContext)
        {
            Console.WriteLine("CustomMiddleware (in)");
            await _next.Invoke(httpContext);
            Console.WriteLine("CustomMiddleware (out)");
        }
    }
    
    public static class CustomMiddlewareExtension
    {
        public static IApplicationBuilder UseCustomMiddle(this IApplicationBuilder builder)
        {
            return builder.UseMiddleware<CustomMiddleware>();
        }
    }

日志输出如下图所示：

![749711-20190718173650349-1330399610.png][]

由于 ASP.NET Core 中的自定义中间件都是通过 **依赖注入（DI）** 的的方式来进行实例化的。所以对应的构造函数，我们是可以注入我们想要的数据类型，不光是 `RequestDelegate`；其次，我们自定义的中间件还需要实现一个公有的 `public void Invoke(HttpContext httpContext)` 或 `public async Task InvokeAsync(HttpContext httpContext)` 的方法，该方法内部主要处理我们的自定义业务，并进行中间件的连接，扮演着 **枢纽中心** 的角色。

### 源码分析 ###

由于 ASP.NET Core 是完全开源跨平台的，所以我们可以很容易的在 [Github][] 上找到其对应的托管仓库。最后，我们可以看一下 ASP.NET Core 官方的一些实现代码。如下图所示：

![749711-20190718175619050-1120899971.png][]

官方开源了内置中间件的全部实现代码，这里我以 `健康检查（HeathChecks）` 中间件为例，来验证一下我们上面说的自定义中间件的实现。

![749711-20190718181407233-238884345.png][]

通过查阅源码，我们可以看出，我们上述自定义的中间件是符合官方的实现标准的。同样的，当我们以后使用某个内置中间件时，如果对其具体实现感兴趣，可以通过这种方式来进行查看。

## 总结 ##

当我们对 ASP.NET Core 的请求管道进行中间件配置的时候，有一个地方需要注意一下，就是中间件的配置一定要具体的业务逻辑顺序进行，比如用户认证配置一定要先于路由配置，结合到代码就是下述示例：

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
    {
        //......
        app.UseAuthentication();
        //......
        app.UseMvc();
    }

如果当我们的中间件顺序配置不当的话，极有可能导致相应的业务出现问题。

就 ASP.NET Core 的技术架构而言，管道式编程只是其中很小很基础的一部分，整个技术框架设计与实现，用到了很多优秀的技术和架构思想。但是这些高大上的实现都是基于基础技术衍化而来的，所以，基础很重要，只有把基础打扎实了，才不会被技术浪潮所淘汰。

上述所有内容就是我个人对 ASP.NET Core 中的管道式编程的一些理解和拙见，如果有不正确或不当的地方，还请斧正。

望共勉！

## 相关参考 ##

*  [ASP.NET Core Middleware][]
 *  [UNDERSTANDING THE ASP.NET CORE MIDDLEWARE PIPELINE][]
 *  [ASP.NET Web API标准的“管道式”设计][ASP.NET Web API]

## 赞赏 ##

转载于:https://www.cnblogs.com/hippieZhou/p/11205573.html

[749711-20190718105721853-511996160.png]: /images/20230810/1ed73f173f974f0db98458e18f0f9c89.png
[C_]: https://www.cnblogs.com/hippieZhou/p/11174644.html
[749711-20190718113742611-1129726883.png]: /images/20230810/56f6d0fb6dd8421ca3adf90933777cf6.png
[http_127.0.0.1_5000]: http://127.0.0.1:5000
[749711-20190718164837125-868968306.png]: /images/20230810/e1ee8530ff024bf2a263799303803807.png
[749711-20190718165126641-1304030059.png]: /images/20230810/46588658d07b421eb592e3c777d0b3c7.png
[httP_127.0.0.1_5000_foo]: http://127.0.0.1:5000/foo
[749711-20190718165143762-364532396.png]: /images/20230810/30da927c1f4f4cd8a69af53b79961abf.png
[749711-20190718171511115-2107402268.png]: /images/20230810/104505bdfc434e708ed5aba0d218eb6c.png
[749711-20190718173650349-1330399610.png]: /images/20230810/4c55becc784c4e28820a11e408e26db2.png
[Github]: https://github.com/aspnet/AspNetCore
[749711-20190718175619050-1120899971.png]: /images/20230810/4108d2d01687496a83f42337162951b0.png
[749711-20190718181407233-238884345.png]: /images/20230810/136851a778ab49e6b61c74365101b5b6.png
[ASP.NET Core Middleware]: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/middleware/index?view=aspnetcore-2.2
[UNDERSTANDING THE ASP.NET CORE MIDDLEWARE PIPELINE]: https://thomaslevesque.com/2018/03/27/understanding-the-asp-net-core-middleware-pipeline/
[ASP.NET Web API]: https://www.cnblogs.com/artech/p/asp-net-web-api-pipeline.html