一、前言

上一篇《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原始碼）

先來看個圖：

核心任務是：

創建GenericWebHostBuilder，它是對通用主機構建器HostBuilder的一個包裝，提供跟web相關的配置源的設定和服務的注冊，建構式中會做些初始化，默認配置
通過靜態方法Host.ConfigureWebDefaults對GenericWebHostBuilder做進一步的默認配置
呼叫用戶代碼(我們自己寫的)對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，它是一個選項物件，看定義：

 1 namespace Microsoft.AspNetCore.Hosting{ 3     internal class GenericWebHostServiceOptions{ 5        public Action<IApplicationBuilder> ConfigureApplication { get; set; } 6        public WebHostOptions WebHostOptions { get; set; } 8        public AggregateException HostingStartupExceptions { get; set; }10     }11 }

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

 1 public IWebHostBuilder Configure(Action<WebHostBuilderContext, IApplicationBuilder> configure){ 2             _builder.ConfigureServices((context, services) => { 3                 services.Configure<GenericWebHostServiceOptions>(options => { 4                     var webhostBuilderContext = GetWebHostBuilderContext(context); 5                     options.ConfigureApplication = app => configure(webhostBuilderContext, app); 6                 }); 7             }); 8  9             return this;10         }

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

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

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

未完待續....

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

標籤：.NET Core

上一篇：C#設計模式學習筆記：(21)訪問者模式

下一篇：記錄這兩年是如何一步一步轉型到.net core+k8s

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