打造跨平台.NET Core后台服务-技术圈

续之前讲的在TopShelf上部署ASP.NET Core程序，作为后台服务运行，自从.NET Core 3.0出现以后，出现了自带的Generic Host，使得自托管服务变为可能。

这种方式和TopShelf方式一样，可以直接F5进行服务的调试，也为跨平台后台服务编写提供了一种新的方案。

创建服务

以VS2019为例，确保安装了.NET CORE 3.0以上的SDK，新建项目，在项目模板里面可以找到Worker Service模板，创建后，vs已经帮我们创建了Program.cs和Worker.cs两个文件。

在Program.cs中

using System;using System.Collections.Generic;using System.Linq;using System.Runtime.InteropServices;using System.Threading.Tasks;using Microsoft.Extensions.DependencyInjection;using Microsoft.Extensions.Hosting;
namespace WorkerServiceTest{public class Program    {public static void Main(string[] args)        {            CreateHostBuilder(args).Build().Run();        }
public static IHostBuilder CreateHostBuilder(string[] args) =>        Host.CreateDefaultBuilder(args)        .ConfigureServices((hostContext, services) =>        {            services.AddHostedService();        });        }    }}

可以发现，配置的方式和ASP.NET CORE的方式基本一样一样的，使用了内置的DI容器。那我们同样可以使用AddSingleton等方法进行其他逻辑的注入，也可以添加多个服务任务。

而Worker类已经写了好一个范例，其中有一个ExecuteAsync方法，可以直接执行后台任务。这个时候，直接F5就可以正常运行了，自带了一个显示当前时间的小程序。

跨平台支持

虽然程序可以正常执行，但是还不能正常部署为服务，需要依据平台添加对应的nuget包：

windows服务，需要添加：

Install-Package Microsoft.Extensions.Hosting.WindowsServices

Linux服务，需要添加：

Install-Package Microsoft.Extensions.Hosting.Systemd

如果想实现一套程序多处运行，那么直接同时安装两个package就可以了。接下来在CreateHostBuilder中，添加UseWindowsService()和UseSystemd()。

public static IHostBuilder CreateHostBuilder(string[] args){if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))    {return Host.CreateDefaultBuilder(args)            .ConfigureServices((hostContext, services) =>            {                services.AddHostedService();            }).UseWindowsService();    }else    {return Host.CreateDefaultBuilder(args)            .ConfigureServices((hostContext, services) =>            {                services.AddHostedService();            }).UseSystemd();    }}

这里使用到了.NET Core判断平台的一个函数：IsOSPlatform，可以判断是否在Windows平台运行，并进行分别调用。

部署

编译完成之后，找到生成的exe文件路径。

Windows下部署

管理员下运行cmd/powershell，执行

sc.exe create WorkerServiceTest binPath=C:\Users\source\repos\WorkerServiceTest\WorkerServiceTest\bin\Debug\netcoreapp3.1\WorkerServiceTest.exe

提示CreateService 成功即安装成功了，可以输入下面的命令运行服务。

sc.exe start WorkerServiceTest

sc.exe负责管理服务，具体配置启动方式和删除，可以查看命令的帮助。另外，友情提醒，如果是在powershell中，不要省略这个.exe，sc有别的用处...

Linux下部署

将整个程序文件夹传输到Linux文件夹下，我这边使用的是CentOS 8。新建一个运行服务的用户：

useradd -m dotnetuser -p dotnetpass

转到/etc/systemd/system文件夹，建立一个WorkerServiceTest.service的文件，这个WorkerServiceTest是你的服务名称。

输入以下内容并保存（systemd配置文件）：

[Unit]Description=WorkerServiceTest
[Service]ExecStart=dotnet /bin/dotnet/WorkerServiceTest.dllWorkingDirectory=/bin/dotnet/User=dotnetuserGroup=dotnetuserRestart=on-failureSyslogIdentifier=WorkerServiceTestPrivateTmp=true
[Install]WantedBy=multi-user.target

注意，你需要已经安装有dotnet runtime 3.0以上版本才可以。

可以使用以下命令进行安

yum install dotnet-runtime-3.1

接下来是配置服务和启动服务

#重载配置systemctl daemon-reload#设置服务自动启动systemctl enable WorkerServiceTest.service #运行服务systemctl start WorkerServiceTest.service#查询服务状态systemctl status WorkerServiceTest.service

然后可以发现，程序可以正常运行。

补充

作为服务，应该要提供一些状态用于外部监测，在Worker.cs中，Worker类可以重写StartAsync和StopAsync方法，提供服务启动和停止的信息，但是windows提供的服务失败后动作等功能都找不到配置的地方，可能这就是局限吧。

总结

一次编写，处处运行，对于后台服务也是如此，很简洁。但是暂时手上没有mac电脑，也不知道mac上面有没有对应的解决方案。可能TopShelf的mono模式可以支持吧。

比较TopShelf模式

总体讲，相较于TopShelf的方式，Service Worker方式有利有弊。

优点：

在相同的框架（.NET CORE 3.0+）下支持跨平台，支持linux服务的systemctl管理，topshelf在linux下需要mono。
配置方式和ASP.NET CORE相似度极高，基本上可以无缝切换。

缺点：

不支持TopSelf的自带命令install/start/uninstall等命令，依然需要sc进行部署，比较麻烦。
不支持windows的很多服务管理特性（比如Pause，依赖管理）。
只支持.NET CORE 3.0以后的框架，不支持.NET FRAMEWORK和早期版本的.NET CORE。

参考资料

https://devblogs.microsoft.com/aspnet/net-core-workers-as-windows-services/https://devblogs.microsoft.com/dotnet/net-core-and-systemd/https://docs.microsoft.com/en-us/dotnet/core/extensions/generic-hosthttps://dejanstojanovic.net/aspnet/2018/june/setting-up-net-core-servicedaemon-on-linux-os/https://dotnetcoretutorials.com/2019/12/07/creating-windows-services-in-net-core-part-3-the-net-core-worker-way/