Cześć
mamy w chmurze (Azure) serwis www (asp.net core) i obok niego potrzebuję podstawić usługę, która będzie działać w tle.
Jej zadaniem będzie ściągać z różnych stron dane i aktualizować wspólną bazę.
Jaki rodzaj projektu/rozwiązania byście rekomendowali?
Opieramy się na .Net stąd pytanie zadaję na tej grupie.
Przed erą chmury napisałem zwykłą aplikację konsolową (uruchamianą w Task Manager) ale od tego czasu zapewne wiele się pozmieniało.
Proszę o sugestie i dziękuje za pomoc.
J
Najprościej to WebJobs lub Azure Funtions.
Każda z nich ma inny model kosztowy, więc żeby wybrać właściwą trzeba trochę więcej informacji, takich jak czy ma działać cały czas, czy być czymś w rodzaju cron joba odpalanego raz na godzinę, czy jest wyzwalana przez zdarzenie z zewnątrz, ile danych przetwarza per iteracja/godzina/dzień, czy ma być publicznie dostępna, itd.
Na tę chwilę główne funkcje to:
Ruch docelowy będzie duży (liczba klientów w perspektywie roku to 5tys)
Komunikacja jednokierunkowa tj brak interakcji z zewnątrz.
Ile takie jedno przetworzenie danych trwa (pobranie ze źródła, transformacja, zapis w bazie docelowej)? Sekundy, minuty, godziny? W jakim interwale czasowym (co kwadrans, godzinę, raz na dzień)? Jaki jest średni rozmiar przetwarzanych danych w każdej iteracji? Kilobajty, megabajty, terabajty?
@markone_dev:
1000 operacji (odczyt, transformacja, zapis) po okolo 5 sek każda - odświeżanie co 30 minut, 5kB
5000 operacji po około 3 sek - co 12h, 1kB
To ja bym na ten moment poszedł w Web Jobs. W twoim przypadku Web Jobs będą darmowe bo są uruchamiane w ramach instancji App Service, a dokładniej jej planu cenowego. Przy Azure Functions trzeba by liczyć że każda operacja to jedno uruchomienie funkcji, a przy tej ilości operacji to szybko przekroczy się darmowy limit 1 000 000 uruchomień na miesiąc. Z dokumentacji:
The first 400,000 GB/s of execution and 1,000,000 executions are free.
Oczywiście można by jakoś kombinować żeby zejść z tej liczby wykonań funkcji, ale to nie o to chodzi, żeby na siłę wybierać usługę, która nie pasuje do przypadku użycia.
Minusem rozwiązania z Web Jobami jest to że gdy z jakiegoś powodu padnie App Service to pada nie tylko serwis www, ale też Web Job, więc trzeba to wziąć też pod uwagę. Jeżeli zależy ci na tym by pomimo awarii App Service z www ten job działał dalej to trzeba by go wynieść do osobnej instancji App Service i płacić za niego dodatkowo. Tutaj już trzeba by więc dobrze policzyć koszty, co by się bardziej opłacało czy nowy App Service czy Azure Functions.
Jeżeli to nie musi być oddzielna usługa to mozna rozważyć:
https://docs.microsoft.com/pl-pl/aspnet/core/fundamentals/host/hosted-services?view=aspnetcore-6.0&tabs=visual-studio
baroo napisał(a):
Jeżeli to nie musi być oddzielna usługa to mozna rozważyć:
https://docs.microsoft.com/pl-pl/aspnet/core/fundamentals/host/hosted-services?view=aspnetcore-6.0&tabs=visual-studio
Zgadza się niemniej trzeba pamiętać, o tym, że za każdym razem jak wdrażamy poprawkę do aplikacji czy joba to releasujemy całość. Przykładowo nie da się wgrać poprawki tylko do joba lub web apki. Trzeba zrobić release całości.
Z punktu widzenia wydajnościowego nie ma różnicy bo zarówno Web Jobs jak i Hosted Services będą współdzielić tą samą maszynę lub maszyny wirtualne (w ramach App Service)