2019年1月19日，微軟技術（蘇州）俱樂部成立，我受邀在成立大會上作了一個名爲《ASP.NET Core框架揭祕》的分享。在此次分享中，我按照ASP.NET Core自身的運行原理和設計思想創建了一個 “迷你版” 的ASP.NET Core框架，並且利用這個 “極簡” 的模擬框架闡述了ASP.NET Core框架最核心、最本質的東西。整個框架涉及到的核心代碼不會超過200行，涉及到7個核心的對象。由於ASP.NET Core 3.X採用了不同的應用承載方式，所以我們將這個模擬框架升級到3.x版本。[本篇內容節選自即將出版的《ASP.NET Core 3框架解密》，感興趣的朋友可以通過《“ASP.NET Core 3框架揭祕”讀者羣，歡迎加入》加入本書讀者羣，以便及時瞭解本書的動態。源代碼從這裏下載。]https://files.cnblogs.com/files/artech/mini-asp-net-core-framework.7z

一、中間件委託鏈

通過本篇文章，我將管道最核心的部分提取出來構建一個“迷你版”的ASP.NET Core框架。較之真正的ASP.NET Core框架，雖然重建的模擬框架要簡單很多，但是它們採用完全一致的設計。爲了能夠在真實框架中找到對應物，在定義接口或者類型時會採用真實的名稱，但是在API的定義上會做最大限度的簡化。

HttpContext

一個HttpContext對象表示針對當前請求的上下文。要理解HttpContext上下文的本質，需要從請求處理管道的層面來講。對於由一個服務器和多箇中間件構成的管道來說，面向傳輸層的服務器負責請求的監聽、接收和最終的響應，當它接收到客戶端發送的請求後，需要將請求分發給後續中間件進行處理。對於某個中間件來說，完成自身的請求處理任務之後，在大部分情況下需要將請求分發給後續的中間件。請求在服務器與中間件之間，以及在中間件之間的分發是通過共享上下文的方式實現的。

如下圖所示，當服務器接收到請求之後，會創建一個通過HttpContext表示的上下文對象，所有中間件都在這個上下文中完成針對請求的處理工作。那麼一個HttpContext對象究竟會攜帶什麼樣的上下文信息？一個HTTP事務（Transaction）具有非常清晰的界定，如果從服務器的角度來說就是始於請求的接收，而終於響應的回覆，所以請求和響應是兩個基本的要素，也是HttpContext承載的最核心的上下文信息。

我們可以將請求和響應理解爲一個Web應用的輸入與輸出，既然HttpContext上下文是針對請求和響應的封裝，那麼應用程序就可以利用這個上下文對象得到當前請求所有的輸入信息，也可以利用它完成我們所需的所有輸出工作。所以，我們爲ASP.NET Core模擬框架定義瞭如下這個極簡版本的HttpContext類型。

public class HttpListenerFeature : IHttpRequestFeature, IHttpResponseFeature
{
    private readonly HttpListenerContext _context;
    public HttpListenerFeature(HttpListenerContext context)=> _context = context;


    Uri IHttpRequestFeature.Url=> _context.Request.Url;
    NameValueCollection IHttpRequestFeature.Headers=> _context.Request.Headers;
    NameValueCollection IHttpResponseFeature.Headers=> _context.Response.Headers;
    Stream IHttpRequestFeature.Body=> _context.Request.InputStream;
    Stream IHttpResponseFeature.Body=> _context.Response.OutputStream;
    int IHttpResponseFeature.StatusCode
    {
        get => _context.Response.StatusCode;
        set => _context.Response.StatusCode = value;
    }
}

如上面的代碼片段所示，我們可以利用HttpRequest對象得到當前請求的地址、請求消息的報頭集合和主體內容。利用HttpResponse對象，我們不僅可以設置響應的狀態碼，還可以添加任意的響應報頭和寫入任意的主體內容。

中間件

HttpContext對象承載了所有與當前請求相關的上下文信息，應用程序針對請求的響應也利用它來完成，所以可以利用一個Action<HttpContext>類型的委託對象來表示針對請求的處理，我們姑且將它稱爲請求處理器（Handler）。但Action<HttpContext>僅僅是請求處理器針對“同步”編程模式的表現形式，對於面向Task的異步編程模式，這個處理器應該表示成類型爲Func<HttpContext,Task>的委託對象。

