ASP.NET Core的請求處理管道由一個服務器和一組中間件構成，但對于面向傳輸層的服務器來說，它其實沒有中間件的概念，當服務器接收到請求之后，會將該請求分發給一個處理器進行處理，對服務器而言，這個處理器就是一個HTTP應用，此應用通過IHttpApplication<TContext>介面來表示，由于服務器是通過IServer介面表示的，所以可以將ASP.NET Core框架的核心視為由IServer和IHttpApplication<TContext>物件組成的管道，[本文節選自《ASP.NET Core 3框架揭秘》第13章, 更多關于ASP.NET Core的文章請點這里]

目錄
一、服務器（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框架自身記錄的診斷日志并不關心，其實很多時候這些日志對糾錯排錯和性能監控提供了很有用的資訊，例如，假設需要創建一個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”）作為唯一標識，

除了用于唯一表示每個請求的請求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框架來監控請求處理的性能和出現的例外，可以采用這樣的方案來收集原始的診斷資訊，

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”）作為負載內容，其他事件都不會攜帶任何負載內容，

請求處理管道[1]: 模擬管道實作
請求處理管道[2]: HttpContext本質論
請求處理管道[3]: Pipeline = IServer + IHttpApplication<TContext
請求處理管道[4]: 中間件委托鏈
請求處理管道[5]: 應用承載[上篇
請求處理管道[6]: 應用承載[下篇]

轉載請註明出處，本文鏈接：https://www.uj5u.com/net/227002.html

標籤：.NET技术

上一篇：C# 程式禁止重復啟動