asp.net core 3.x 通用主機是如何承載asp.net core的-上

一、前言

上一篇《asp.net core 3.x 通用主機原理及使用》扯了下3.x中的通用主機，剛好有哥們寫了篇《.NET Core 3.1和WorkerServices構建Windows服務》可以當做通用主機的案例來看。本篇主要聊下asp.net core 3.x中是如何使用通用主機來承載asp.net core本身的。

注：我是.net framework 4.x跳到.net core 3.x的，基本看源碼總結的，可能某些地方理解不到位，所以此文只作為參考別全信哈。

閱讀前提（參考老A的博客）：

• 了解配置系統和選項模式
• 了解通用主機，可以看看上一篇文章
• 如果能大概理解Builder模式和上下文模式就更好了

目錄：

• 通用主機回顧
• 通用主機是如何承載asp.net core的
• 核心類及使用要點
• 總結

二、回顧通用主機

2.1、IHost表示通用主機

微軟為我們提供了一個默認實現（Microsoft.Extensions.Hosting.Internal.Host），它內部主要包含：ioc容器(服務提供器)、生命周期事件處理器、日志記錄器、和IHostedService集合以及啟動和停止方法。

2.1.1、ioc服務提供器：

用來存儲各種服務對象，這個根容器是所有IHostedService共享的，各個IHostedService也可以創建主機的“范圍IOC容器”。ioc容器包含微軟為我們塞進去的，和我們自己塞進去的各種服務組件。在主機配置階段微軟會塞入：

• HostingEnvironment 主機環境，
  • EnvironmentName主機環境(是開發模式？還是生產模式？)
  • ApplicationName應用名稱
  • ContentRootPath主機的內容根路徑
  • ContentRootFileProvider內容提供器

• HostBuilderContext 主機創建過程中的上下文對象，在配置主機的多個步驟中傳遞數據。主要包含：HostingEnvironment和AppConfiguration應用配置對象
• AppConfiguration 應用配置對象，里面也包含主機配置對象
• IHostLifetime主機生命周期事件處理器
• IHostApplicationLifetime 應用生命周期事件處理器
• Internal.Host 作為默認主機

所以將來我們定義的類隨時可以注入這些對象，這些對象是在HostBuilder中賦值的，請往下看

2.1.2、生命周期事件處理器

將來主機啟動/停止時會觸發回調相應的幾個方法，比如：主機啟動了 應用啟動了  應用停止了，主機停止了。我們可以自定義一個事件處理器加入到ioc容器中來實現生命周期事件的訂閱。

2.1.3、IHostedService集合

一個IHostedService的實現類就是一個應用。asp.net core本身就是一個應用。

2.1.4、啟動流程

觸發相應的生命周期事件、遍歷啟動所有IHostedService

2.2、HostBuilder表示主機構造器

它負責主機的配置和生成。它定義了幾個委托集合，並提供相應的方法允許我們的代碼向集合中加入自己的委托，這些委托主要是用來：

• 向ioc容器注冊服務；
• 設置主機和應用配置對象的數據源；
• 配置容器本身（比如替換成別的依賴注入框架）；

將來在調用Build生成最終的主機時會：

• 創建主機配置生成器ConfigurationBuilder，然后回調我們的代碼提供的委托對配置對象的數據源進行設置，最終通過配置對象生成器.Build生成配置對象
• 創建HostingEnvironment（含義上面有說），默認用配置對象進行賦值，然后回調我們的代碼提供的委托進一步設置主機環境對象
• 初始化BuilderContext（含義上面有說）
• 初始化應用配置生成器，套路給主機配置一樣
• 初始化IOC容器，
  • 先把上面說的對象丟入容器中，
  • 注冊默認主機， Internal.Host 
  • 注冊選項模式需要的幾個服務，
  • 注冊日志系統需要的服務
  • 然后回調我們的委托，我們的委托可以注入各種主機需要的服務
  • 配置ioc容器本身，我們對微軟提供的ioc進行配置，或干脆替換為第三方依賴注入框架
• 嘴周從容器中解析得到主機

2.3、Host.CreateDefaultBuilder進一步簡化主機的配置和創建

