Какакой тип .NET приложения выбрать если нужна отказоустойчивость — обычное консольное, ASP.NET или Worker Service?

Question

[soundie]

Нужно создать приложение под платформу .NET 5 на виртуальном сервере (VPS) под Linux. Приложение простое: получать по HTTP примерно раз в секунду данные от датчиков, обработать их и отправить обычным HTTP GET-запросом обратно. Датчиков несколько, поэтому наверняка оно будет асинхронным (параллельным). Крайне желательно обеспечить отказоустойчивость всего этого дела, то есть даже если вдруг будет какой-то баг, то чтобы можно было легко закодить автоматический перезапуск.

Какой тип проекта будет оптимальным для такой задачи - обычное консольное, ASP.NET-приложение (WebApp или WebAPI?) или ещё заметил вроде по описанию подходящее Worker Service?

Мне нужно просто узнать в какую сторону копать, то есть понять что из шаблонов проекта под эту задачу лучше подойдёт.

Answer 1

[Андрей Голубков]

Вам может подойти 2 варианта: WebAPI либо Worker Service.

WebAPI предоставит вам конечную точку(узел) на который вы можете делать HTTP запросы из браузера, через curl и др. Т.е. инициатором какого-то действия будет запрос из вне. Но так как у вас процесс должен работать сам, без участия человека - этот вариант не особо подойдёт, но можно добавить планировщик, например - Quartz, который будет раз в указанное время запускать нужный вам код. А по HTTP вы можете периодически забирать статистику работы вашего приложения.

Worker Service - работает сам, можно сделать работу по расписанию или по другим условиям. Пишете функцию - она будет вызываться сама. Думаю, вам скорее нужен этот вариант.

Про отказоустойчивость: вы можете погуглить механизм Health Check, можно настроить автоматическую проверку жизни вашего сервиса и в случае обнаружения плохого состояния - автоматически его перезапустить.

Answer 2

[Василий Банников]

Нужно создать приложение под платформу .NET 5

Тогда уж уже 6. .NET 5 скоро end of life настигнет.

Крайне желательно обеспечить отказоустойчивость всего этого дела, то есть даже если вдруг будет какой-то баг, то чтобы можно было легко закодить автоматический перезапуск.

Перезапуск решается не на уровне приложения, а на уровне выше - через systemd/docker/k8s
Они умеют автоматически отслеживать, что твой сервис упал, и перезапускать обратно.
Если сервис может сломаться не падая полностью - смотри на Health checks (https://docs.microsoft.com/en-us/aspnet/core/host-...)

получать по HTTP

Ну тут очевидно - asp net бери.
Worker Service - это про некоторую работу, которая выполняется в фоне постоянно (например слушатель очереди логичнее делать на нём)
Просто консольное приложение - будет как aspnet, только хуже (если говорить про HttpListener/TcpListener), Придётся самому изобретать AppHost чтобы отслеживать состояние сервиса.

Только не надо это всё на GET-запросах делать) Семантически корректнее будет использовать POST.

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddHttpClient();
var app = builder.Build();

app.MapPost("/value", async ([FromBody] SensorReadings data, [FromServices] HttpClient httpClient) =>
{
    // Что-то делаем с полученными данными
    await httpClient.PostAsJsonAsync("https://example.com", data);
});

app.Run();

record SensorReadings(Guid SensorId, DateTimeOffset Timestamp, double Value);

Но в принципе, раз у тебя датчики - я бы посмотрел на сочетание mqtt и worker service