欢迎光临
我的个人博客网站

ASP.NET Core管道详解[3]: Pipeline = IServer + IHttpApplication

ASP.NET Core的请求处理管道由一个服务器和一组中间件构成,但对于面向传输层的服务器来说,它其实没有中间件的概念。当服务器接收到请求之后,会将该请求分发给一个处理器进行处理,对服务器而言,这个处理器就是一个HTTP应用,此应用通过IHttpApplication<TContext>接口来表示。由于服务器是通过IServer接口表示的,所以可以将ASP.NET Core框架的核心视为由IServer和IHttpApplication<TContext>对象组成的管道。[本文节选自《ASP.NET Core 3框架揭秘》第13章, 更多关于ASP.NET Core的文章请点这里]

ASP.NET Core管道详解[3]: Pipeline = IServer + IHttpApplication

目录
一、服务器(IServer)
二、承载应用( HostingApplication)
三、应用生命周期和请求日志
     ILogger日志
     DiagnosticSource诊断日志
     EventSource事件日志

一、服务器(IServer)

由于服务器是整个请求处理管道的“龙头”,所以启动和关闭应用的最终目的是启动和关闭服务器。ASP.NET Core框架中的服务器通过IServer接口来表示,该接口具有如下所示的3个成员,其中由服务器提供的特性就保存在其Features属性表示的IFeatureCollection集合中。IServer接口的StartAsync<TContext>方法与StopAsync方法分别用来启动和关闭服务器。

public interface IServer : IDisposable {     IFeatureCollection Features { get; }      Task StartAsync<TContext>(IHttpApplication<TContext> application, CancellationToken cancellationToken);     Task StopAsync(CancellationToken cancellationToken); }

服务器在开始监听请求之前总是绑定一个或者多个监听地址,这个地址是应用程序从外部指定的。具体来说,应用程序指定的监听地址会封装成一个特性,并且在服务器启动之前被添加到它的特性集合中。这个承载了监听地址列表的特性通过如下所示的IServerAddressesFeature接口来表示,该接口除了有一个表示地址列表的Addresses属性,还有一个布尔类型的PreferHostingUrls属性,该属性表示如果监听地址同时设置到承载系统配置和服务器上,是否优先考虑使用前者。

public interface IServerAddressesFeature {     ICollection<string> Addresses { get; }     bool PreferHostingUrls { get; set; } }

正如前面所说,服务器将用来处理由它接收请求的处理器会被视为一个通过IHttpApplication<TContext>接口表示的应用,所以可以将ASP.NET Core的请求处理管道视为IServer对象和IHttpApplication<TContext>对象的组合。当调用IServer对象的StartAsync<TContext>方法启动服务器时,我们需要提供这个用来处理请求的IHttpApplication<TContext>对象。IHttpApplication<TContext>采用基于上下文的请求处理方式,泛型参数TContext代表的就是上下文的类型。在IHttpApplication<TContext>处理请求之前,它需要先创建一个上下文对象,该上下文会在请求处理结束之后被释放。上下文的创建、释放和自身对请求的处理实现在该接口3个对应的方法(CreateContext、DisposeContext和ProcessRequestAsync)中。

public interface IHttpApplication<TContext> {     TContext CreateContext(IFeatureCollection contextFeatures);     void DisposeContext(TContext context, Exception exception);      Task ProcessRequestAsync(TContext context); }

二、承载应用( HostingApplication)

ASP.NET Core框架利用如下所示的HostingApplication类型作为IHttpApplication<TContext>接口的默认实现,它使用一个内嵌的Context类型来表示处理请求的上下文。一个Context对象是对一个HttpContext对象的封装,同时承载了一些与诊断相关的信息。

public class HostingApplication : IHttpApplication<HostingApplication.Context> {     ...     public struct Context     {         public HttpContext HttpContext { get; set; }          public IDisposable Scope { get; set; }         public long StartTimestamp { get; set; }         public bool EventLogEnabled { get; set; }         public Activity Activity { get; set; }     } }