• 創建HostBuilder
• 設置內容根為當前應用程序根目錄
• 將以"DOTNET_"的環境變量和命令行參數（如果有）作為“主機配置”的數據源
• 以以下數據作為“應用配置”的數據源
  • json文件appsettings.json和appsettings.{env.EnvironmentName}.json
  • 如果是開發模式，則添加一個特殊的json文件作為數據源，這個文件存儲如：賬號 密碼 數據庫連接字符串等比較機密的信息（文件查找路徑有點復雜，后期補充）
  • 添加環境變量作為配置源（沒細看，也許是整個系統的環境變量）
  • 嘗試添加命令行參數配置源
• 添加日志記錄系統需要的服務以及相關的配置
• 使用默認的ServiceProvider，當是開發模式時：在創建對象階段開啟依賴注入范圍驗證

以上為通用主機的大致內容，先有個印象，將來需要擴展時在研究源碼

三、通用主機是如何承載asp.net core的

asp.net core 3.x開始直接使用通用主機，主要思路是對通用主機做跟web相關配置（添加跟web相關的配置源和注冊服務），關鍵是會將GenericWebHostService注冊到ioc容器中。對於通用主機來說所謂的應用就是一個實現了IHostedService的類。GenericWebHostService就是這樣一個類，它就基本代表了asp.net core。對於通用主機來說asp.net core不過是一個應用而已。將來通用主機啟動時自然是啟動GenericWebHostService

注：GenericWebHostService會在啟動時創建ApplicationBuilder，然后對其進行配置（中間件管道），然后生成一個Application，最后拿到配置好的IServer（如KestrlServer）然后傳入Application並啟動它，Server開始監聽http請求，后續請求抵達時由Application對象負責將請求傳入中間件管道*（大致這么個流程，還沒詳細去看GenericWebHostService源碼）

先來看個圖：

 核心任務是：

1. 創建GenericWebHostBuilder，它是對通用主機構建器HostBuilder的一個包裝，提供跟web相關的配置源的設置和服務的注冊。構造函數中會做些初始化，默認配置
2. 通過靜態方法Host.ConfigureWebDefaults對GenericWebHostBuilder做進一步的默認配置
3. 調用用戶代碼(我們自己寫的)對GenericWebHostBuilder做進一步配置

所以文章后面部分我們將這個用來承載asp.net core的通用主機稱為“Web主機”，把通用主機配置器HostBuilder的包裝類GenericWebHostBuilder稱為“Web主機配置器”

四、GenericWebHostBuilder

它包裝了HostBuilder，所以可以把它理解為一個特殊的HostBuilder，特殊在它提供web相關的配置api，本質上還是向通用主機配置對象HostBuilder添加各種服務和配置源

4.1、GetSetting、UseSetting

GenericWebHostBuilder有個IConfiguration類型的屬性，可以把它理解為跟web相關的配置對象，它會作為通用主機的配置源，由於通用主機的配置源又是應用配置的數據源，因此最后：應用配置對象 = 通用主機配置對象 + （web主機配置對象）GenericWebHostBuilder._config  + 應用配置對象;
_config在構造函數中被初始化，唯一數據源是以"ASPNETCORE_"為前綴的環境變量
另外配置對象還在ExecuteHostingStartups被使用到，后面會詳細講
GetSetting、UseSetting這倆方法分別從_config讀取和寫入配置，所以我們可以在配置主機時更方便的向配置中加入一些值，也可以替換一些值來影響一些組件的配置

所以我們可以在配置web主機時通過UseSetting來快速設置/替換某些配置值，也可以在任意能獲得GenericWebHostBuilder的地方調用GetSetting方便的獲取配置值

4.2、IWebHostEnvironment、WebHostOptions、WebHostBuilderContext

在web主機配置過程中的多個步驟中經常會使用到這幾個對象，我們對web主機進行配置時，提供的委托的參數也經常會攜帶者節參數，因此看看這幾個東西是啥。

IWebHostEnvironment
web主機環境相關，它還繼承IHostEnvironment，所以它包含以下內容：

• EnvironmentName 主機運行環境，是開發？生產？
• ApplicationName 應用名
• ContentRootPath 內容根，默認是應用程序所在目錄
• ContentRootFileProvider 內容根對應的文件提供器
• WebRootPath  web根，默認wwwroot，
• WebRootFileProvider web根對應的文件提供器

