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 是怎么执行到Controller 的Action的呢？
  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()将本程序集定义的所有Controller和Action转换为一个个的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：存储了Controller 和Action相关的元素集合，包含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 是怎么执行到Controller 的Action的呢？

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

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

答：Ednpoint 终结者路由是普通路由map 转换后的委托路由，里面包含了路由方法的所有元素信息EndpointMetadataCollection 和RequestDelegate 委托。

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

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

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

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

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

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

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

时间： 2024-07-31 09:52:49

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