在.NET 6.0中使用不同的托管模型

大家好，我是张飞洪，感谢您的阅读，我会不定期和你分享学习心得，希望我的文章能成为你成长路上的垫脚石，让我们一起精进。

本章是《定制ASP NET 6.0框架系列文章》的第六篇。在本章中，我们将讨论如何在ASP NET 6.0中自定义托管宿主。比如，托管选项和不同类型的托管，并了解一下IIS上的托管。限于篇幅，本章只是一个抛砖迎玉。

本章涵盖主题包括：

配置WebHostBuilder
配置Kestrel
配置HTTP.sys
IIS上的托管
在Linux上使用Nginx或Apache

本章涉及的服务端体系结构主题包括：

1 准备

代码准备

我们先创建一个空运用：

dotnet new web -n ExploreHosting -o ExploreHosting

然后使用VS Code打开该项目：

cd ExploreHosting code .

名词解释：

Hosting 有些地方叫宿主，有些地方叫托管，还有的地方叫承载，为了行文方便，我这里统一叫托管，我们知道他们是同一个意思就行。

2 配置WebHostBuilder

与上一章一样，这个小节我们将重点放在Program.cs上。WebHostBuilder是托管的重要类，它是我们配置和创建Web托管的地方。

以下代码是每个新创建的ASP.NET Core Web项目默认的代码：

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();

正如我们前面所了解的，默认框架已经帮我们配置了基本的内容，我们可以在在Azure或本地IIS上直接运行。显然以上的配置是最基础的，你完全可以覆写这些默认配置，包括托管的配置。

下面我们一起来看下Kestrel如何配置。

3 配置Kestrel

创建好WebHostBuilder后，我们可以使用各种方法来配置builder。这里，我们只举例一种，即使用Startup类。

在第4章：使用Kestrel配置和自定义HTTPS中我提到，Kestrel是托管应用程序的一种选项，它内置于.NET的Web服务器，基于.NET套接字实现。以前，它是在libuv之上构建的，libuv与Node.js使用相同的web服务器。Microsoft删除了对libuv的依赖，并基于.NET套接字创建了自己的Web服务器Kestrel。

在上一章中，我们使用UseKestrel方法来配置Kestrel选项：

