"跨平臺"後的ASP.Net Core是如何接收並處理請求的呢? 它的運行和處理機制和之前有什麼不同? 本章從"巨集觀"到"微觀"地看一下它的結構以及不同時期都幹了些什麼. 本章主要內容如下: ASP.NET Core 的運行機制: "巨集觀"的看一下Http請求的處理流程. 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這個紅框框放大一些, 看看這裡都做了些什麼.
