Asp.Net Core EndPoint 终结点路由工作原理解读

一、背景

在本打算写一篇关于Identityserver4 的文章时候,却发现自己对EndPoint -终结点路由还不是很了解,故暂时先放弃了IdentityServer4 的研究和编写;所以才产生了今天这篇关于EndPoint (终结点路由) 的文章。

还是跟往常一样,打开电脑使用强大的Google 和百度搜索引擎查阅相关资料,以及打开Asp.net core 3.1 的源代码进行拜读,同时终于在我的实践及测试中对EndPoint 有了不一样的认识,说到这里更加敬佩微软对Asp.net core 3.x 的框架中管道模型的设计。

我先来提出以下几个问题:

  1. 当访问一个Web 应用地址时,Asp.Net Core 是怎么执行到ControllerAction的呢?
  2. EndPoint 跟普通路由又存在着什么样的关系?
  3. UseRouting()UseAuthorization()UserEndpoints() 这三个中间件的关系是什么呢?
  4. 怎么利用EndPoint 终结者路由来拦截Action 的执行并且记录相关操作日志?(时间有限,下一篇文章再来分享整理)

二、拜读源码解惑

Startup 代码

我们先来看一下Startup中简化版的代码,代码如下:

public void ConfigureServices(IServiceCollection services)
{
        services.AddControllers();
}

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
        app.UseRouting();
        app.UseAuthorization();
        app.UseEndpoints(endpoints =>
        {
              endpoints.MapControllers();
        });
}

程序启动阶段:

  • 第一步:执行services.AddControllers()

    Controller的核心服务注册到容器中去

  • 第二步:执行app.UseRouting()

    EndpointRoutingMiddleware中间件注册到http管道中

  • 第三步:执行app.UseAuthorization()

    AuthorizationMiddleware中间件注册到http管道中

  • 第四步:执行app.UseEndpoints(encpoints=>endpoints.MapControllers())

    有两个主要的作用:

    调用endpoints.MapControllers()将本程序集定义的所有ControllerAction转换为一个个的EndPoint放到路由中间件的配置对象RouteOptions

    EndpointMiddleware中间件注册到http管道中

app.UseRouting() 源代码如下:

public static IApplicationBuilder UseRouting(this IApplicationBuilder builder)
{
       if (builder == null)
       {
             throw new ArgumentNullException(nameof(builder));
       }

       VerifyRoutingServicesAreRegistered(builder);

       var endpointRouteBuilder = new DefaultEndpointRouteBuilder(builder);
       builder.Properties[EndpointRouteBuilder] = endpointRouteBuilder;

       return builder.UseMiddleware<EndpointRoutingMiddleware>(endpointRouteBuilder);
 }

EndpointRoutingMiddleware 中间件代码如下:

internal sealed class EndpointRoutingMiddleware
    {
        private const string DiagnosticsEndpointMatchedKey = "Microsoft.AspNetCore.Routing.EndpointMatched";

        private readonly MatcherFactory _matcherFactory;
        private readonly ILogger _logger;
        private readonly EndpointDataSource _endpointDataSource;
        private readonly DiagnosticListener _diagnosticListener;
        private readonly RequestDelegate _next;

        private Task<Matcher> _initializationTask;

        public EndpointRoutingMiddleware(
            MatcherFactory matcherFactory,
            ILogger<EndpointRoutingMiddleware> logger,
            IEndpointRouteBuilder endpointRouteBuilder,
            DiagnosticListener diagnosticListener,
            RequestDelegate next)
        {
            if (endpointRouteBuilder == null)
            {
                throw new ArgumentNullException(nameof(endpointRouteBuilder));
            }

            _matcherFactory = matcherFactory ?? throw new ArgumentNullException(nameof(matcherFactory));
            _logger = logger ?? throw new ArgumentNullException(nameof(logger));
            _diagnosticListener = diagnosticListener ?? throw new ArgumentNullException(nameof(diagnosticListener));
            _next = next ?? throw new ArgumentNullException(nameof(next));

            _endpointDataSource = new CompositeEndpointDataSource(endpointRouteBuilder.DataSources);
        }

        public Task Invoke(HttpContext httpContext)
        {
            // There‘s already an endpoint, skip maching completely
            var endpoint = httpContext.GetEndpoint();
            if (endpoint != null)
            {
                Log.MatchSkipped(_logger, endpoint);
                return _next(httpContext);
            }

            // There‘s an inherent race condition between waiting for init and accessing the matcher
            // this is OK because once `_matcher` is initialized, it will not be set to null again.
            var matcherTask = InitializeAsync();
            if (!matcherTask.IsCompletedSuccessfully)
            {
                return AwaitMatcher(this, httpContext, matcherTask);
            }

            var matchTask = matcherTask.Result.MatchAsync(httpContext);
            if (!matchTask.IsCompletedSuccessfully)
            {
                return AwaitMatch(this, httpContext, matchTask);
            }

            return SetRoutingAndContinue(httpContext);

            // Awaited fallbacks for when the Tasks do not synchronously complete
            static async Task AwaitMatcher(EndpointRoutingMiddleware middleware, HttpContext httpContext, Task<Matcher> matcherTask)
            {
                var matcher = await matcherTask;
                await matcher.MatchAsync(httpContext);
                await middleware.SetRoutingAndContinue(httpContext);
            }

            static async Task AwaitMatch(EndpointRoutingMiddleware middleware, HttpContext httpContext, Task matchTask)
            {
                await matchTask;
                await middleware.SetRoutingAndContinue(httpContext);
            }

        }

        [MethodImpl(MethodImplOptions.AggressiveInlining)]
        private Task SetRoutingAndContinue(HttpContext httpContext)
        {
            // If there was no mutation of the endpoint then log failure
            var endpoint = httpContext.GetEndpoint();
            if (endpoint == null)
            {
                Log.MatchFailure(_logger);
            }
            else
            {
                // Raise an event if the route matched
                if (_diagnosticListener.IsEnabled() && _diagnosticListener.IsEnabled(DiagnosticsEndpointMatchedKey))
                {
                    // We‘re just going to send the HttpContext since it has all of the relevant information
                    _diagnosticListener.Write(DiagnosticsEndpointMatchedKey, httpContext);
                }

                Log.MatchSuccess(_logger, endpoint);
            }

            return _next(httpContext);
        }

        // Initialization is async to avoid blocking threads while reflection and things
        // of that nature take place.
        //
        // We‘ve seen cases where startup is very slow if we  allow multiple threads to race
        // while initializing the set of endpoints/routes. Doing CPU intensive work is a
        // blocking operation if you have a low core count and enough work to do.
        private Task<Matcher> InitializeAsync()
        {
            var initializationTask = _initializationTask;
            if (initializationTask != null)
            {
                return initializationTask;
            }

            return InitializeCoreAsync();
        }

        private Task<Matcher> InitializeCoreAsync()
        {
            var initialization = new TaskCompletionSource<Matcher>(TaskCreationOptions.RunContinuationsAsynchronously);
            var initializationTask = Interlocked.CompareExchange(ref _initializationTask, initialization.Task, null);
            if (initializationTask != null)
            {
                // This thread lost the race, join the existing task.
                return initializationTask;
            }

            // This thread won the race, do the initialization.
            try
            {
                var matcher = _matcherFactory.CreateMatcher(_endpointDataSource);

                // Now replace the initialization task with one created with the default execution context.
                // This is important because capturing the execution context will leak memory in ASP.NET Core.
                using (ExecutionContext.SuppressFlow())
                {
                    _initializationTask = Task.FromResult(matcher);
                }

                // Complete the task, this will unblock any requests that came in while initializing.
                initialization.SetResult(matcher);
                return initialization.Task;
            }
            catch (Exception ex)
            {
                // Allow initialization to occur again. Since DataSources can change, it‘s possible
                // for the developer to correct the data causing the failure.
                _initializationTask = null;

                // Complete the task, this will throw for any requests that came in while initializing.
                initialization.SetException(ex);
                return initialization.Task;
            }
        }

        private static class Log
        {
            private static readonly Action<ILogger, string, Exception> _matchSuccess = LoggerMessage.Define<string>(
                LogLevel.Debug,
                new EventId(1, "MatchSuccess"),
                "Request matched endpoint ‘{EndpointName}‘");

            private static readonly Action<ILogger, Exception> _matchFailure = LoggerMessage.Define(
                LogLevel.Debug,
                new EventId(2, "MatchFailure"),
                "Request did not match any endpoints");

            private static readonly Action<ILogger, string, Exception> _matchingSkipped = LoggerMessage.Define<string>(
                LogLevel.Debug,
                new EventId(3, "MatchingSkipped"),
                "Endpoint ‘{EndpointName}‘ already set, skipping route matching.");

            public static void MatchSuccess(ILogger logger, Endpoint endpoint)
            {
                _matchSuccess(logger, endpoint.DisplayName, null);
            }

            public static void MatchFailure(ILogger logger)
            {
                _matchFailure(logger, null);
            }

            public static void MatchSkipped(ILogger logger, Endpoint endpoint)
            {
                _matchingSkipped(logger, endpoint.DisplayName, null);
            }
        }
    }