由於這個表示請求處理器的委託對象具有非常廣泛的應用，所以我們爲它專門定義瞭如下這個RequestDelegate委託類型，可以看出它就是對Func<HttpContext,Task>委託的表達。一個RequestDelegate對象表示的是請求處理器，那麼中間件在模型中應如何表達？

public delegate Task RequestDelegate(HttpContext context);

作爲請求處理管道核心組成部分的中間件可以表示成類型爲Func<RequestDelegate, RequestDelegate>的委託對象。換句話說，中間件的輸入與輸出都是一個RequestDelegate對象。我們可以這樣來理解：對於管道中的某個中間件（下圖所示的第一個中間件）來說，後續中間件組成的管道體現爲一個RequestDelegate對象，由於當前中間件在完成了自身的請求處理任務之後，往往需要將請求分發給後續中間件進行處理，所以它需要將後續中間件構成的RequestDelegate對象作爲輸入。

當代表當前中間件的委託對象執行之後，如果將它自己“納入”這個管道，那麼代表新管道的RequestDelegate對象就成爲該委託對象執行後的輸出結果，所以中間件自然就表示成輸入和輸出類型均爲RequestDelegate的Func<RequestDelegate, RequestDelegate>對象。

中間件管道的構建

從事軟件行業10多年來，筆者對架構設計越來越具有這樣的認識：好的設計一定是“簡單”的設計。所以在設計某個開發框架時筆者的目標是再簡單點。上面介紹的請求處理管道的設計就具有“簡單”的特質：Pipeline = Server + Middlewares。但是“再簡單點”其實是可以的，我們可以將多箇中間件組成一個單一的請求處理器。請求處理器可以通過RequestDelegate對象來表示，所以整個請求處理管道將具有更加簡單的表達：Pipeline = Server + RequestDelegate（見下圖12）。

表示中間件的Func<RequestDelegate, RequestDelegate>對象向表示請求處理器的RequestDelegate對象之間的轉換是通過IApplicationBuilder對象來完成的。從接口命名可以看出，IApplicationBuilder對象是用來構建“應用程序”（Application）的，實際上，由所有註冊中間件構建的RequestDelegate對象就是對應用程序的表達，因爲應用程序的意圖完全是由註冊的中間件達成的。

public interface IApplicationBuilder
{
    RequestDelegate Build();
    IApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware);
}

如上所示的代碼片段是模擬框架對IApplicationBuilder接口的簡化定義。它的Use方法用來註冊中間件，而Build方法則將所有的中間件按照註冊的順序組裝成一個RequestDelegate對象。如下所示的代碼片段中ApplicationBuilder類型是對該接口的默認實現。我們給出的代碼片段還體現了這樣一個細節：當我們將註冊的中間件轉換成一個表示請求處理器的RequestDelegate對象時，會在管道的尾端添加一個處理器用來響應一個狀態碼爲404的響應。這個細節意味着如果沒有註冊任何的中間件或者所有註冊的中間件都將請求分發給後續管道，那麼應用程序會回覆一個狀態碼爲404的響應。

public class ApplicationBuilder : IApplicationBuilder
{
    private readonly IList<Func<RequestDelegate, RequestDelegate>> _middlewares = new List<Func<RequestDelegate, RequestDelegate>>();


    public RequestDelegate Build()
    {
        RequestDelegate next = context =>
        {
            context.Response.StatusCode = 404;
            return Task.CompletedTask;
        };
        foreach (var middleware in _middlewares.Reverse())
        {
            next = middleware.Invoke(next);
        }
        return next;
    }


    public IApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware)
    {
        _middlewares.Add(middleware);
        return this;
    }
}

二、服務器

服務器在管道中的職責非常明確：負責HTTP請求的監聽、接收和最終的響應。具體來說，啓動後的服務器會綁定到指定的端口進行請求監聽。一旦有請求抵達，服務器會根據該請求創建代表請求上下文的HttpContext對象，並將該上下文分發給註冊的中間件進行處理。當中間件管道完成了針對請求的處理之後，服務器會將最終生成的響應回覆給客戶端。

IServer