.UseKestrel((host, options) => { // ... })

如上代码所示，第一个参数是WebHostBuilderContext，用于访问已配置的主机设置或配置本身。第二个参数是配置Kestrel的对象。

下面的代码片段显示的是我们在上一章中所做的托管配置需要监听的访问地址：

builder.WebHost.UseKestrel((host, options) => {

  var filename = host.Configuration.GetValue("AppSettings:certfilename", "");

  var password = host.Configuration.GetValue("AppSettings:certpassword", "");     

  options.Listen(IPAddress.Loopback, 5000);

  options.Listen(IPAddress.Loopback, 5001, listenOptions  => {

      listenOptions.UseHttps(filename, password);

  });

});

注意：在中添加一个using一个System.Net名称空间。

以上代码演示的是覆盖默认配置，您可以在其中传入URL，例如，使用launchSettings.json文件的applicationUrl属性或环境变量。

接下来，我们看看如何设置HTTP.sys。

4 配置HTTP.sys

这里介绍另一个托管选项HTTP.sys，一个不同的Web服务器的实现。它是一个非常成熟的库，默认嵌入到Windows中，可以用来托管ASP.NET Core应用程序：

.UseHttpSys(options => { // ... })

HTTP.sys不同于Kestrel，它不能在IIS中使用，因为对于IIS来说，它与ASP.NET Core模块无法兼容。

使用HTTP.sys而不是Kestrel的主要原因是：Windows身份验证不能在Kestrel中使用。另外，如果你想将自己的应用暴露到公网当中，当时你又不想使用IIS，也可以使用HTTP.sys。

多年来，IIS一直在HTTP.sys之上运行，这意味着使用UseHttpSys()相当于IIS内部使用相同的Web服务器实现。了解有关HTTP.sys的更多信息，可以访问该地址。

接下来，让我们看看使用IIS托管。

5 IIS上的托管

ASP.NET Core应用程序不应直接暴露于internet，即使它支持Kestrel或HTTP.sys。最好在两者之间有一个反向代理，或者至少有一个监视托管过程的服务。对于ASP.NET Core来说，IIS不仅仅是一个反向代理。它还负责托管进程，以防由于错误而中断。如果发生错误，IIS将重新启动进程。Nginx和IIS类似，主要是用在Linux上的反向代理，也负责托管过程。

假设你已经创建了一个新项目（删除Kestrel相关配置，对IIS不起作用）。

在IIS或Azure上托管ASP.NET Core Web之前，我们需要先编译并发布应用。

dotnet publish -o ..\published -r win-x64

编译后生成的文件可以部署在IIS上，另外它还生成了一个web.config，用于配置IIS或Azure的设置。

如果发布一个自包含的应用程序，它还包含运行时本身，即.NET Core运行时，但是交付时的大小增加了很多。而在IIS上只需创建一个新网站并将其映射到发布输出的文件夹即可。如果你需要考虑更改安全相关内容，或者带一些数据库连接等等，它会变得更加复杂，这不是一篇文章能搞定的。

6 在Linux上使用Nginx或Apache

在Linux上的发布ASP.NET Core应用和IIS上非常相似，因为没有了IIS这个反向代理，所以我们需要为反向代理做准备额外的步骤。一般我们会选择一个网络服务器，如Nginx或Apache作为反向代理，将流量转发给Kestrel和ASP.NET Core应用程序。

首先，我们需要应用接受两个特定的转发头，打开Startup.cs并在UseAuthentication中间件之前的Configure方法中添加以下行：

app.UseForwardedHeaders(new ForwardedHeadersOptions {

  ForwardedHeaders = ForwardedHeaders.XForwardedFor|ForwardedHeaders.XForwardedProto

});

另外，还需要添加来自反向代理的传入流量信任，为此需要向ConfigureServices方法添加以下行：

Builder.Services.Configure<ForwardedHeadersOptions>(options => {

  options.KnownProxies.Add(IPAddress.Parse("10.0.0.108"));

});

这里别忘了引入Microsoft.AspNetCore.HttpOverrides名称空间。

这里演示的是添加代理的IP地址，然后我们发布应用程序：

dotnet publish --configuration Release

将生成的文件复制到名为/var/www/yourapplication的文件夹中。你可以通过以下命令在Linux上进行快速测试：

dotnet <yourapplication.dll>

这里的yourapplication.dll是已编译的应用程序，包括路径。如果一切正常，我们就能够在http://localhost:5000/访问我们的站点。

如果访问一切正常，应用程序应该作为服务运行，我们需要在/etc/systemd/system/上创建一个服务文件，可以将文件命名为kestrel-yourapplication.service，在其中配置以下内容：

[Unit] Description=Example .NET Web API App running on Ubuntu

[Service] WorkingDirectory=/var/www/yourapplication ExecStart=/usr/bin/dotnet/var/www/yourapplication/yourapplication.dll

Restart=always

# Restart service after 10 seconds if the dotnet service crashes:

RestartSec=10 KillSignal=SIGINT SyslogIdentifier=dotnet-example User=www-data Environment=ASPNETCORE_ENVIRONMENT=Production Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false [Install] WantedBy=multi-user.target

1.确保配置里的路径指向编译生成的文件夹。

2.此文件配置了应用程序应在默认端口上作为服务运行。

3.监视应用程序并在其崩溃时重新启动。

4.定义了来自环境变量的配置（请参阅第1章“自定义日志记录”，了解如何使用环境变量配置应用程序）。

接下来，我们看下如何配置Nginx。

6.1配置Nginx

接下来，我们可以在Nginx上进行配置了：

server {

listen        80;

server_name   example.com *.example.com;

  location / {

    proxy_pass         http://localhost:5000;

    proxy_http_version 1.1;

    proxy_set_header   Upgrade $http_upgrade;

    proxy_set_header   Connection keep-alive;

    proxy_set_header   Host $host;

    proxy_cache_bypass $http_upgrade;

    proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;

    proxy_set_header   X-Forwarded-Proto $scheme;

  }

}

以上代码告诉Nginx将端口80上的调用转发给example.com及其子域http://localhost:5000，这是应用程序的默认地址。

6.2配置Apache

Apache配置看起来非常类似于Nginx方法，几乎做了相同的事情：

<VirtualHost *:*>

  RequestHeader set "X-Forwarded-Proto       expr=%{REQUEST_SCHEME}

</VirtualHost>

<VirtualHost *:80>

  ProxyPreserveHost On

  ProxyPass / http://127.0.0.1:5000/

  ProxyPassReverse / http://127.0.0.1:5000/

  ServerName www.example.com

  ServerAlias *.example.com

  ErrorLog ${APACHE_LOG_DIR}yourapplication-error.log

  CustomLog ${APACHE_LOG_DIR}yourapplication-access.log

  common

</VirtualHost>

以上就是Nginx和Apache的配置内容，更多细节需要你撸起袖子细细体验了。

回顾

ASP.NET Core和.NET CLI已经包含了在各种平台上运行的所有工具，并默认进行了设置，以便为Azure和IIS以及Nginx做好准备。

在.NET 6.0我们用的是WebHostBuilder，它创建了应用程序的托管环境。但是在之前的3.0版本中，我们用的是HostBuilder，它能够创建完全独立于任何Web上下文托管环境。

ASP.NET Core 6.0具有在程序后台运行驻守任务的能力，具体介绍，请期待我们的下一章《使用IHostedService和BackgroundService》。