我们从它的源码中可以看到,EndpointRoutingMiddleware中间件先是创建matcher,然后调用matcher.MatchAsync(httpContext)去寻找Endpoint,最后通过httpContext.GetEndpoint()验证了是否已经匹配到了正确的Endpoint并交个下个中间件继续执行!

app.UseEndpoints() 源代码

public static IApplicationBuilder UseEndpoints(this IApplicationBuilder builder, Action<IEndpointRouteBuilder> configure)
{
       if (builder == null)
       {
              throw new ArgumentNullException(nameof(builder));
       }

       if (configure == null)
       {
              throw new ArgumentNullException(nameof(configure));
       }

       VerifyRoutingServicesAreRegistered(builder);

       VerifyEndpointRoutingMiddlewareIsRegistered(builder, out var endpointRouteBuilder);

       configure(endpointRouteBuilder);

       // Yes, this mutates an IOptions. We‘re registering data sources in a global collection which
       // can be used for discovery of endpoints or URL generation.
       //
       // Each middleware gets its own collection of data sources, and all of those data sources also
       // get added to a global collection.
       var routeOptions = builder.ApplicationServices.GetRequiredService<IOptions<RouteOptions>>();
        foreach (var dataSource in endpointRouteBuilder.DataSources)
        {
              routeOptions.Value.EndpointDataSources.Add(dataSource);
        }

        return builder.UseMiddleware<EndpointMiddleware>();
}

internal class DefaultEndpointRouteBuilder : IEndpointRouteBuilder
{
        public DefaultEndpointRouteBuilder(IApplicationBuilder applicationBuilder)
        {
            ApplicationBuilder = applicationBuilder ?? throw new ArgumentNullException(nameof(applicationBuilder));
            DataSources = new List<EndpointDataSource>();
        }

        public IApplicationBuilder ApplicationBuilder { get; }

        public IApplicationBuilder CreateApplicationBuilder() => ApplicationBuilder.New();

        public ICollection<EndpointDataSource> DataSources { get; }

        public IServiceProvider ServiceProvider => ApplicationBuilder.ApplicationServices;
    }

代码中构建了DefaultEndpointRouteBuilder 终结点路由构建者对象,该对象中存储了Endpoint的集合数据;同时把终结者路由集合数据存储在了routeOptions 中,并注册了EndpointMiddleware 中间件到http管道中;

Endpoint对象代码如下:

/// <summary>
/// Represents a logical endpoint in an application.
/// </summary>
public class Endpoint
{
        /// <summary>
        /// Creates a new instance of <see cref="Endpoint"/>.
        /// </summary>
        /// <param name="requestDelegate">The delegate used to process requests for the endpoint.</param>
        /// <param name="metadata">
        /// The endpoint <see cref="EndpointMetadataCollection"/>. May be null.
        /// </param>
        /// <param name="displayName">
        /// The informational display name of the endpoint. May be null.
        /// </param>
        public Endpoint(
            RequestDelegate requestDelegate,
            EndpointMetadataCollection metadata,
            string displayName)
        {
            // All are allowed to be null
            RequestDelegate = requestDelegate;
            Metadata = metadata ?? EndpointMetadataCollection.Empty;
            DisplayName = displayName;
        }

        /// <summary>
        /// Gets the informational display name of this endpoint.
        /// </summary>
        public string DisplayName { get; }

        /// <summary>
        /// Gets the collection of metadata associated with this endpoint.
        /// </summary>
        public EndpointMetadataCollection Metadata { get; }

        /// <summary>
        /// Gets the delegate used to process requests for the endpoint.
        /// </summary>
        public RequestDelegate RequestDelegate { get; }

        public override string ToString() => DisplayName ?? base.ToString();
    }