HostingApplication对象会在开始和完成请求处理,以及在请求过程中出现异常时发出一些诊断日志事件。具体来说,HostingApplication对象会采用3种不同的诊断日志形式,包括基于DiagnosticSource和EventSource的诊断日志以及基于 .NET Core日志系统的日志。Context除HttpContext外的其他属性都与诊断日志有关。具体来说,Context的Scope是为ILogger创建的针对当前请求的日志范围(第9章有对日志范围的详细介绍),此日志范围会携带唯一标识每个请求的ID,如果注册ILoggerProvider提供的ILogger支持日志范围,它可以将这个请求ID记录下来,那么我们就可以利用这个ID将针对同一请求的多条日志消息组织起来做针对性分析。

HostingApplication对象会在请求结束之后记录当前请求处理的耗时,所以它在开始处理请求时就会记录当前的时间戳,Context的StartTimestamp属性表示开始处理请求的时间戳。它的EventLogEnabled属性表示针对EventSource的事件日志是否开启,而Activity属性则与针对DiagnosticSource的诊断日志有关,Activity代表基于当前请求处理的活动。

虽然ASP.NET Core应用的请求处理完全由HostingApplication对象负责,但是该类型的实现逻辑其实是很简单的,因为它将具体的请求处理分发给一个RequestDelegate对象,该对象表示的正是所有注册中间件组成的委托链。在创建HostingApplication对象时除了需要提供RequestDelegate对象,还需要提供用于创建HttpContext上下文的IHttpContextFactory对象,以及与诊断日志有关的ILogger对象和DiagnosticListener对象,它们被用来创建上面提到过的HostingApplicationDiagnostics对象。

public class HostingApplication : IHttpApplication<HostingApplication.Context> {     private readonly RequestDelegate _application;     private HostingApplicationDiagnostics _diagnostics;     private readonly IHttpContextFactory _httpContextFactory;      public HostingApplication(RequestDelegate application, ILogger logger,DiagnosticListener diagnosticSource, IHttpContextFactory httpContextFactory)     {         _application = application;         _diagnostics = new HostingApplicationDiagnostics(logger, diagnosticSource);         _httpContextFactory = httpContextFactory;     }      public Context CreateContext(IFeatureCollection contextFeatures)     {         var context = new Context();         var httpContext = _httpContextFactory.Create(contextFeatures);         _diagnostics.BeginRequest(httpContext, ref context);         context.HttpContext = httpContext;         return context;     }      public Task ProcessRequestAsync(Context context) => _application(context.HttpContext);      public void DisposeContext(Context context, Exception exception)     {         var httpContext = context.HttpContext;         _diagnostics.RequestEnd(httpContext, exception, context);         _httpContextFactory.Dispose(httpContext);         _diagnostics.ContextDisposed(context);     } }

如上面的代码片段所示,当CreateContext方法被调用时,HostingApplication对象会利用IHttpContextFactory工厂创建出当前HttpContext上下文,并进一步将它封装成一个Context对象。在返回这个Context对象之前,它会调用HostingApplicationDiagnostics对象的BeginRequest方法记录相应的诊断日志。用来真正处理当前请求的ProcessRequestAsync方法比较简单,只需要调用代表中间件委托链的RequestDelegate对象即可。

对于用来释放上下文的DisposeContext方法来说,它会利用IHttpContextFactory对象的Dispose方法来释放创建的HttpContext对象。换句话说,HttpContext上下文的生命周期是由HostingApplication对象控制的。完成针对HttpContext上下文的释放之后,HostingApplication对象会利用HostingApplicationDiagnostics对象记录相应的诊断日志。Context的Scope属性表示的日志范围就是在调用HostingApplicationDiagnostics对象的ContextDisposed方法时释放的。如果将HostingApplication对象引入ASP.NET Core的请求处理管道,那么完整的管道就体现为下图所示的结构。

ASP.NET Core管道详解[3]: Pipeline = IServer + IHttpApplication

三、应用生命周期和请求日志

很多人可能对ASP.NET Core框架自身记录的诊断日志并不关心,其实很多时候这些日志对纠错排错和性能监控提供了很有用的信息。例如,假设需要创建一个APM(Application Performance Management)来监控ASP.NET Core处理请求的性能及出现的异常,那么我们完全可以将HostingApplication对象记录的日志作为收集的原始数据。实际上,目前很多APM(如Elastic APM和SkyWalking APM等)针对ASP.NET Core应用的客户端都是利用这种方式收集请求调用链信息的。

ILogger日志