在模擬的ASP.NET Core框架中，我們將服務器定義成一個極度簡化的IServer接口。在如下所示的代碼片段中，IServer接口具有唯一的StartAsync方法來啓動自身代表的服務器。服務器最終需要將接收的請求分發給註冊的中間件，而註冊的中間件最終會被IApplicationBuilder對象構建成一個代表請求處理器的RequestDelegate對象，StartAsync方法的參數handler代表的就是這樣一個對象。

public interface IServer
{
    Task StartAsync(RequestDelegate handler);
}

針對服務器的適配

面向應用層的HttpContext對象是對請求和響應的抽象與封裝，但是請求最初是由面向傳輸層的服務器接收的，最終的響應也會由服務器回覆給客戶端。所有ASP.NET Core應用使用的都是同一個HttpContext類型，但是它們可以註冊不同類型的服務器，應如何解決兩者之間的適配問題？計算機領域有這樣一句話：“任何問題都可以通過添加一個抽象層的方式來解決，如果解決不了，那就再加一層。”同一個HttpContext類型與不同服務器類型之間的適配問題自然也可以通過添加一個抽象層來解決。我們將定義在該抽象層的對象稱爲特性（Feature），特性可以視爲對HttpContext某個方面的抽象化描述。

如上圖所示，我們可以定義一系列特性接口來爲HttpContext提供某個方面的上下文信息，具體的服務器只需要實現這些Feature接口即可。對於所有用來定義特性的接口，最重要的是提供請求信息的IRequestFeature接口和完成響應的IResponseFeature接口。

下面闡述用來適配不同服務器類型的特性在代碼層面的定義。如下面的代碼片段所示，我們定義了一個IFeatureCollection接口來表示存放特性的集合。可以看出，這是一個以Type和Object作爲Key和Value的字典，Key代表註冊Feature所採用的類型，而Value代表Feature對象本身，也就是說，我們提供的特性最終是以對應類型（一般爲接口類型）進行註冊的。爲了便於編程，我們定義了Set<T>方法和Get<T>方法來設置與獲取特性對象。

public interface IFeatureCollection : IDictionary<Type, object> { }
public class FeatureCollection : Dictionary<Type, object>, IFeatureCollection { }
public static partial class Extensions
{
    public static T Get<T>(this IFeatureCollection features)  => features.TryGetValue(typeof(T), out var value) ? (T)value : default(T);
    public static IFeatureCollection Set<T>(this IFeatureCollection features, T feature)
    {
        features[typeof(T)] = feature;
        return features;
    }
}

最核心的兩種特性類型就是分別用來表示請求和響應的特性，我們可以採用如下兩個接口來表示。可以看出，IHttpRequestFeature接口和IHttpResponseFeature接口具有與抽象類型HttpRequest和HttpResponse完全一致的成員定義。

public interface IHttpRequestFeature
{
    Uri Url { get; }
    NameValueCollection Headers { get; }
    Stream Body { get; }
}
public interface IHttpResponseFeature
{
    int StatusCode { get; set; }
    NameValueCollection Headers { get; }
    Stream Body { get; }
}

我們在前面給出了用於描述請求上下文的HttpContext類型的成員定義，下面介紹其具體實現。如下面的代碼片段所示，表示請求和響應的HttpRequest與HttpResponse分別是由對應的特性（IHttpRequestFeature對象和IHttpResponseFeature對象）創建的。HttpContext對象本身則是通過一個表示特性集合的IFeatureCollection 對象來創建的，它會在初始化過程中從這個集合中提取出對應的特性來創建HttpRequest對象和HttpResponse對象。

public class HttpContext
{
    public HttpRequest Request { get; }
    public HttpResponse Response { get; }


    public HttpContext(IFeatureCollection features)
    {
        Request = new HttpRequest(features);
        Response = new HttpResponse(features);
    }
}


public class HttpRequest
{
    private readonly IHttpRequestFeature _feature;
    public Uri Url=> _feature.Url;
    public NameValueCollection Headers=> _feature.Headers;
    public Stream Body=> _feature.Body;
    public HttpRequest(IFeatureCollection features)=> _feature = features.Get<IHttpRequestFeature>();
}


public class HttpResponse
{
    private readonly IHttpResponseFeature _feature;