Endpoint 对象代码中有两个关键类型属性分别是EndpointMetadataCollection 类型和RequestDelegate

  • EndpointMetadataCollection:存储了ControllerAction相关的元素集合,包含Action 上的Attribute 特性数据等
  • RequestDelegate :存储了Action 也即委托,这里是每一个Controller 的Action 方法

再回过头来看看EndpointMiddleware 中间件和核心代码,EndpointMiddleware 的一大核心代码主要是执行Endpoint 的RequestDelegate 委托,也即Controller 中的Action 的执行。

public Task Invoke(HttpContext httpContext)
{
        var endpoint = httpContext.GetEndpoint();
        if (endpoint?.RequestDelegate != null)
        {
             if (!_routeOptions.SuppressCheckForUnhandledSecurityMetadata)
             {
                 if (endpoint.Metadata.GetMetadata<IAuthorizeData>() != null &&
                        !httpContext.Items.ContainsKey(AuthorizationMiddlewareInvokedKey))
                  {
                      ThrowMissingAuthMiddlewareException(endpoint);
                  }

                  if (endpoint.Metadata.GetMetadata<ICorsMetadata>() != null &&
                       !httpContext.Items.ContainsKey(CorsMiddlewareInvokedKey))
                   {
                       ThrowMissingCorsMiddlewareException(endpoint);
                   }
             }

            Log.ExecutingEndpoint(_logger, endpoint);

            try
            {
                 var requestTask = endpoint.RequestDelegate(httpContext);
                 if (!requestTask.IsCompletedSuccessfully)
                 {
                     return AwaitRequestTask(endpoint, requestTask, _logger);
                 }
            }
            catch (Exception exception)
            {
                 Log.ExecutedEndpoint(_logger, endpoint);
                 return Task.FromException(exception);
            }

            Log.ExecutedEndpoint(_logger, endpoint);
            return Task.CompletedTask;
        }

        return _next(httpContext);

        static async Task AwaitRequestTask(Endpoint endpoint, Task requestTask, ILogger logger)
         {
             try
             {
                 await requestTask;
             }
             finally
             {
                 Log.ExecutedEndpoint(logger, endpoint);
             }
         }
}

疑惑解答:

1. 当访问一个Web 应用地址时,Asp.Net Core 是怎么执行到ControllerAction的呢?

答:程序启动的时候会把所有的Controller 中的Action 映射存储到routeOptions 的集合中,Action 映射成Endpoint终结者 的RequestDelegate 委托属性,最后通过UseEndPoints 添加EndpointMiddleware 中间件进行执行,同时这个中间件中的Endpoint 终结者路由已经是通过Routing匹配后的路由。

2. EndPoint 跟普通路由又存在着什么样的关系?

答:Ednpoint 终结者路由是普通路由map 转换后的委托路由,里面包含了路由方法的所有元素信息EndpointMetadataCollectionRequestDelegate 委托。

3. UseRouting()UseAuthorization()UseEndpoints() 这三个中间件的关系是什么呢?

答:UseRouing 中间件主要是路由匹配,找到匹配的终结者路由EndpointUseEndpoints 中间件主要针对UseRouting 中间件匹配到的路由进行 委托方法的执行等操作。

UseAuthorization 中间件主要针对 UseRouting 中间件中匹配到的路由进行拦截 做授权验证操作等,通过则执行下一个中间件UseEndpoints(),具体的关系可以看下面的流程图:

上面流程图中省略了一些部分,主要是把UseRoutingUseAuthorizationUseEndpoint 这三个中间件的关系突显出来。

最后我们可以在UseRouting() 和UseEndpoint() 注册的Http 管道之间 注册其他牛逼的自定义中间件,以实现我们自己都有的业务逻辑

以上如果有错误的地方,请大家积极纠正,谢谢大家的支持!!

原文地址:https://www.cnblogs.com/mtxcat/p/12708147.html

时间: 2024-10-01 04:27:42

Asp.Net Core EndPoint 终结点路由工作原理解读的相关文章

asp.net core 3.x 通用主机原理及使用

原文:asp.net core 3.x 通用主机原理及使用 一.前言 只是讲asp.net core 3.x通用主机的大致原理,这些东西是通过查看源码以及自己根据经验总结得来的,在文章中不会深入源码,因为个人觉得懂原理就晓得扩展点,后期碰到有需求的时候再仔细去研究源码也不迟.阅读前你应该先去了解下(推荐博客园老A的博客): asp.net core中的依赖注入. 配置, 讲解的方式是: 概述 逐一介绍核心类及扩展方式 通常我们如何使用 总结 二.概述 以前的控制台应用程序.winform程序启动