为了确定什么样的信息会被作为诊断日志记录下来,下面介绍一个简单的实例,将HostingApplication对象写入的诊断日志输出到控制台上。前面提及,HostingApplication对象会将相同的诊断信息以3种不同的方式进行记录,其中包含日志系统,所以我们可以通过注册对应ILoggerProvider对象的方式将日志内容写入对应的输出渠道。

整个演示实例如下面的代码片段所示:首先通过调用IWebHostBuilder接口的ConfigureLogging方法注册一个ConsoleLoggerProvider对象,并开启针对日志范围的支持。我们调用IApplicationBuilder接口的Run扩展方法注册了一个中间件,该中间件在处理请求时会利用表示当前请求上下文的HttpContext对象得到与之绑定的IServiceProvider对象,并进一步从中提取出用于发送日志事件的ILogger<Program>对象,我们利用它写入一条Information等级的日志。如果请求路径为“/error”,那么该中间件会抛出一个InvalidOperationException类型的异常。

public class Program {     public static void Main()     {         Host.CreateDefaultBuilder()             .ConfigureLogging(builder => builder.AddConsole(options => options.IncludeScopes = true))             .ConfigureWebHostDefaults(builder => builder                 .Configure(app => app.Run(context =>                 {                     var logger = context.RequestServices.GetRequiredService<ILogger<Program>>();                     logger.LogInformation($"Log for event Foobar");                     if (context.Request.Path == new PathString("/error"))                     {                         throw new InvalidOperationException("Manually throw exception.");                     }                     return Task.CompletedTask;                 })))             .Build()             .Run();     } }

在启动程序之后,我们利用浏览器采用不同的路径(“/foobar”和“/error”)向应用发送了两次请求,演示程序的控制台上呈现的输出结果如下图所示。由于我们开启了日志范围的支持,所以被ConsoleLogger记录下来的日志都会携带日志范围的信息。日志范围的唯一标识被称为请求ID(Request ID),它由当前的连接ID和一个序列号组成。从图13-4可以看出,两次请求的ID分别是“0HLO4ON65ALGG:00000001”和“0HLO4ON65ALGG:00000002”。由于采用的是长连接,并且两次请求共享同一个连接,所以它们具有相同的连接ID(“0HLO4ON65ALGG”)。同一连接的多次请求将一个自增的序列号(“00000001”和“00000002”)作为唯一标识。

ASP.NET Core管道详解[3]: Pipeline = IServer + IHttpApplication

除了用于唯一表示每个请求的请求ID,日志范围承载的信息还包括请求指向的路径,这也可以从图13-4所示的输出接口看出来。另外,上述请求ID实际上对应HttpContext类型的TraceIdentifier属性。如果需要进行跨应用的调用链跟踪,所有相关日志就可以通过共享TraceIdentifier属性构建整个调用链。

public abstract class HttpContext {      public abstract string  TraceIdentifier { get; set; }      ... }

对于两次采用不同路径的请求,控制台共捕获了7条日志,其中类别为App.Program的日志是应用程序自行写入的,HostingApplication写入日志的类别为“Microsoft.AspNetCore.Hosting.Diagnostics”。对于第一次请求的3条日志消息,第一条是在HostingApplication开始处理请求时写入的,我们利用这条日志获知请求的HTTP版本(HTTP/1.1)、HTTP方法(GET)和请求URL。对于包含主体内容的请求,请求主体内容的媒体类型(Content-Type)和大小(Content-Length)也会一并记录下来。当HostingApplication对象处理完请求后会写入第三条日志,日志承载的信息包括请求处理耗时(67.877 6毫秒)和响应状态码(200)。如果响应具有主体内容,对应的媒体类型同样会被记录下来。

对于第二次请求,由于我们人为抛出了一个异常,所以异常的信息被写入日志。但是如果足够仔细,就会发现这条等级为Error的日志并不是由HostingApplication对象写入的,而是作为服务器的KestrelServer写入的,因为该日志采用的类别为“Microsoft.AspNetCore.Server.Kestrel”。换句话说,HostingApplication对象利用ILogger记录的日志中并不包含应用的异常信息。

DiagnosticSource诊断日志