WebHostOptions
web主機選項對象，雖然是這個名字，但是並沒有應用選項模式，且它是internal修飾的，因此我們寫代碼通常不會訪問到它，但是它在GenericWebHostBuilder有些作用的
它內部包含根web相關的配置：

• ApplicationName：應用程序名
• PreventHostingStartup、HostingStartupAssemblies、HostingStartupExcludeAssemblies：插件/模塊相關屬性，參考《asp.net core 3.x 模塊化開發之HostingStartup》
• Environment：應用程序當前運行，是開發模式？是生產環境？
• StartupAssembly：啟動類Startup所在程序集
• WebRoot：web靜態資源目錄，通常對應那個wwwroot目錄
• ContentRootPath：內容根路徑，通常對應應用程序所在目錄，

WebHostBuilderContext
= IWebHostEnvironment + IConfiguration

private WebHostBuilderContext GetWebHostBuilderContext(HostBuilderContext context)
GenericWebHostBuilder通過這個方法來創建WebHostBuilderContext，web主機配置器內部多個方法都會調用此方法。此方法執行過程大致步驟如下：

• 使用主機配置器上下文的配置對象來創建一個WebHostOptions，所以WebHostOptions上面那些屬性都是通過配置來賦值的，由於HostBuilderContext的配置對象現在=主機配置對象 + 應用配置對象 + web主機配置對象，可想而知，我們可以通過多種途徑來配置WebHostOptions的屬性
• 創建WebHostBuilderContext
  • Configuration = context.Configuration,
  • HostingEnvironment = new HostingEnvironment()
• 通過HostingEnvironmentExtensions.Initialize對WebHostBuilderContext.HostingEnvironment進行初始化，其實就是將WebHostOptions中相應的屬性賦值上去
• 最后HostBuilderContext和WebHostOptions被存儲到HostBuilderContext.Properties緩存起來

所以我們平時可以通過多種途徑來配置內容根、web根、應用名、運行環境（開發？生成？）
也可以在配置web主機時的委托中來通過WebHostBuilderContext來訪問到這些屬性和對應的文件提供器
由於IHostingEnvironment會以單例注冊到容器，因此我們將來可以直接注入HostingEnvironment或者web主機環境對象

4.3、public IWebHostBuilder Configure(Action<WebHostBuilderContext, IApplicationBuilder> configure)

調用此方法傳入一個委托，這個委托主要用來配置中間件管道，將來通用主機在啟動時會啟動代表asp.net core的GenericWebHostService，這時我們這個委托就會被調用。所以配置管道的代碼是在HostBuilder.Build().Run()這個Run階段執行，並不是在Build這步

這個方法跟UseStartup（下面會說）是沖突的，意思只能用其中一個，

要了解這個方法的原理，得先說說GenericWebHostServiceOptions，它是一個選項對象，看定義：

namespace Microsoft.AspNetCore.Hosting{
    internal class GenericWebHostServiceOptions{
       public Action<IApplicationBuilder> ConfigureApplication { get; set; }
       public WebHostOptions WebHostOptions { get; set; }
       public AggregateException HostingStartupExceptions { get; set; }
    }
}

此對象應用了選項模式，（第5行）ConfigureApplication其實就代表了那個用來配置中間件管道的委托

public IWebHostBuilder Configure(Action<WebHostBuilderContext, IApplicationBuilder> configure){
            _builder.ConfigureServices((context, services) => {
                services.Configure<GenericWebHostServiceOptions>(options => {
                    var webhostBuilderContext = GetWebHostBuilderContext(context);
                    options.ConfigureApplication = app => configure(webhostBuilderContext, app);
                });
            });

            return this;
        }

所以無論是Startup中的Configre方法，還是這里傳入的委托，最終都會以一個委托的形式賦值到GenericWebHostServiceOptions.ConfigureApplication屬性上，而這個委托將來在主機啟動階段被調用，最終實現允許用戶配置中間件管道的目的

為什么要提供兩種配置中間件管道的方式呢？因為直接在Program.main里配置更簡單，但是封裝性不好，通過單獨的Startup類更清晰。

所以我們配置中間件管道時除了可以在Startup.Configre中配置，也可以直接在Program.main里配置主機時通過GenericWebHostBuilder.Configure進行配置

 

未完待續....