    public NameValueCollection Headers=> _feature.Headers;
    public Stream Body=> _feature.Body;
    public int StatusCode
    {
        get => _feature.StatusCode;
        set => _feature.StatusCode = value;
    }
    public HttpResponse(IFeatureCollection features)=> _feature = features.Get<IHttpResponseFeature>();
}

換句話說，我們利用HttpContext對象的Request屬性提取的請求信息最初來源於IHttpRequestFeature對象，利用它的Response屬性針對響應所做的任意操作最終都會作用到IHttpResponseFeature對象上。這兩個對象最初是由註冊的服務器提供的，這正是同一個ASP.NET Core應用可以自由地選擇不同服務器類型的根源所在。

HttpListenerServer

在對服務器的職責和它與HttpContext的適配原理有了清晰的認識之後，我們可以嘗試定義一個服務器。我們將接下來定義的服務器類型命名爲HttpListenerServer，因爲它對請求的監聽、接收和響應是由一個HttpListener對象來實現的。由於服務器接收到請求之後需要藉助“特性”的適配來構建統一的請求上下文（即HttpContext對象），這也是中間件的執行上下文，所以提供針對性的特性實現是自定義服務類型的關鍵所在。

對HttpListener有所瞭解的讀者都知道，當它在接收到請求之後同樣會創建一個HttpListenerContext對象表示請求上下文。如果使用HttpListener對象作爲ASP.NET Core應用的監聽器，就意味着不僅所有的請求信息會來源於這個HttpListenerContext對象，我們針對請求的響應最終也需要利用這個上下文對象來完成。HttpListenerServer對應特性所起的作用實際上就是在HttpListenerContext和HttpContext這兩種上下文之間搭建起一座如下圖所示的橋樑。

上圖中用來在HttpListenerContext和HttpContext這兩個上下文類型之間完成適配的特性類型被命名爲HttpListenerFeature。如下面的代碼片段所示，HttpListenerFeature類型同時實現了針對請求和響應的特性接口IHttpRequestFeature與IHttpResponseFeature。

public class HttpListenerFeature : IHttpRequestFeature, IHttpResponseFeature
{
    private readonly HttpListenerContext _context;
    public HttpListenerFeature(HttpListenerContext context) => _context = context;
    Uri IHttpRequestFeature.Url => _context.Request.Url;
    NameValueCollection IHttpRequestFeature.Headers => _context.Request.Headers;
    NameValueCollection IHttpResponseFeature.Headers => _context.Response.Headers;
    Stream IHttpRequestFeature.Body => _context.Request.InputStream;
    Stream IHttpResponseFeature.Body => _context.Response.OutputStream;
    int IHttpResponseFeature.StatusCode
    {
        get => _context.Response.StatusCode;
        set => _context.Response.StatusCode = value;
    }
}

創建HttpListenerFeature對象時需要提供一個HttpListenerContext對象，IHttpRequestFeature接口的實現成員所提供的請求信息全部來源於這個HttpListenerContext上下文，IHttpResponseFeature接口的實現成員針對響應的操作最終也轉移到這個HttpListenerContext上下文上。如下所示的代碼片段是針對HttpListener的服務器類型HttpListenerServer的完整定義。我們在創建HttpListenerServer對象的時候可以顯式提供一組監聽地址，如果沒有提供，監聽地址會默認設置“localhost:5000”。在實現的StartAsync方法中，我們啓動了在構造函數中創建的HttpListenerServer對象，並且在一個無限循環中通過調用其GetContextAsync方法實現了針對請求的監聽和接收。

public class HttpListenerServer : IServer
{
    private readonly HttpListener _httpListener;
    private readonly string[] _urls;
    public HttpListenerServer(params string[] urls)
    {
        _httpListener = new HttpListener();
        _urls = urls.Any() ? urls : new string[] { "http://localhost:5000/" };
    }


    public async Task StartAsync(RequestDelegate handler)
    {
        Array.ForEach(_urls, url => _httpListener.Prefixes.Add(url));
        _httpListener.Start();
        while (true)
        {
            var listenerContext = await _httpListener.GetContextAsync();
            var feature = new HttpListenerFeature(listenerContext);
            var features = new FeatureCollection()
                .Set<IHttpRequestFeature>(feature)
                .Set<IHttpResponseFeature>(feature);
            var httpContext = new HttpContext(features);
            await handler(httpContext);
            listenerContext.Response.Close();
        }
    }
}