HostingApplication采用的3种日志形式还包括基于DiagnosticSource对象的诊断日志,所以我们可以通过注册诊断监听器来收集诊断信息。如果通过这种方式获取诊断信息,就需要预先知道诊断日志事件的名称和内容荷载的数据结构。通过查看HostingApplication类型的源代码,我们会发现它针对“开始请求”、“结束请求”和“未处理异常”这3类诊断日志事件对应的名称,具体如下。

  • 开始请求:Microsoft.AspNetCore.Hosting.BeginRequest。
  • 结束请求:Microsoft.AspNetCore.Hosting.EndRequest。
  • 未处理异常:Microsoft.AspNetCore.Hosting.UnhandledException。

至于针对诊断日志消息的内容荷载(Payload)的结构,上述3类诊断事件具有两个相同的成员,分别是表示当前请求上下文的HttpContext和通过一个Int64整数表示的当前时间戳,对应的数据成员的名称分别为httpContext和timestamp。对于未处理异常诊断事件,它承载的内容荷载还包括一个额外的成员,那就是表示抛出异常的Exception对象,对应的成员名称为exception。

既然我们已经知道事件的名称和诊断承载数据的成员,所以可以定义如下所示的DiagnosticCollector类型作为诊断监听器(需要针对NuGet包“Microsoft.Extensions.DiagnosticAdapter”的引用)。针对上述3类诊断事件,我们在DiagnosticCollector类型中定义了3个对应的方法,各个方法通过标注的DiagnosticNameAttribute特性设置了对应的诊断事件。我们根据诊断数据承载的结构定义了匹配的参数,所以DiagnosticSource对象写入诊断日志提供的诊断数据将自动绑定到对应的参数上。

public class DiagnosticCollector {     [DiagnosticName("Microsoft.AspNetCore.Hosting.BeginRequest")]     public void OnRequestStart(HttpContext httpContext, long timestamp)     {         var request = httpContext.Request;         Console.WriteLine($"nRequest starting {request.Protocol} {request.Method} { request.Scheme}://{request.Host}{request.PathBase}{request.Path}");         httpContext.Items["StartTimestamp"] = timestamp;     }      [DiagnosticName("Microsoft.AspNetCore.Hosting.EndRequest")]     public void OnRequestEnd(HttpContext httpContext, long timestamp)     {         var startTimestamp = long.Parse(httpContext.Items["StartTimestamp"].ToString());         var timestampToTicks = TimeSpan.TicksPerSecond / (double)Stopwatch.Frequency;         var elapsed = new TimeSpan((long)(timestampToTicks * (timestamp - startTimestamp)));         Console.WriteLine($"Request finished in {elapsed.TotalMilliseconds}ms { httpContext.Response.StatusCode}");     }     [DiagnosticName("Microsoft.AspNetCore.Hosting.UnhandledException")]     public void OnException(HttpContext httpContext, long timestamp, Exception exception)     {         OnRequestEnd(httpContext, timestamp);         Console.WriteLine($"{exception.Message}nType:{exception.GetType()}nStacktrace: { exception.StackTrace}");     } }

可以在针对“开始请求”诊断事件的OnRequestStart方法中输出当前请求的HTTP版本、HTTP方法和URL。为了能够计算整个请求处理的耗时,我们将当前时间戳保存在HttpContext上下文的Items集合中。在针对“结束请求”诊断事件的OnRequestEnd方法中,我们将这个时间戳从HttpContext上下文中提取出来,结合当前时间戳计算出请求处理耗时,该耗时和响应的状态码最终会被写入控制台。针对“未处理异常”诊断事件的OnException方法则在调用OnRequestEnd方法之后将异常的消息、类型和跟踪堆栈输出到控制台上。

如下面的代码片段所示,在注册的Startup类型中,我们在Configure方法注入DiagnosticListener服务,并调用它的SubscribeWithAdapter扩展方法将上述DiagnosticCollector对象注册为诊断日志的订阅者。与此同时,我们调用IApplicationBuilder接口的Run扩展方法注册了一个中间件,该中间件会在请求路径为“/error”的情况下抛出一个异常。

public class Program {     public static void Main()     {         Host.CreateDefaultBuilder()             .ConfigureLogging(builder => builder.ClearProviders())             .ConfigureWebHostDefaults(builder => builder.UseStartup<Startup>())             .Build()             .Run();     } }  public class Startup {     public void Configure(IApplicationBuilder app, DiagnosticListener listener)     {         listener.SubscribeWithAdapter(new DiagnosticCollector());         app.Run(context =>         {             if (context.Request.Path == new PathString("/error"))             {                 throw new InvalidOperationException("Manually throw exception.");             }             return Task.CompletedTask;         });     } }

