什么是中间件（Middleware）？
中间件是一种装配到应用程序管道以处理请求和响应的软件。 每个组件：
- 选择是否将请求传递到管道中的下一个组件。
- 可在调用管道中的下一个组件前后执行工作。
请求委托（Request delegates）用于构建请求管道，处理每个HTTP请求。
Use, Run, and Map
请求委托使用Run，Map和Use扩展方法进行配置。单独的请求委托可以以内联匿名方法（称为内联中间件）指定，或者可以在可重用的类中定义它。这些可重用的类和内联匿名方法是中间件或中间件组件。请求流程中的每个中间件组件都负责调用流水线中的下一个组件，如果适当，则负责链接短路。
将HTTP模块迁移到中间件解释了ASP.NET Core和以前版本（ASP.NET）中的请求管道之间的区别，并提供了更多的中间件示例。
个人理解：将具体业务和底层逻辑解耦的组件。
大致的效果是：需要利用服务的人（前端写业务的），不需要知道底层逻辑（提供服务的）的具体实现，只要拿着中间件结果来用就好了。
举个例子：我开了一家炸鸡店（业务端），然而周边有太多屠鸡场（底层），为了成本我肯定想一个个比价，再综合质量挑选一家屠鸡场合作（适配不同底层逻辑）。由于市场变化，合作一段时间后，或许性价比最高的屠鸡场就不是我最开始选的了，我又要重新和另一家屠鸡场合作，进货方式、交易方式等等全都要重来一套（重新适配）。
然而我只想好好做炸鸡，有性价比高的肉送来就行。于是我找到了一个专门整合屠鸡场资源的第三方代理（中间件），跟他谈好价格和质量后（统一接口），从今天开始，我就只需要给代理钱，然后拿肉就行。代理负责保证肉的质量，至于如何根据实际性价比，选择不同的屠鸡场，那就是代理做的事了。
中间件的特点
1、满足大量应用的需要；
2、运行于多种硬件和OS平台；
3、支持分布式计算，提供跨网络、硬件和OS平台的透明性的应用或服务的交互功能；
4、支持标准的协议；
5、支持标准的接口。
主要中间件的分类
中间件分类（IDC的分类）：大致可分为六类:终端仿真/屏幕转换中间件、数据访问中间件、远程过程调用中间件、消息中间件、交易中间件、对象中间件。
中间件所包括的范围十分广泛，针对不同的应用需求涌现出多种各具特色的中间件产品。但至今中间件还没有一个比较精确的定义，因此，在不同的角度或不同的层次上，对中间件的分类也会有所不同。由于中间件需要屏蔽分布环境中异构的操作系统和网络协议，它必须能够提供分布环境下的通讯服务，我们将这种通讯服务称之为平台。基于目的和实现机制的不同，我们将平台分为以下主要几类：
1、远程过程调用中间件（Remote Procedure Call）
2、面向消息的中间件（MesSAge-Oriented Middleware）
3、对象请求代理中间件（object RequeST Brokers）
它们可向上提供不同形式的通讯服务，包括同步、排队、订阅发布、广播等等，在这些基本的通讯平台之上，可构筑各种框架，为应用程序提供不同领域内的服务，如事务处理监控器、分布数据访问、对象事务管理器OTM等。平台为上层应用屏蔽了异构平台的差异，而其上的框架又定义了相应领域内的应用的系统结构、标准的服务组件等，用户只需告诉框架所关心的事件，然后提供处理这些事件的代码。当事件发生时，框架则会调用用户的代码。用户代码不用调用框架，用户程序也不必关心框架结构、执行流程、对系统级API的调用等，所有这些由框架负责完成。因此，基于中间件开发的应用具有良好的可扩充性、易管理性、高可用性和可移植性。
使用 IApplicationBuilder 创建中间件管道
ASP.NET Core请求流程由一系列请求委托组成，如下图所示（执行流程遵循黑色箭头）：
每个委托可以在下一个委托之前和之后执行操作。委托还可以决定不将请求传递给下一个委托，这称为请求管道的短路。短路通常是可取的，因为它避免了不必要的工作。例如，静态文件中间件可以返回一个静态文件的请求，并使管道的其余部分短路。需要在管道早期调用异常处理委托，因此它们可以捕获后面管道的异常。
最简单的可能是ASP.NET Core应用程序建立一个请求的委托，处理所有的请求。此案例不包含实际的请求管道。相反，针对每个HTTP请求都调用一个匿名方法。
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;
public class Startup
{
public void Configure(IApplicationBuilder app)
{
app.Run(async context =>
{
await context.Response.WriteAsync("Hello, World!");
});
}
}
第一个 app.Run 委托终止管道。
有如下代码：
public void Configure(IApplicationBuilder app)
{
app.Run(async context =>
{
await context.Response.WriteAsync("method 1");
});
app.Run(async context =>
{
await context.Response.WriteAsync("method 2");
});
}
通过浏览器访问，发现确实在第一个app.Run终止了管道
您可以将多个请求委托与app.Use连接在一起。 next参数表示管道中的下一个委托。 （请记住，您可以通过不调用下一个参数来结束流水线。）通常可以在下一个委托之前和之后执行操作，如下例所示：
public void Configure(IApplicationBuilder app)
{
//app.Use 将多个请求委托链接在一起
app.Use(async (context, next) =>
{
//进入第一个委托 执行下一个委托之前
await context.Response.WriteAsync("Enter the first delegate\r\n");
//调用管道中的下一个委托
await next.Invoke();
await context.Response.WriteAsync("delegate 1.\r\n");
//结束第一个委托 执行下一个委托之后
await context.Response.WriteAsync("End the first delegate\r\n");
});
//app.Run 委托终止管道
app.Run(async context =>
{
//进入第二个委托
await context.Response.WriteAsync("Enter the second delegate\r\n");
await context.Response.WriteAsync("delegate 2.\r\n");
//结束第二个委托
await context.Response.WriteAsync("End the second delegate\r\n");
});
//第一个 app.Run 委托终止管道,此处不会输出
app.Run(async context =>
{
await context.Response.WriteAsync("Hello, World!");
});
}
使用浏览器访问有如下结果：
可以看出请求委托的执行顺序是遵循上面的流程图的。
注意：
响应发送到客户端后，请勿调用next.Invoke。 响应开始之后，对HttpResponse的更改将抛出异常。 例如，设置响应头，状态代码等更改将会引发异常。在调用next之后写入响应体。
- 可能导致协议违规。 例如，写入超过content-length所述内容长度。
- 可能会破坏响应内容格式。 例如，将HTML页脚写入CSS文件。
HttpResponse.HasStarted是一个有用的提示，指示是否已发送响应头和/或正文已写入。
订购
在Configure方法中添加中间件组件的顺序定义了在请求上调用它们的顺序，以及响应的相反顺序。 此排序对于安全性，性能和功能至关重要。
Configure方法（如下所示）添加了以下中间件组件：
1.异常/错误处理
2.静态文件服务
3.身份认证
4.MVC
public void Configure(IApplicationBuilder app)
{
app.UseExceptionHandler("/Home/Error"); // Call first to catch exceptions
// thrown in the following middleware.
app.UseStaticFiles(); // Return static files and end pipeline.
app.UseAuthentication(); // Authenticate before you access
// secure resources.
app.UseMvcWithDefaultRoute(); // Add MVC to the request pipeline.
}
上面的代码，UseExceptionHandler是添加到管道中的第一个中间件组件，因此它捕获以后调用中发生的任何异常。
静态文件中间件在管道中提前调用，因此可以处理请求和短路，而无需通过剩余的组件。 静态文件中间件不提供授权检查。 由其提供的任何文件，包括wwwroot下的文件都是公开的。
如果请求没有被静态文件中间件处理，它将被传递给执行身份验证的Identity中间件（app.UseAuthentication）。 身份不会使未经身份验证的请求发生短路。 虽然身份认证请求，但授权（和拒绝）仅在MVC选择特定的剃刀页面或控制器和操作之后才会发生。
授权（和拒绝）仅在MVC选择特定的Razor页面或Controller和Action之后才会发生。
以下示例演示了中间件顺序，其中静态文件的请求在响应压缩中间件之前由静态文件中间件处理。 静态文件不会按照中间件的顺序进行压缩。 来自UseMvcWithDefaultRoute的MVC响应可以被压缩。
public void Configure(IApplicationBuilder app)
{
app.UseStaticFiles(); // Static files not compressed
app.UseResponseCompression();
app.UseMvcWithDefaultRoute();
}
Use, Run, 和 Map
你可以使用Use，Run和Map配置HTTP管道。Use方法可以使管道短路（即，可以不调用下一个请求委托）。Run方法是一个约定， 并且一些中间件组件可能暴露在管道末端运行的Run [Middleware]方法。Map*扩展用作分支管道的约定。映射根据给定的请求路径的匹配来分支请求流水线，如果请求路径以给定路径开始，则执行分支。
public class Startup
{
private static void HandleMapTest1(IApplicationBuilder app)
{
app.Run(async context =>
{
await context.Response.WriteAsync("Map Test 1");
});
}
private static void HandleMapTest2(IApplicationBuilder app)
{
app.Run(async context =>
{
await context.Response.WriteAsync("Map Test 2");
});
}
public void Configure(IApplicationBuilder app)
{
app.Map("/map1", HandleMapTest1);
app.Map("/map2", HandleMapTest2);
app.Run(async context =>
{
await context.Response.WriteAsync("Hello from non-Map delegate. <p>");
});
}
}
下表显示了使用以前代码的 http://localhost:19219 的请求和响应：
请求 响应
| 请求 | 响应 |
|---|---|
| localhost:1234 | Hello from non-Map delegate. |
| localhost:1234/map1 | Map Test 1 |
| localhost:1234/map2 | Map Test 2 |
| localhost:1234/map3 | Hello from non-Map delegate. |
当使用Map时，匹配的路径段将从HttpRequest.Path中删除，并为每个请求追加到Http Request.PathBase。
MapWhen根据给定谓词的结果分支请求流水线。 任何类型为Func<HttpContext,bool>的谓词都可用于将请求映射到管道的新分支。 在以下示例中，谓词用于检测查询字符串变量分支的存在：
public class Startup
{
private static void HandleBranch(IApplicationBuilder app)
{
app.Run(async context =>
{
var branchVer = context.Request.Query["branch"];
await context.Response.WriteAsync($"Branch used = {branchVer}");
});
}
public void Configure(IApplicationBuilder app)
{
app.MapWhen(context => context.Request.Query.ContainsKey("branch"),
HandleBranch);
app.Run(async context =>
{
await context.Response.WriteAsync("Hello from non-Map delegate. <p>");
});
}
}
以下下表显示了使用上面代码 http://localhost:19219 的请求和响应：
| 请求 | 响应 |
|---|---|
| localhost:1234 | Hello from non-Map delegate. |
| localhost:1234/?branch=1 | Branch used = master |
Map支持嵌套，例如：
app.Map("/level1", level1App => {
level1App.Map("/level2a", level2AApp => {
// "/level1/level2a"
//...
});
level1App.Map("/level2b", level2BApp => {
// "/level1/level2b"
//...
});
});
Map也可以一次匹配多个片段，例如：
app.Map("/level1/level2", HandleMultiSeg);
内置中间件
ASP.NET Core附带以下中间件组件：
| 中间件 | 描述 |
|---|---|
| Authentication | 提供身份验证支持 |
| CORS | 配置跨域资源共享 |
| Response Caching | 提供缓存响应支持 |
| Response Compression | 提供响应压缩支持 |
| Routing | 定义和约束请求路由 |
| Session | 提供用户会话管理 |
| Static Files | 为静态文件和目录浏览提供服务提供支持 |
| URL Rewriting Middleware | 用于重写 Url，并将请求重定向的支持 |
编写中间件
中间件通常封装在一个类中，并使用扩展方法进行暴露。 查看以下中间件，它从查询字符串设置当前请求的Culture：
public class Startup
{
public void Configure(IApplicationBuilder app)
{
app.Use((context, next) =>
{
var cultureQuery = context.Request.Query["culture"];
if (!string.IsNullOrWhiteSpace(cultureQuery))
{
var culture = new CultureInfo(cultureQuery);
CultureInfo.CurrentCulture = culture;
CultureInfo.CurrentUICulture = culture;
}
// Call the next delegate/middleware in the pipeline
return next();
});
app.Run(async (context) =>
{
await context.Response.WriteAsync(
$"Hello {CultureInfo.CurrentCulture.DisplayName}");
});
}
}
您可以通过传递Culture来测试中间件，例如 http://localhost:19219/?culture=zh-CN
以下代码将中间件委托移动到一个类：
using Microsoft.AspNetCore.Http;
using System.Globalization;
using System.Threading.Tasks;
namespace Culture
{
public class RequestCultureMiddleware
{
private readonly RequestDelegate _next;
public RequestCultureMiddleware(RequestDelegate next)
{
_next = next;
}
public Task Invoke(HttpContext context)
{
var cultureQuery = context.Request.Query["culture"];
if (!string.IsNullOrWhiteSpace(cultureQuery))
{
var culture = new CultureInfo(cultureQuery);
CultureInfo.CurrentCulture = culture;
CultureInfo.CurrentUICulture = culture;
}
// Call the next delegate/middleware in the pipeline
return this._next(context);
}
}
}
以下通过IApplicationBuilder的扩展方法暴露中间件：
using Microsoft.AspNetCore.Builder;
namespace Culture
{
public static class RequestCultureMiddlewareExtensions
{
public static IApplicationBuilder UseRequestCulture(
this IApplicationBuilder builder)
{
return builder.UseMiddleware<RequestCultureMiddleware>();
}
}
}
以下代码从Configure调用中间件：
public class Startup
{
public void Configure(IApplicationBuilder app)
{
app.UseRequestCulture();
app.Run(async (context) =>
{
await context.Response.WriteAsync(
$"Hello {CultureInfo.CurrentCulture.DisplayName}");
});
}
}
中间件应该遵循显式依赖原则，通过在其构造函数中暴露其依赖关系。 中间件在应用程序生命周期构建一次。 如果您需要在请求中与中间件共享服务，请参阅以下请求相关性。
中间件组件可以通过构造方法参数来解析依赖注入的依赖关系。 UseMiddleware也可以直接接受其他参数。
每个请求的依赖关系
因为中间件是在应用程序启动时构建的，而不是每个请求，所以在每个请求期间，中间件构造函数使用的作用域生命周期服务不会与其他依赖注入类型共享。 如果您必须在中间件和其他类型之间共享作用域服务，请将这些服务添加到Invoke方法的签名中。 Invoke方法可以接受由依赖注入填充的其他参数。 例如：
public class MyMiddleware
{
private readonly RequestDelegate _next;
public MyMiddleware(RequestDelegate next)
{
_next = next;
}
public async Task Invoke(HttpContext httpContext, IMyScopedService svc)
{
svc.MyProperty = 1000;
await _next(httpContext);
}
}
