- A+
在Asp.Net Core
中,管道往往伴随着请求一起出现。客户端发起Http
请求,服务端去响应这个请求,之间的过程都在管道内进行。
举一个生活中比较常见的例子:旅游景区。
我们都知道,有些景区大门离景区很远,我们需要经过层层关卡才能到达景区。
我的请求最终就是去到景区,去到景区的整个过程就是管道,景区就是服务器,层层关卡就是一个个中间件了,比如:门票
、停车费
、摆渡费
等等。
如果其中任何一个中间件卡壳了,比如我没买门票,那别人肯定是不让我进去,这就是管道短路了。
Asp.Net Core
请求管道包含一系列Http
请求委托(RequestDelegate
),依次调用。
微软给的图示:
Asp.Net Core服务
在解释管道的使用方法之前,我们先来准备一个Asp.Net Core
服务。
创建一个.Net Core
控制台应用程序,并实现如下代码,一个简单的使用 Kestrel
托管的服务就完成了:
internal class Program { static void Main(string[] args) { new WebHostBuilder() .UseKestrel() .UseStartup<Startup2>() .Build() .Start(); Console.ReadLine(); } } public class Startup { public void Configure(IApplicationBuilder app) { } }
这也是.Net Core
的优点之一,提供一个平台,我们去选择我们需要的模块,摒弃那些多余的功能。优点是优点,一般开发中直接一把梭。
Kestrel
托管默认监听端口:5000
管道中间件
微软这边内置了三个扩展函数供我们构建自己的中间件:
- Use
- Map
- Run
其中Use
和Map
函数还提供了对应的分支扩展:UseWhen
、MapWhen
、UseMiddleware
。下面我们一个个来解释。
app.Use
Use
是最常用的一种模式,承接上一个请求并执行下一个请求的任务
public void Configure(IApplicationBuilder app) { app.Use(async (context, next) => { Console.WriteLine("middleware1"); await next.Invoke(); }); app.Use(async (context, next) => { Console.WriteLine("middleware2"); }); }
app.UseWhen
UseWhen
在Use
的基础上提供了条件分支的功能
app.UseWhen(context => // 判断请求路径的开头是否是/h context.Request.Path.StartsWithSegments(new PathString("/h")), c => c.Use(async (context, next) => { Console.WriteLine("middleware1"); await next.Invoke(); }) ); app.Use(async (context, next) => { Console.WriteLine("middleware2"); });
app.Map
Map
我们可以理解成专为请求路径扩展的分支中间件,可以根据请求路径去处理对应分支逻辑,与上面的UseWhen
例子效果类似,但更加方便。
app.Map("/h", _app => { _app.Use(async (context, next) => { Console.WriteLine("hello world"); }); });
app.MapWhen
MapWhen
与UseWhen
类似,都是在请求上下文的基础上去扩展分支,比Map
更加灵活。
app.MapWhen(context => { return context.Request.Query["name"] == "tony"; }, _app => { _app.Use(async (context, next) => { context.Response.ContentType = "text/plain; charset=utf-8"; await context.Response.WriteAsync("i 服了 you"); }); });
app.Run
Run
一般用于断路或请求管道的末尾,不会将请求传递下去
app.Run(async context => { await context.Response.WriteAsync("hello world"); });
UseMiddleware
将一个完整的类添加到管道中间件,也就是将上面的请求委托,用类以及函数的形式替代了,便于我们的代码管理。
app.UseMiddleware<DotnetboyMiddleware>(); public class DotnetboyMiddleware { private readonly RequestDelegate _next; private readonly string _name; public DotnetboyMiddleware(RequestDelegate next, string name) { _next = next; _name = name; } public Task Invoke(HttpContext context) { context.Response.WriteAsync($"my name is {_name}").Wait(); return this._next(context); } }
微软内置的一些管道中间件扩展函数就介绍完了,下面我们实现一下微软实例图示中的效果:
public void Configure(IApplicationBuilder app) { app.Use(async (context, next) => { Console.WriteLine("middleware1 : in"); await next.Invoke(); Console.WriteLine("middleware1 : out"); }); app.Use(async (context, next) => { Console.WriteLine("middleware2 : in"); await next.Invoke(); Console.WriteLine("middleware2 : out"); }); app.Run(async context => { Console.WriteLine("Hello World"); await context.Response.WriteAsync("Hello World"); }); }
从上面的例子中我们可以看到,中间件都是由上而下依次执行,由每个中间件决定是否继续执行下一个中间件,最终到响应结果。
如果哪个中间件决定不往下执行,那通道也就短路了,比如我们去掉 middleware2
的 await next.Invoke();
执行到 Console.WriteLine("middleware2 : out");
就短路了,此路不通,原路返回。
因为管道中间件执行逻辑的关系,我们在实际开发中要注意两点:
-
1、谨慎使用管道短路
-
2、注意中间件的使用顺序,比如:路由中间件肯定是要在认证中间件前面执行,有中间件需要访问文件,在此之前就必须先执行开放静态文件的中间件
编辑于 2021-12-22 18:19
之前的标题一直是.Net Core
基础篇,现在改成了Asp.Net Core
基础篇,因为.Net Core
与Asp.Net Core
不是一个概念,平台 - 框架
,容易引起误解。类似之前的.NET Framework与Asp.Net的关系。也是我个人的疏忽和映像流,理所当然的写成了.Net Core
。
在这里多谢两位老哥的提点:@隆德尔、@那一剑风情,评论我就不放了,要脸。
其他有理解错的地方,也希望大家能提点一二,写博客的目的就是在分享中不断纠错不断进步。