ASP.NET Core 2.0 : 五.服務是如何加載並運行的, Kestrel、配置與環境
"跨平臺"後的ASP.Net Core是如何接收並處理請求的呢? 它的運行和處理機制和之前有什麽不同?
本章從"宏觀"到"微觀"地看一下它的結構以及不同時期都幹了些什麽.
ASP.NET Core 系列目錄
本章主要內容如下:
ASP.NET Core 的運行機制: "宏觀"的看一下Http請求的處理流程.
ASP.NET Core 的配置與運行: 2倍放大後的ASP.NET Core Application, Kestrel服務器、啟動與配置
ASP.NET Core 的環境變量.
ASP.NET Core 的運行機制
圖1
ASP.NET Core 的運行機制如上圖所示, 現在做一下詳細說明.
①Web Server: ASP.NET Core提供兩種服務器可用, 分別是Kestrel和HTTP.sys(Core 1.x 中被命名為 WebListener),
A. Kestrel是一個跨平臺的Web服務器;
B. HTTP.sys只能用在Windows系統中.
②Internet: 當需要部署在Internal Network 中並需要 Kestrel 中沒有的功能（如 Windows 身份驗證）時，可以選擇HTTP.sys。
③IIS、Apache、Nginx: Kestrel 可以單獨使用 ，也可以將其與反向代理服務器（如 IIS、Nginx 或 Apache）結合使用。 請求經這些服務器進行初步處理後轉發給Kestrel(即圖中虛線的可選流程).
大概的運行機制就是這樣, 那麽具體到ASP.NET Core Application是如何運行的呢? 我們將圖1中ASP.NET Core Application這個紅框框放大一下,看下一節.
ASP.NET Core 的啟動
看一下將圖1的ASP.NET Core Application放大後的樣子:
圖2
④Main方法, 程序的起點.
⑤創建並配置WebHostBuilder: 首先調用CreateDefaultBuilder( 如圖所示, 它是一系列配置的大綜合,下文做詳細介紹), 進行一系列配置之後, 調用 UseStartup<T>(),
指定⑩Startup為啟動配置文件. 在Startup中, 將進行兩個比較重要的工作, ⑧服務的依賴註入和⑨配置管道, 後文將對這一部分詳細的介紹.
⑥生成WebHostBuilder並進行了一系列配置之後, 通過這個WebHostBuilder來Build出一個IWebHost.
⑦調用IWebHost的Run方法使之開始運行.
ASP.NET Core 應用程序本質上是控制臺應用程序，所以它也是以一個我們熟悉的Main方法作為程序的起點.
打開Program.cs文件, 默認是如下代碼
public class Program
{
public static void Main(string[] args)
{
BuildWebHost(args).Run();
}
public static IWebHost BuildWebHost(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.Build();
}
定義了一個BuildWebHost方法, 在Main中調用它返回一個IWebHost, 並使這個IWebHost"Run起來". 再看BuildWebHost方法內部, 通過調用CreateDefaultBuilder
創建了一個IWebHostBuilder, 然後用這個Builder來Build出一個IWebHost.
簡單來說就是 創建IWebHostBuilder=>Builder=>Build()=>IWebHost=>Run().
WebHostBuilder的一系列配置
系統離不開各種各樣的配置, 比如常見的讀取配置文件, 指定日誌處理程序等, 我們詳細的看一下.
CreateDefaultBuilder
CreateDefaultBuilder, 顧名思義, 它是一個默認配置 . 如圖2所示, 它主要是調用了各種ConfigureXXX和UseXXX, 首先看一下它的源碼
1 public static IWebHostBuilder CreateDefaultBuilder(string[] args)
2 {
3 var builder = new WebHostBuilder()
4 .UseKestrel()
5 .UseContentRoot(Directory.GetCurrentDirectory())
6 .ConfigureAppConfiguration((hostingContext, config) =>
7 {
8 var env = hostingContext.HostingEnvironment;
9
10 config.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
11 .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: true);
12
13 if (env.IsDevelopment())
14 {
15 var appAssembly = Assembly.Load(new AssemblyName(env.ApplicationName));
16 if (appAssembly != null)
17 {
18 config.AddUserSecrets(appAssembly, optional: true);
19 }
20 }
21
22 config.AddEnvironmentVariables();
23
24 if (args != null)
25 {
26 config.AddCommandLine(args);
27 }
28 })
29 .ConfigureLogging((hostingContext, logging) =>
30 {
31 logging.AddConfiguration(hostingContext.Configuration.GetSection("Logging"));
32 logging.AddConsole();
33 logging.AddDebug();
34 })
35 .UseIISIntegration()
36 .UseDefaultServiceProvider((context, options) =>
37 {
38 options.ValidateScopes = context.HostingEnvironment.IsDevelopment();
39 });
40
41 return builder;
42 }
上面的源碼中我們看到它這些ConfigureXXX和UseXXX的過程, 而在Core 1.0版本中是沒有CreateDefaultBuilder這個方法的,
系統默認是逐個調用這些ConfigureXXX和UseXXX的,在Core 2.0中, 為了代碼簡潔和使用方便, 將這些常規情況下需要調用的方法放到了這個名為CreateDefaultBuilder的方法中.
一般情況下，調用CreateDefaultBuilder 執行其中的這些的默認配置足夠用了。但既然這是默認配置, 我們就可以根據自身情況自定義.
因為這些配置都是對 WebHostBuilder進行修改, 而修改後再次返回修改後的 WebHostBuilder, 所以在CreateDefaultBuilder不符合現實需求的情況下可以通過如下的方法進行自定義.
1)不調用CreateDefaultBuilder, 將上面講到的這些配置選擇性的執行, 甚至可以添加、替換裏面的某些配置, 如將UseKestrel改為UseHttpSys.
2)小幅改動, 即調用CreateDefaultBuilder之後再對其返回的WebHostBuilder調用自定義的其他配置方法. 例如可以再次調用 ConfigureAppConfiguration，從而添加更多的配置源.
下面來介紹一下這些ConfigureXXX和UseXXX.
A. UseKestrel
用於指定服務器使用 Kestrel, 若使用HttpSys, 需使用UseHttpSys。
Kestrel 是跨平臺 ASP.NET Core Web 服務器，它基於 libuv（一個跨平臺異步 I/O 庫）。 Kestrel 是 Web 服務器，默認包括在 ASP.NET Core 項目模板中。
Kestrel 支持以下功能：
- HTTPS
- 用於啟用 WebSocket 的不透明升級
- 用於獲得 Nginx 高性能的 Unix 套接字.
默認情況下，ASP.NET Core 項目模板使用的是 Kestrel。
我們可以再次調用UseKestrel來修改Kestrel的配置, 例如限制請求正文的最大值
public static IWebHost BuildWebHost(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.UseKestrel(options =>
{
options.Limits.MaxRequestBodySize = 10 * 1024;
})
.Build();
B. UseContentRoot
為應用程序指定根目錄。需註意這和 StaticFiles的根是不同的, 雖然默認情況下StaticFiles的根是以ContentRoot為依據 ([ContentRoot]/wwwroot)。
C. ConfigureAppConfiguration
讀取配置。如上代碼會讀取 appsettings.json 和 appsettings.{env.EnvironmentName}.json , env.EnvironmentName指的是環境, 例如Development. 當在Development環境的時候, 還會讀取用戶密鑰。
這部分在學習系統配置的時候詳細介紹.
D. ConfigureLogging
配置日誌處理程序,控制臺和調試日誌提供程序, 學習日誌的時候再詳講.
E. UseIISIntegration
將應用程序配置為在 IIS 中運行。上面已經講過, 這裏仍需要使用 UseKestrel, 而IIS 起到反向代理的作用，而 Kestrel 仍用作主機。
如果應用程序沒有使用 IIS 作為反向代理，那麽 UseIISIntegration 不會有任何效果。因此，即使應用程序在非 IIS 方案中運行，也可以安全調用這種方法。
F.UseDefaultServiceProvider
設置默認的依賴註入容器, 這部分在後面學習依賴註入的時候再詳講.
ASP.NET Core 的環境
在 ASP.NET Core 中，有個非常重要而且常用的東西叫環境變量, 它由 ASPNETCORE_ENVIRONMENT 環境變量指定。
我們可以根據需要將此變量設置為任意值，但通常使用的是值 Development、Staging 和 Production。它定義了當前應用程序的運行環境, 我們經常會根據這個變量來讓應用采用不同的處理方式.
在上面的例子中, 就有這樣的用法
if (env.IsDevelopment())
{
var appAssembly = Assembly.Load(new AssemblyName(env.ApplicationName));
if (appAssembly != null)
{
config.AddUserSecrets(appAssembly, optional: true);
}
}
_Layout View 中
<environment include="Development">
<link rel="stylesheet" href="~/lib/bootstrap/dist/css/bootstrap.css" />
<link rel="stylesheet" href="~/css/site.css" />
</environment>
因此，如果在run 之前將 ASPNETCORE_ENVIRONMENT 變量設置為 Development（或在 launchSettings.json 文件中設置此環境變量），
應用程序會在 Development 模式下運行，而不是 Production 模式（這是不設置任何變量時的默認模式）。
註意：在 Windows 和 macOS 上，環境變量和值不區分大小寫。Linux 環境變量和值區分大小寫。
小結
通過上面的內容大概對ASP.NET Core 2.0 的服務啟動、配置與運行, 運行環境等做了大概的了解, 其中涉及的部分內容如讀取配置、日誌等, 將在後期單獨介紹.
除了上述內容, ASP.NET Core留給我們作為擴展的地方主要放在了Startup文件中, 即圖2中的⑩Startup, 這裏進行了兩個比較重要的工作, ⑧服務的依賴註入和⑨配置管道,
下文我們將圖2的⑩Startup這個紅框框放大一些, 看看這裏都做了些什麽.
ASP.NET Core 系列目錄
原文地址：https://www.cnblogs.com/FlyLolo/p/ASPNETCore2_5.html
ASP.NET Core 2.0 : 五.服務是如何加載並運行的, Kestrel、配置與環境