待演示实例正常启动后,可以采用不同的路径(“/foobar”和“/error”)对应用程序发送两个请求,服务端控制台会以图13-5所示的形式输出DiagnosticCollector对象收集的诊断信息。如果我们试图创建一个针对ASP.NET Core的APM框架来监控请求处理的性能和出现的异常,可以采用这样的方案来收集原始的诊断信息。

ASP.NET Core管道详解[3]: Pipeline = IServer + IHttpApplication

EventSource事件日志

除了上述两种日志形式,HostingApplication对象针对每个请求的处理过程中还会利用EventSource对象发出相应的日志事件。除此之外,在启动和关闭应用程序(实际上就是启动和关闭IWebHost对象)时,同一个EventSource对象还会被使用。这个EventSource类型采用的名称为Microsoft.AspNetCore.Hosting,上述5个日志事件对应的名称如下。

  • 启动应用程序:HostStart。
  • 开始处理请求:RequestStart。
  • 请求处理结束:RequestStop。
  • 未处理异常:UnhandledException。
  • 关闭应用程序:HostStop。

我们可以通过如下所示的实例来演示如何利用创建的EventListener对象来监听上述5个日志事件。如下面的代码片段所示,我们定义了派生于抽象类EventListener的DiagnosticCollector。在启动应用前,我们创建了这个DiagnosticCollector对象,并通过注册其EventSourceCreated事件开启了针对目标名称为Microsoft.AspNetCore.Hosting的EventSource的监听。在注册的EventWritten事件中,我们将监听到的事件名称的负载内容输出到控制台上。

public class Program {     private sealed class DiagnosticCollector : EventListener {}     static void Main()     {         var listener = new DiagnosticCollector();         listener.EventSourceCreated +=(sender, args) =>         {             if (args.EventSource.Name == "Microsoft.AspNetCore.Hosting")             {                 listener.EnableEvents(args.EventSource, EventLevel.LogAlways);             }         };           listener.EventWritten += (sender, args) =>         {             Console.WriteLine(args.EventName);             for (int index = 0; index < args.PayloadNames.Count; index++)             {                 Console.WriteLine($"t{args.PayloadNames[index]} = {args.Payload[index]}");             }         };          Host.CreateDefaultBuilder()             .ConfigureLogging(builder => builder.ClearProviders())             .ConfigureWebHostDefaults(builder => builder                 .Configure(app => app.Run(context =>                 {                     if (context.Request.Path == new PathString("/error"))                     {                         throw new InvalidOperationException("Manually throw exception.");                     }                     return Task.CompletedTask;                 })))             .Build()             .Run();     } }

以命令行的形式启动这个演示程序后,从下图所示的输出结果可以看到名为HostStart的事件被发出。然后采用目标地址“http://localhost:5000/foobar”和“http:// http://localhost:5000/error”对应用程序发送两个请求,从输出结果可以看出,应用程序针对前者的处理过程会发出RequestStart事件和RequestStop事件,针对后者的处理则会因为抛出的异常发出额外的事件UnhandledException。输入“Ctrl+C”关闭应用后,名称为HostStop的事件被发出。对于通过EventSource发出的5个事件,只有RequestStart事件会将请求的HTTP方法(GET)和路径(“/foobar”和“/error”)作为负载内容,其他事件都不会携带任何负载内容。

ASP.NET Core管道详解[3]: Pipeline = IServer + IHttpApplication

请求处理管道[1]: 模拟管道实现
请求处理管道[2]: HttpContext本质论
请求处理管道[3]: Pipeline = IServer +  IHttpApplication<TContext
请求处理管道[4]: 中间件委托链
请求处理管道[5]: 应用承载[上篇
请求处理管道[6]: 应用承载[下篇]

赞(0) 打赏
未经允许不得转载:张拓的天空 » ASP.NET Core管道详解[3]: Pipeline = IServer + IHttpApplication
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

专业的IT技术经验分享 更专业 更方便

联系我们本站主机

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏

==========================
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 47916032 bytes) in /www/wwwroot/www.ztsky.cn/wp-content/plugins/wp-autopost-pro/wp-autopost-function.php on line 6673