.NET Core技术研究-中间件的由来和使用

  我们将原有ASP.NET应用升级到ASP.NET Core的过程中,会遇到一个新的概念:中间件。

  中间件是ASP.NET Core全新引入的概念。中间件是一种装配到应用管道中以处理请求和响应的软件。 每个组件:

  • 选择是否将请求传递到管道中的下一个组件。
  • 可在管道中的下一个组件前后执行工作。

  单独看以上中间件的定义,一个很直观的感觉:中间件是HTTP请求管道中的一层层的AOP扩展。

  在展开介绍中间件之前,我们先回顾一下ASP.NET中HttpHandler和HttpModule的处理方式。

 一、ASP.NET中HttpHandler和HttpModule

  先看一张图:

   

 

   上图中有两个概念HttpHandler和HttpModule,其中:

   HttpHandler用于处理具有给定文件名或扩展名的请求。比如上图中的.report类的请求,同时,任何一个HttpHandler都需要实现接口IHttpHandler,都需要在Web.Config配置文件中注册使用。

   HttpModule用于处理每个请求调用,比如上图中的Authorization Module,每个Http请求都会经过HttpModule的处理。通过HttpModule可以中断Http请求,可以自定义HttpResponse返回。同时,任何一个HttpModule都需要实现接口IHttpModule,都需要在Web.Config配置文件中注册使用。

  ASP.NET Core引入了中间件来实现上面2种Http请求处理扩展。ASP.NET Core中间件和 ASP.NET HttpHandler HttpModule有什么区别?

  二、ASP.NET Core中间件和 ASP.NET HttpHandler HttpModule的区别

  1. 中间件比HttpHandler、HttpModule更简单

  • "模块"、"处理程序"、" Global.asax.cs"、 "WEB.CONFIG" (IIS配置除外)和 "应用程序生命周期" 消失

  • 中间件已使用HttpHandler HttpModule的角色

  • 中间件使用代码而不是在 web.config 中进行配置

  • 通过管道分支,可以将请求发送到特定的中间件,不仅可以基于 URL,还可以发送到请求标头、查询字符串等。

   2. 中间件类似于HttpModule     

  • 处理每个请求调用

  • 可以实现Http请求中间和继续

  • 能够创建自定义的HttpResponse

   3. 中间件和HttpModule按不同的顺序处理

  • 中间件的顺序取决于它们插入请求管道的顺序,而模块的顺序主要基于应用程序生命周期事件

  • 中间件中Http响应的顺序与Http请求的顺序相反,而对于HttpModule,请求和响应的顺序是相同的。

      

 三、ASP.NET Core中间件的设计原理

   ASP.NET Core 请求管道包含一系列请求委托,依次调用。 下图演示了这一概念。 沿黑色箭头执行。

   

   每个请求委托(中间件)都可以在下一个请求委托(中间件)之前和之后执行操作。中间件中的异常处理委托应该在管道的早期被处理,这样就可以捕获在管道后期发生的异常。

   在Startup.Configure 方法中添加中间件组件的顺序定义了针对请求调用这些中间件的顺序,以及响应的相反顺序。 这个顺序对于安全性、性能和功能非常重要。

   看一段示例代码:

public void Configure(IApplicationBuilder app,IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
        app.UseDatabaseErrorPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
        app.UseHsts();
    }

    app.UseHttpsRedirection();
    app.UseStaticFiles();
    // app.UseCookiePolicy();

    app.UseRouting();
    // app.UseRequestLocalization();
    // app.UseCors();

    app.UseAuthentication();
    app.UseAuthorization();
    // app.UseSession();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
        endpoints.MapControllerRoute(
            name: "default",pattern: "{controller=Home}/{action=Index}/{id?}");
    });
}

  上述代码中每个中间件扩展方法都通过 Microsoft.AspNetCore.Builder 命名空间在 IApplicationBuilder 上公开。

        app.Use***都是各种常用的内置中间件。比如:

      1. 异常处理类中间件。如上述代码中:

           当应用在开发环境中运行时:异常显示页中间件 (UseDeveloperExceptionPage) 报告应用运行时错误。数据库错误页中间件报告数据库运行时错误。(app.UseDatabaseErrorPage();)

           当应用在生产环境中运行时:异常处理程序中间件 (UseExceptionHandler) 捕获以下中间件中引发的异常。TTP 严格传输安全协议 (HSTS) 中间件 (UseHsts) 添加 Strict-Transport-Security 标头。

      2. HTTPS 重定向中间件 (UseHttpsRedirection) 将 HTTP 请求重定向到 HTTPS。

      3. 静态文件中间件 (UseStaticFiles) 返回静态文件,并简化进一步请求处理。

      4. Cookie 策略中间件 (UseCookiePolicy) 使应用符合欧盟一般数据保护条例 (GDPR) 规定。

      5. 用于路由请求的路由中间件 (UseRouting)。

      6. 身份验证中间件 (UseAuthentication) 尝试对用户进行身份验证,然后才会允许用户访问安全资源。

      7. 用于授权用户访问安全资源的授权中间件 (UseAuthorization)。

      8. 会话中间件 (UseSession) 建立和维护会话状态。 如果应用使用会话状态,请在 Cookie 策略中间件之后和 MVC 中间件之前调用会话中间件。

      9. 用于将 Razor Pages 终结点添加到请求管道的终结点路由中间件(带有 MapRazorPages 的 UseEndpoints)。

      10. 对于单页应用程序 (SPA),SPA 中间件 UseSpaStaticFiles 通常是中间件管道中的最后一个。 SPA 中间件处于最后的作用是:允许所有其他中间件首先响应匹配的请求。允许具有客户端侧路由的 SPA 针对服务器应用无法识别的所有路由运行。

       还有很多其他的内置中间件,可以参考链接:https://docs.microsoft.com/en-us/aspnet/core/fundamentals/middleware/?view=aspnetcore-3.0。如下图,

       

      了解了ASP.NET Core内置的中间件之后,我们可能需要自定义一些中间件,比如说原有的ASP.NET HttpModule和HttpHandler.

      接下来第四部分,我们继续示例:

 四、自定义中间件

   将已有HttpModule用自定义中间件实现

   先看一下原有HttpModule的一个实现:

/// <summary>
/// 自定义HTTP扩展模块
/// </summary>
public class CustomerHttpModule : IHttpModule
    {        
        public void Init(HttpApplication context)
        {
            context.BeginRequest += Context_BeginRequest;
        }

        private void Context_BeginRequest(object sender,EventArgs e)
        {            
            HttpApplication app = (HttpApplication)sender;
            // Do something            
        }

        public void Dispose()
        {

        }
}

 迁移到中间件实现:

   

/// <summary>
/// 自定义中间件
/// </summary>
public class CustomerMiddleware
{
        private readonly RequestDelegate _next;

        public CustomerMiddleware(RequestDelegate next)
        {
            _next = next;
        }

        public async Task Invoke(HttpContext context)
        {
            // Do something with context near the beginning of request processing.                
            await _next.Invoke(context);
            // Clean up.
        }
}

  同时增加IApplicationBuilder的一个扩展方法:

public static IApplicationBuilder UseCustomerMiddleware(this IApplicationBuilder builder)
{
    return builder.UseMiddleware<CustomerMiddleware>();
}

  Startup中使用这个中间件:     

app.UseCustomerMiddlewares();  

 以上是对ASP.NET Core中中间件的技术由来整理和使用分享。

 

周国庆

2020/4/4       

 

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