當HttpListener監聽到抵達的請求後，我們會得到一個HttpListenerContext對象，此時只需要利用它創建一個HttpListenerFeature對象並且分別以IHttpRequestFeature接口和IHttpResponseFeature接口的形式註冊到創建的FeatureCollection集合上。我們最終利用這個FeatureCollection集合創建出代表請求上下文的HttpContext對象，當將它作爲參數調用由所有註冊中間件共同構建的RequestDelegate對象時，中間件管道將接管並處理該請求。

三、承載服務

到目前爲止，我們已經瞭解構成ASP.NET Core請求處理管道的兩個核心要素（服務器和中間件），現在我們的目標是利用.NET Core承載服務系統來承載這一管道。毫無疑問，還需要通過實現IHostedService接口來定義對應的承載服務，爲此我們定義了一個名爲WebHostedService的承載服務。(關於.NET Core承載服務系統，請參閱我的系列文章《服務承載系統》)

WebHostedService

由於服務器是整個請求處理管道的“龍頭”，所以從某種意義上來說，啓動一個ASP.NET Core應用就是爲啓動服務器，所以可以將服務的啓動在WebHostedService承載服務中實現。如下面的代碼片段所示，創建一個WebHostedService對象時，需要提供服務器對象和由所有註冊中間件構建的RequestDelegate對象。在實現的StartAsync方法中，我們只需要調用服務器對象的StartAsync方法啓動它即可。

public class WebHostedService : IHostedService
{
    private readonly IServer _server;
    private readonly RequestDelegate _handler;
    public WebHostedService(IServer server, RequestDelegate handler)
    {
        _server = server;
        _handler = handler;
    }


    public Task StartAsync(CancellationToken cancellationToken) => _server.StartAsync(_handler);
    public Task StopAsync(CancellationToken cancellationToken) => Task.CompletedTask;
}

到目前爲止，我們基本上已經完成了所有核心的工作，如果能夠將一個WebHostedService實例註冊到.NET Core的承載系統中，它就能夠幫助我們啓動一個ASP.NET Core應用。爲了使這個過程在編程上變得更加便利和“優雅”，我們定義了一個輔助的WebHostBuilder類型。

WebHostBuilder

要創建一個WebHostedService對象，必需顯式地提供一個表示服務器的IServer對象，以及由所有註冊中間件構建而成的RequestDelegate對象，WebHostBuilder提供了更加便利和“優雅”的服務器與中間件註冊方式。如下面的代碼片段所示，WebHostBuilder是對額外兩個Builder對象的封裝：一個是用來構建服務宿主的IHostBuilder對象，另一個是用來註冊中間件並最終幫助我們創建RequestDelegate對象的IApplicationBuilder對象。

public class WebHostBuilder
{
    public IHostBuilder HostBuilder { get; }
    public IApplicationBuilder ApplicationBuilder { get; }
    public WebHostBuilder(IHostBuilder hostBuilder, IApplicationBuilder applicationBuilder)
    {
        HostBuilder = hostBuilder;
        ApplicationBuilder = applicationBuilder;
    }
}

我們爲WebHostBuilder定義瞭如下兩個擴展方法：UseHttpListenerServer方法完成了針對自定義的服務器類型HttpListenerServer的註冊；Configure方法提供了一個Action<IApplication
Builder>類型的參數，利用該參數來註冊任意中間件。

public static partial class Extensions
{
    public static WebHostBuilder UseHttpListenerServer(this WebHostBuilder builder, params string[] urls)
    {
        builder.HostBuilder.ConfigureServices(svcs => svcs.AddSingleton<IServer>(new HttpListenerServer(urls)));
        return builder;
    }


    public static WebHostBuilder Configure(this WebHostBuilder builder, Action<IApplicationBuilder> configure)
    {
        configure?.Invoke(builder.ApplicationBuilder);
        return builder;
    }
}

代表ASP.NET Core應用的請求處理管道最終是利用承載服務WebHostedService註冊到.NET Core的承載系統中的，針對WebHostedService服務的創建和註冊體現在爲IHostBuilder接口定義的ConfigureWebHost擴展方法上。如下面的代碼片段所示，ConfigureWebHost方法定義了一個Action<WebHostBuilder>類型的參數，利用該參數可以註冊服務器、中間件及其他相關服務。