asp.net core 3.x Endpoint终结点路由1-基本介绍和使用

前言 我是从.net 4.5直接跳到.net core 3.x的,感觉asp.net这套东西最初是从4.5中的owin形成的.目前官方文档重点是讲路由,没有特别说明与传统路由的区别,本篇主要介绍终结点路由的相关概念和如何使用,不会详细介绍路由,这个参考官方文档就ok了.如果将来有机会研究到底层再深度剖析. 参考:https://docs.microsoft.com/zh-cn/aspnet/core/fundamentals/routing?view=aspnetcore-3.1https://

asp.net core 系列 6 路由(中)

一.URL 生成 接着上篇讲MVC的路由,MVC 应用程序可以使用路由的 URL 生成功能,生成指向操作的 URL 链接. 生成 URL 可消除硬编码 URL,使代码更稳定.更易维护. 此部分重点介绍 MVC 提供的 URL 生成功能,并且仅涵盖 URL 生成工作原理的基础知识. IUrlHelper 接口用于生成 URL,是 MVC 与路由之间的基础结构的基础部分. 在控制器.视图和视图组件中,可通过 Url 属性找到 IUrlHelper 的实例. // // mvc 框架的Controll

【ASP.NET Core】给路由规则命名有何用处

上一篇中老周给伙伴们介绍了自定义视图搜索路径的方法,本篇咱们扯一下有关 URL 路径规则的名称问题.在扯今天的话题之前,先补充点东东.在上一篇中设置视图搜索路径时用到三个有序参数:{2}{1}{0},分别是 Area.Controller.Action.其中说到几个特殊的视图,如_Layout.cshtml._ViewStart.cshtml等._Layout.cshtml 页默认放在 /Views/Shared 目录下,但,_ViewStart.cshtml 和 _ViewImports.cs

experss路由工作原理

router.get("/", function(req, res) { res.render("index", {"title":"express"}); }); 这段代码的意思是当访问主页时,调用ejs模板引擎,来渲染index.ejs模板文件(即将title变量全部替换为字符串Express),生成静态页面并显示在浏览器中. 我们来做一些修改,以上代码实现了路由的功能,我们当然可以不要routes/index.js文件,

Asp.Net Core 中间件应用实践中你不知道的那些事

一.概述 这篇文章主要分享Endpoint 终结点路由的中间件的应用场景及实践案例,不讲述其工作原理,如果需要了解工作原理的同学, 可以点击查看以下两篇解读文章: Asp.Net Core EndPoint 终结点路由工作原理解读 ASP.NET CORE 管道模型及中间件使用解读 1.1 中间件(Middleware)的作用 我们知道,任何的一个web框架都是把http请求封装成一个管道,每一次的请求都是经过管道的一系列操作,最终到达我们写的代码中.那么中间件就是在应用程序管道中的一个组件,用

ASP.NET Core 开发人员异常页面

原文:ASP.NET Core 开发人员异常页面 UseDeveloperExceptionPage 中间件 我们谈谈在 Startup 类的 Configure()方法中以下代码: public void Configure(IApplicationBuilder app, IHostingEnvironment env) { if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); } app.UseFileServer(); a

Asp.Net Core 入门(六)—— 路由

Asp.Net Core MVC的路由在Startup.cs文件中的Configure方法中进行配置,使其加入到Http请求管道中,如果不配置,那么我们所发送的请求无法得到象应. 那么该怎么配置Asp.Net Core MVC的路由呢?通常是在Configure方法最后一行加入 app.UseMvcWithDefaultRoute(); 或者 app.UseMvc(); app.UseMvcWithDefaultRoute(); //使用默认路由 app.UseMvc(routes => { r

ASP.NET Core MVC/WebAPi如何构建路由?

前言 本节我们来讲讲ASP.NET Core中的路由,在讲路由之前我们首先回顾下之前所讲在ASP.NET Core中的模型绑定这其中有一个问题是我在项目当中遇见的,我们下面首先来看看这个问题. 回顾ASP.NET Core模型绑定 我们有这样一个场景:修改个人资料中的各个属性,此时每个属性的值的类型肯定是不一样的,所以我们将值定义为object,如下model. public class BlogViewModel { public string prop { get; set; } publi