.NET Core中Windows Service等效方案及云平台SCM替代方案咨询

Great question! .NET Core (and .NET 5+) has first-class, cross-platform support for exactly this kind of long-running queue-processing workload. The official replacement for traditional Windows Services here is the .NET Worker Service (previously called Background Service), built specifically for continuous background tasks like polling queues and handling messages.

Key Features That Meet Your Needs: #

• Auto-run on deployment: You can register a Worker Service as a Windows Service (using the Microsoft.Extensions.Hosting.WindowsServices NuGet package) or a Linux systemd service. For Windows, once installed, it’ll boot automatically with the system—just like your existing Windows Service.
• Graceful manual start/stop: The Worker Service integrates seamlessly with .NET’s hosting lifecycle, so graceful shutdowns are straightforward:
  1. In your Worker class, override the StopAsync(CancellationToken cancellationToken) method to finish processing the current message, halt new queue polling, and clean up resources (like closing queue clients or database connections).
  2. When you stop the service via Services.msc, sc stop command, or even Ctrl+C (for local testing), the host will trigger this method and wait for it to complete (you can configure the shutdown timeout if needed).

Quick Setup for Windows Service Deployment: #

1. Create a Worker Service project via CLI or Visual Studio:

   dotnet new worker -n QueueProcessorService
   

2. Add the Windows Services hosting package:

   dotnet add package Microsoft.Extensions.Hosting.WindowsServices
   

3. Update Program.cs to enable Windows Service mode:

   var host = Host.CreateDefaultBuilder(args)
       .ConfigureServices(services =>
       {
           services.AddHostedService<Worker>();
       })
       .UseWindowsService() // Enables running as a Windows Service
       .Build();
   
   await host.RunAsync();
   

4. Install the service using the sc command:

   sc create "QueueProcessorService" binPath="C:\Path\To\Your\QueueProcessorService.exe"
   

If you’re moving to the cloud, both Azure and AWS offer managed services to run your queue workload, plus built-in tools to control start/stop operations (just like Windows SCM).

Azure Options: #

• Azure WebJobs (Continuous): A direct fit for background queue tasks. Deploy your Worker Service as a continuous WebJob, which starts automatically on deployment. You can manage it via:
  • The Azure Portal to manually start/stop the job.
  • Azure CLI commands like az webjob continuous start --name <job-name> --resource-group <rg-name> --webapp-name <app-name> or az webjob continuous stop.
• Azure Functions (Continuous Trigger): For a serverless approach, a continuous trigger Function runs indefinitely to poll your queue. Start/stop the Function App via the Portal, Azure CLI, or PowerShell—Azure handles all infrastructure management.
• Azure Container Apps: If you containerize your Worker Service, deploy it here. It auto-starts on deployment, and you can scale or stop the service via the Portal or CLI. The platform also handles graceful shutdowns for containerized workloads.

Azure’s SCM equivalent is its Portal resource management interface plus CLI/PowerShell commands, which let you fully control the lifecycle of your services (start, stop, restart) with ease.

AWS Options: #

• AWS Elastic Beanstalk: Deploy your .NET Core Worker Service to an Elastic Beanstalk environment configured for background workers. It auto-starts on deployment, and you can restart or terminate the environment via the AWS Console or CLI:

  aws elasticbeanstalk restart-environment --environment-name <env-name>
  

• AWS ECS (Elastic Container Service): Containerize your Worker Service and run it as an ECS Service. The service auto-starts tasks, and you can scale the desired task count to 0 (stop) or back up via the Console or CLI:

  aws ecs update-service --cluster <cluster-name> --service <service-name> --desired-count 0
  

• AWS EC2: If you prefer VMs, install your Worker Service as a Windows Service on an EC2 Windows instance. You can use the native Windows SCM directly, or manage it remotely via AWS Systems Manager Run Command to trigger start/stop operations.

AWS’s SCM-like tools include the Console service management dashboards, AWS CLI, and AWS Systems Manager, all designed to control the lifecycle of your cloud-hosted workloads.

内容的提问来源于stack exchange，提问作者Jason J