public static partial class Extensions
{
    public static IHostBuilder ConfigureWebHost(this IHostBuilder builder, Action<WebHostBuilder> configure)
    {
        var webHostBuilder = new WebHostBuilder(builder, new ApplicationBuilder());
        configure?.Invoke(webHostBuilder);
        builder.ConfigureServices(svcs => svcs.AddSingleton<IHostedService>(provider => {
            var server = provider.GetRequiredService<IServer>();
            var handler = webHostBuilder.ApplicationBuilder.Build();
            return new WebHostedService(server, handler);
        }));
        return builder;
    }
}

在ConfigureWebHost方法中，我們創建了一個ApplicationBuilder對象，並利用它和當前的IHostBuilder對象創建了一個WebHostBuilder對象，然後將這個WebHostBuilder對象作爲參數調用了指定的Action<WebHostBuilder>委託對象。在此之後，我們調用IHostBuilder接口的ConfigureServices方法在依賴注入框架中註冊了一個用於創建WebHostedService服務的工廠。對於由該工廠創建的WebHostedService對象來說，服務器來源於註冊的服務，而作爲請求處理器的RequestDelegate對象則由ApplicationBuilder對象根據註冊的中間件構建而成。

應用構建

到目前爲止，這個用來模擬ASP.NET Core請求處理管道的“迷你版”框架已經構建完成，下面嘗試在它上面開發一個簡單的應用。如下面的代碼片段所示，我們調用靜態類型Host的CreateDefaultBuilder方法創建了一個IHostBuilder對象，然後調用ConfigureWebHost方法並利用提供的Action<WebHostBuilder>對象註冊了HttpListenerServer服務器和3箇中間件。在調用Build方法構建出作爲服務宿主的IHost對象之後，我們調用其Run方法啓動所有承載的IHostedSerivce服務。

class Program
{
    static void Main()
    {
        Host.CreateDefaultBuilder()
            .ConfigureWebHost(builder => builder
                .UseHttpListenerServer()
                .Configure(app => app
                    .Use(FooMiddleware)
                    .Use(BarMiddleware)
                    .Use(BazMiddleware)))
            .Build()
            .Run();
    }


    public static RequestDelegate FooMiddleware(RequestDelegate next)
        => async context =>{
            await context.Response.WriteAsync("Foo=>");
            await next(context);
        };


    public static RequestDelegate BarMiddleware(RequestDelegate next)
        => async context =>{
            await context.Response.WriteAsync("Bar=>");
            await next(context);
        };


    public static RequestDelegate BazMiddleware(RequestDelegate next)
        => context => context.Response.WriteAsync("Baz");
}

由於中間件最終體現爲一個類型爲Func<RequestDelegate, RequestDelegate>的委託對象，所以可以利用與之匹配的方法來定義中間件。演示實例中定義的3箇中間件（FooMiddleware、BarMiddleware和BazMiddleware）對應的正是3個靜態方法，它們調用WriteAsync擴展方法在響應中寫了一段文字。

public static partial class Extensions
{
    public static Task WriteAsync(this HttpResponse response, string contents)
    {
        var buffer = Encoding.UTF8.GetBytes(contents);
        return response.Body.WriteAsync(buffer, 0, buffer.Length);
    }
}

應用啓動之後，如果利用瀏覽器嚮應用程序採用的默認監聽地址（“http://localhost:5000”）發送一個請求，得到的輸出結果如下圖所示。瀏覽器上呈現的文字正是註冊的3箇中間件寫入的。

200行代碼，7個對象——讓你瞭解ASP.NET Core框架的本質[3.x版]

一、中間件委託鏈

HttpContext

中間件

中間件管道的構建

二、服務器

IServer

針對服務器的適配

HttpListenerServer

三、承載服務

WebHostedService

WebHostBuilder

應用構建

SQL優化-20231016

.NET Core微服務開發選項

SQL Server 分頁+json分享

MySQL 常用優化指南，及大表優化思路都在這了！

分享一些支持多租戶的開源框架

分佈式高併發中，如何發揮gRPC的威力？來看看它的底層實現原理！

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結