在上文中,我介绍了事件驱动型架构的一种简单的实现,并演示了一个完整的事件派发、订阅和处理的流程。这种实现太简单了,百十行代码就展示了一个基本工作原理。然而,要将这样的解决方案运用到实际生产环境,还有很长的路要走。今天,我们就研究一下在事件处理器中,对象生命周期的管理问题。事实上,不仅仅是在事件处理器
上文已经介绍了Identity Service的实现过程。今天我们继续,实现一个简单的Weather API和一个基于Ocelot的API网关。 回顾 《Angular SPA基于Ocelot API网关与IdentityServer4的身份认证与授权(一)》 Weather API Weather
最近我为我自己的应用开发框架Apworks设计了一套案例应用程序,并以Apache 2.0开源,开源地址是:https://github.com/daxnet/apworks-examples,目的是为了让大家更为方便地学习和使用.NET Core、最新的前端开发框架Angular,以及Apwork
HAL(Hypertext Application Language,超文本应用语言)是一种RESTful API的数据格式风格,为RESTful API的设计提供了接口规范,同时也降低了客户端与服务端接口的耦合度。很多当今流行的RESTful API开发框架,包括Spring REST,也都默认支
在前面两篇文章中,我详细介绍了基本事件系统的实现,包括事件派发和订阅、通过事件处理器执行上下文来解决对象生命周期问题,以及一个基于RabbitMQ的事件总线的实现。接下来对于事件驱动型架构的讨论,就需要结合一个实际的架构案例来进行分析。在领域驱动设计的讨论范畴,CQRS架构本身就是事件驱动的,因此,
HAL,全称为Hypertext Application Language,它是一种简单的数据格式,它能以一种简单、统一的形式,在API中引入超链接特性,使得API的可发现性(discoverable)更强,并具有自描述的特点。使用了HAL的API会更容易地被第三方开源库所调用,并且使用起来也很方便
何时使用领域驱动设计?其实当你的应用程序架构设计是面向业务的时候,你已经开始使用领域驱动设计了。领域驱动设计既不是架构风格(Architecture Style),也不是架构模式(Architecture Pattern),它也不是一种软件开发方法论,所以,是否应该使用领域驱动设计,以及什么时候使用
《在ASP.NET Core中使用Apworks快速开发数据服务》一文中,我介绍了如何使用Apworks框架的数据服务来快速构建用于查询和管理数据模型的RESTful API,通过该文的介绍,你会看到,使用Apworks框架开发数据服务是何等简单快捷,提供的功能也非常多,比如对Hypermedia的
在上一讲中,我们已经完成了一个完整的案例,在这个案例中,我们可以通过Angular单页面应用(SPA)进行登录,然后通过后端的Ocelot API网关整合IdentityServer4完成身份认证。在本讲中,我们会讨论在当前这种架构的应用程序中,如何完成用户授权。 回顾 《Angular SPA基于
Keycloak是一个功能强大的开源身份和访问管理系统,提供了一整套解决方案,包括用户认证、单点登录(SSO)、身份联合、用户注册、用户管理、角色映射、多因素认证和访问控制等。它广泛应用于企业和云服务,可以简化和统一不同应用程序和服务的安全管理,支持自托管或云部署,适用于需要安全、灵活且易于扩展的用
3月7日,微软发布了Visual Studio 2017 RTM,与之一起发布的还有.NET Core Runtime 1.1.0以及.NET Core SDK 1.0.0,尽管这些并不是最新版,但也已经从preview版本升级到了正式版。所以,在安装Visual Studio 2017时如果启用了
在上文中,我介绍了如何在Ocelot中使用自定义的中间件来修改下游服务的response body。今天,我们再扩展一下设计,让我们自己设计的中间件变得更为通用,使其能够应用在不同的Route上。比如,我们可以设计一个通用的替换response body的中间件,然后将其应用在多个Route上。 O
不少关注我博客的朋友都知道我在2009年左右开发过一个名为Apworks的企业级应用程序开发框架,旨在为分布式企业系统软件开发提供面向领域驱动(DDD)的框架级别的解决方案,并对多种系统架构风格提供支持。这个框架的开发和维护我坚持了很久,一直到2015年,我都一直在不停地重构这个项目。目前这个项目在
好吧,这个题目我也想了很久,不知道如何用最简单的几个字来概括这篇文章,原本打算取名《Angular单页面应用基于Ocelot API网关与IdentityServer4ʺSP.NET Identity实现身份认证与授权》,然而如你所见,这样的名字实在是太长了。所以,我不得不缩写“单页面应用”几个字
在前面两篇文章中,我介绍了基于IdentityServer4的一个Identity Service的实现,并且实现了一个Weather API和基于Ocelot的API网关,然后实现了通过Ocelot API网关整合Identity Service做身份认证的API请求。今天,我们进入前端开发,设计
Ocelot是ASP.NET Core下的API网关的一种实现,在微服务架构领域发挥了非常重要的作用。本文不会从整个微服务架构的角度来介绍Ocelot,而是介绍一下最近在学习过程中遇到的一个问题,以及如何使用中间件(Middleware)来解决这样的问题。 问题描述 在上文中,我介绍了一种在Angu
在大数据处理和人工智能时代,数据工厂(Data Factory)无疑是一个非常重要的大数据处理平台。市面上也有成熟的相关产品,比如Azure Data Factory,不仅功能强大,而且依托微软的云计算平台Azure,为大数据处理提供了强大的计算能力,让大数据处理变得更为稳定高效。由于工作中我的项目
在上文中,我们讨论了事件处理器中对象生命周期的问题,在进入新的讨论之前,首先让我们总结一下,我们已经实现了哪些内容。下面的类图描述了我们已经实现的组件及其之间的关系,貌似系统已经变得越来越复杂了。其中绿色的部分就是上文中新实现的部分,包括一个简单的Event Store,一个事件处理器执行上下文的接
在之前《在ASP.NET Core中使用Apworks快速开发数据服务》一文的评论部分,.NET大神张善友为我提了个建议,可以使用Compile As a Service的Roslyn为语法解析提供支持。在此非常感激友哥给我的建议,也让我了解了一些Roslyn的知识。使用Roslyn的一个很大的好处
很长一段时间以来,我都在思考如何在ASP.NET Core的框架下,实现一套完整的事件驱动型架构。这个问题看上去有点大,其实主要目标是为了实现一个基于ASP.NET Core的微服务,它能够非常简单地订阅来自于某个渠道的事件消息,并对接收到的消息进行处理,于此同时,它还能够向该渠道发送事件消息,以便