Udostępnij za pośrednictwem

Zalecenia dotyczące tworzenia zadań w tle

  • Artykuł

Dotyczy tego zalecenia listy kontrolnej dotyczącej niezawodności platformy Azure Well-Architected Framework:

RE:07 Wzmocnienie odporności i możliwości odzyskiwania obciążenia przez zaimplementowanie środków samonaprawiania i samonaprawiania. Twórz możliwości w rozwiązaniu przy użyciu wzorców niezawodności opartych na infrastrukturze i wzorców projektowych opartych na oprogramowaniu w celu obsługi błędów składników i błędów przejściowych. Twórz możliwości w systemie w celu wykrywania błędów składników rozwiązania i automatycznego inicjowania akcji naprawczej, podczas gdy obciążenie nadal działa w pełni lub w ograniczonej funkcjonalności.

Powiązane przewodniki: Błędy | przejściowe Samozachowawnie

W tym przewodniku opisano zalecenia dotyczące tworzenia zadań w tle. Zadania w tle są uruchamiane automatycznie bez konieczności interakcji z użytkownikiem. Wiele aplikacji wymaga zadań w tle, które działają niezależnie od interfejsu użytkownika.

Niektóre przykłady zadań w tle obejmują zadania wsadowe, zadania wymagające intensywnego przetwarzania i długotrwałe procesy, takie jak przepływy pracy. Aplikacja uruchamia zadanie i przetwarza interakcyjne żądania od użytkowników. Jeśli na przykład aplikacja musi wygenerować miniatury obrazów przekazywanych przez użytkowników, można wykonać zadanie w tle w celu wygenerowania miniatury i zapisania jej w magazynie. Użytkownik nie musi czekać na ukończenie procesu. W innym przykładzie klient składa zamówienie, które inicjuje przepływ pracy w tle, który przetwarza zamówienie. Klient nadal przegląda aplikację internetową podczas uruchamiania zadania w tle. Po zakończeniu zadania w tle aktualizuje przechowywane dane zamówienia i wysyła wiadomość e-mail do klienta w celu potwierdzenia zamówienia.

Zadania w tle pomagają zminimalizować obciążenie interfejsu użytkownika aplikacji, co zwiększa dostępność i skraca interakcyjny czas odpowiedzi.

Kluczowe strategie projektowania

Aby wybrać zadanie, które ma być wyznaczone jako zadanie w tle, należy rozważyć, czy zadanie jest uruchamiane bez interakcji użytkownika i czy interfejs użytkownika musi czekać na ukończenie zadania. Zadania, które wymagają od użytkownika lub interfejsu użytkownika oczekiwania podczas ich uruchamiania, zazwyczaj nie są odpowiednimi zadaniami w tle.

Ocena zapotrzebowania na zadania w tle

Oto kilka przykładów zadań w tle:

  • Zadania intensywnie obciążające procesor CPU, na przykład obliczenia matematyczne lub analiza modeli strukturalnych.

  • Zadania intensywnie korzystające z operacji we/wy, takie jak uruchamianie serii transakcji magazynu lub plików indeksowania.

  • Zadania wsadowe, na przykład nocne aktualizacje danych lub zaplanowane przetwarzanie.

  • Długotrwałe przepływy pracy, takie jak realizacja zamówienia lub aprowizowanie usług i systemów.

  • Przetwarzanie danych poufnych, które przekazuje zadanie do bezpieczniejszej lokalizacji do przetwarzania. Na przykład przetwarzanie danych poufnych w aplikacji internetowej może być niewskazane. Zamiast tego możesz użyć wzorca, takiego jak wzorzec strażnika, aby przenieść dane do izolowanego procesu w tle, który ma dostęp do chronionego magazynu.

Wybieranie odpowiednich wyzwalaczy

Zainicjuj zadania w tle za pomocą:

  • Wyzwalacze sterowane zdarzeniami: zdarzenie, zazwyczaj akcja użytkownika lub krok w przepływie pracy, wyzwala zadanie.

  • Wyzwalacze sterowane harmonogramem: harmonogram oparty na czasomierzu wywołuje zadanie. Zadanie można zaplanować cyklicznie lub dla pojedynczego przebiegu.

Wyzwalacze sterowane zdarzeniami

Akcja wyzwala wywołanie sterowane zdarzeniami, które uruchamia zadanie w tle. Przykłady wyzwalaczy sterowanych zdarzeniami obejmują:

  • Interfejs użytkownika lub inne zadanie umieszcza komunikat w kolejce zgodnie z opisem w stylu architektury Web-Queue-Worker. Komunikat zawiera dane dotyczące wcześniej wykonanej akcji, takiej jak klient, który złożył zamówienie. Zadanie w tle monitoruje tę kolejkę i wykrywa przybycie nowego komunikatu. Odczytuje komunikat i używa danych komunikatu jako danych wejściowych zadania w tle. Ten wzorzec jest nazywany asynchroniczną komunikacją opartą na komunikatach.

  • Interfejs użytkownika lub inne zadanie zapisuje lub aktualizuje wartość przechowywaną w magazynie. Zadanie w tle monitoruje magazyn i wykrywa zmiany. Odczytuje dane i używa ich jako danych wejściowych dla zadania w tle.

  • Interfejs użytkownika lub inne zadanie wysyła żądanie do punktu końcowego, takiego jak identyfikator URI HTTPS lub interfejs API, który jest udostępniany jako usługa internetowa. W ramach żądania interfejs użytkownika lub zadanie przesyła dane wymagane przez zadanie w tle. Punkt końcowy lub usługa internetowa wywołuje zadanie w tle, które wykorzystuje te dane jako dane wejściowe.

Inne przykłady zadań odpowiednich do wywołania sterowanego zdarzeniami obejmują przetwarzanie obrazów, przepływy pracy, wysyłanie informacji do usług zdalnych, wysyłanie wiadomości e-mail i aprowizowanie nowych użytkowników w aplikacjach wielodostępnych.

Wyzwalacze sterowane harmonogramem

Czasomierz wyzwala wywołanie oparte na harmonogramie, które uruchamia zadanie w tle. Przykłady wyzwalaczy sterowanych harmonogramem obejmują:

  • Czasomierz uruchamiany lokalnie w aplikacji lub w ramach systemu operacyjnego aplikacji regularnie wywołuje zadanie w tle.

  • Czasomierz uruchamiany w innej aplikacji, takiej jak Azure Logic Apps, regularnie wysyła żądanie do interfejsu API lub usługi internetowej. Interfejs API lub usługa internetowa wywołuje zadanie w tle.

  • Oddzielny proces lub aplikacja uruchamia czasomierz, który wywołuje zadanie w tle po opóźnieniu czasu lub w określonym czasie.

Inne przykłady zadań, które są odpowiednie do wywołania opartego na harmonogramie, obejmują procedury przetwarzania wsadowego (takie jak aktualizowanie powiązanych list produktów dla klientów w oparciu o ich ostatnie zachowanie), rutynowe zadania przetwarzania danych (takie jak aktualizowanie indeksów lub generowanie skumulowanych wyników), analiza danych dla codziennych raportów, oczyszczanie przechowywania danych i kontrole spójności danych.

Jeśli używasz zadania opartego na harmonogramie, które musi być uruchamiane jako pojedyncze wystąpienie, zapoznaj się z następującymi zagadnieniami:

  • Jeśli wystąpienie obliczeniowe uruchamiające harmonogram, takie jak maszyna wirtualna korzystająca z zaplanowanych zadań systemu Windows, jest skalowane, uruchamiane jest wiele wystąpień harmonogramu. Wiele wystąpień harmonogramu może uruchomić wiele wystąpień zadania. Aby uzyskać więcej informacji, zobacz Co oznacza idempotentne w systemach oprogramowania?

  • Jeśli zadania są uruchamiane dłużej niż okres między zdarzeniami harmonogramu, harmonogram może uruchomić kolejne wystąpienie zadania, gdy poprzednie zadanie jest uruchamiane.

Zwracanie danych do obciążenia

Zadania w tle są uruchamiane asynchronicznie w osobnym procesie, a nawet w oddzielnej lokalizacji, od interfejsu użytkownika lub procesu, który wywołał zadanie w tle. Najlepiej, aby zadania w tle uruchamiały się i zapominały o operacjach. Ich postęp w czasie wykonywania nie ma wpływu na interfejs użytkownika ani proces wywoływania, co oznacza, że proces wywołujący nie czeka na ukończenie zadań. Interfejs użytkownika i proces wywołujący nie mogą wykryć, kiedy zadanie zakończy się.

Jeśli potrzebujesz zadania w tle do komunikowania się z zadaniem wywołującym, aby wskazać postęp lub ukończenie, musisz zaimplementować mechanizm. Oto kilka przykładów:

  • Zapisz wartość wskaźnika stanu w magazynie dostępnym dla interfejsu użytkownika lub zadania wywołującego, które może monitorować lub sprawdzać tę wartość. Inne dane zwracane przez zadanie w tle do obiektu wywołującego można umieścić w tym samym magazynie.

  • Ustanów kolejkę odpowiedzi monitora interfejsu użytkownika lub obiektu wywołującego. Zadanie w tle może wysyłać komunikaty do kolejki, które wskazują stan. Dane, które zadanie w tle powraca do obiektu wywołującego, można umieścić w komunikatach. W przypadku usługi Azure Service Bus użyj ReplyTo właściwości i CorrelationId , aby zaimplementować tę funkcję.

  • Uwidacznianie przez zadanie w tle interfejsu API lub punktu końcowego, do którego interfejs użytkownika lub element wywołujący może uzyskać dostęp w celu uzyskania informacji o stanie. Odpowiedź może zawierać dane zwracane przez zadanie w tle do obiektu wywołującego.

  • Skonfiguruj zadanie w tle, aby wywołać interfejs użytkownika lub obiekt wywołujący za pośrednictwem interfejsu API, aby wskazać stan w wstępnie zdefiniowanych punktach lub po zakończeniu. Zdarzenia wywoływane lokalnie lub mechanizm publikowania i subskrybowania można używać. Żądanie lub ładunek zdarzenia może zawierać dane zwracane przez zadanie w tle do obiektu wywołującego.

Partycjonowanie zadań w tle

Jeśli uwzględnisz zadania w tle w istniejącym wystąpieniu obliczeniowym, rozważ, jak te zmiany wpływają na atrybuty jakości wystąpienia obliczeniowego i zadania w tle. Rozważ te czynniki, aby zdecydować, czy przenieść zadania z istniejącym wystąpieniem obliczeniowym, czy oddzielić je od innego wystąpienia obliczeniowego:

  • Dostępność: zadania w tle mogą nie potrzebować takiego samego poziomu dostępności, jak inne części aplikacji, w szczególności interfejs użytkownika i części, które bezpośrednio obejmują interakcję użytkownika. Zadania w tle mogą mieć wyższą tolerancję opóźnienia, ponawiania prób połączenia oraz inne czynniki wpływające na dostępność, ponieważ operacje można umieścić w kolejce. Jednak musi być wystarczająca pojemność, aby zapobiec tworzeniu kopii zapasowych żądań, które mogą blokować kolejki i wpływać na całą aplikację.

  • Skalowalność: zadania w tle prawdopodobnie mają różne wymagania dotyczące skalowalności w porównaniu z interfejsem użytkownika i interaktywnymi częściami aplikacji. Może być konieczne skalowanie interfejsu użytkownika, aby sprostać szczytom zapotrzebowania. Zaległe zadania w tle mogą być uruchamiane w mniej zajętych czasach i z mniejszą liczbą wystąpień obliczeniowych.

  • Odporność: jeśli wystąpienie obliczeniowe hostujące tylko zadania w tle nie powiedzie się, może nie mieć krytycznego wpływu na całą aplikację. Żądania dotyczące tych zadań można kolejkować lub odkładać do momentu udostępnienia zadania. Jeśli wystąpienie obliczeniowe lub zadania podrzędne mogą zostać uruchomione ponownie w odpowiednim interwale, może to nie mieć wpływu na użytkowników aplikacji.

  • Zabezpieczenia: zadania w tle mogą mieć różne wymagania dotyczące zabezpieczeń lub ograniczenia w porównaniu z interfejsem użytkownika lub innymi częściami aplikacji. Użyj oddzielnego wystąpienia obliczeniowego, aby określić inne środowisko zabezpieczeń dla zadań podrzędnych. Aby zmaksymalizować bezpieczeństwo i separację, można również użyć wzorców, takich jak Gatekeeper, aby odizolować wystąpienia obliczeniowe w tle od interfejsu użytkownika.

  • Wydajność: wybierz typ wystąpienia obliczeniowego dla zadań w tle, które są w szczególności zgodne z wymaganiami dotyczącymi wydajności zadania. Możesz użyć tańszej opcji obliczeniowej, jeśli zadania nie wymagają tych samych możliwości przetwarzania co interfejs użytkownika. Możesz też użyć większego wystąpienia, jeśli zadania wymagają większej pojemności i zasobów.

  • Możliwość zarządzania: zadania w tle mogą mieć inny rytm programowania i wdrażania w porównaniu z głównym kodem aplikacji lub interfejsem użytkownika. Aby uprościć aktualizacje i przechowywanie wersji, wdróż zadania w tle w osobnym wystąpieniu obliczeniowym.

  • Koszt: w przypadku dodawania wystąpień obliczeniowych do uruchamiania zadań w tle koszty hostingu rosną. Starannie rozważ kompromis między większą pojemnością a dodatkowymi kosztami.

Aby uzyskać więcej informacji, zobacz Wzorzec wyboru lidera i wzorzec konkurencyjnych konsumentów.

Zapobieganie konfliktowi zasobów

Jeśli masz wiele wystąpień zadania w tle, mogą one konkurować o dostęp do zasobów i usług, takich jak bazy danych i magazyn. Ten współbieżny dostęp może spowodować rywalizację o zasoby, co może spowodować konflikty dostępności usługi i zaszkodzić integralności danych, które są w magazynie. Rozwiązywanie problemów z zasobami przy użyciu pesymistycznego podejścia blokującego. Takie podejście uniemożliwia konkurencyjnym wystąpieniom zadania jednoczesne uzyskiwanie dostępu do usługi lub uszkodzenie danych.

Innym podejściem do rozwiązywania konfliktów jest zdefiniowanie zadań w tle jako pojedynczego wystąpienia, tak aby tylko jedno wystąpienie było uruchamiane. Jednak takie podejście eliminuje korzyści z niezawodności i wydajności zapewniane przez konfigurację wielu wystąpień. Ta wada jest szczególnie prawdziwa, jeśli interfejs użytkownika dostarcza wystarczającą ilość pracy, aby zachować więcej niż jedno zadanie w tle zajęte.

Upewnij się, że zadanie w tle może być automatycznie uruchamiane ponownie i że ma wystarczającą pojemność do obsługi szczytów zapotrzebowania. Przydziel wystąpienie obliczeniowe z wystarczającą ilością zasobów, zaimplementuj mechanizm kolejkowania, który przechowuje żądania do uruchomienia w przypadku spadku zapotrzebowania lub użyj kombinacji tych technik.

Organizowanie wielu zadań

Zadania w tle mogą być złożone i wymagają uruchomienia wielu zadań. W tych scenariuszach wspólne jest podzielenie zadania na mniejsze dyskretne kroki lub podzadania, które mogą być uruchamiane przez wielu użytkowników. Zadania wieloetapowe są bardziej wydajne i bardziej elastyczne, ponieważ poszczególne kroki są często wielokrotnego użytku w wielu zadaniach. Można również łatwo dodawać, usuwać lub modyfikować kolejność kroków.

Może to być wyzwanie, aby koordynować wiele zadań i kroków, ale istnieją trzy typowe wzorce prowadzące do rozwiązania:

  • Dekompiluj zadanie do wielu kroków wielokrotnego użytku. Aplikacja może być wymagana do wykonywania różnych zadań o różnej złożoności na podstawie informacji, które przetwarza. Proste, ale nieelastyczne podejście do implementowania takiej aplikacji polega na wykonaniu tego przetwarzania jako modułu monolitycznego. Jednak takie podejście może zmniejszyć możliwości refaktoryzacji kodu, optymalizacji go lub ponownego użycia, jeśli aplikacja wymaga części tego samego przetwarzania w innym miejscu. Aby uzyskać więcej informacji, zobacz Wzorzec potoków i filtrów.

  • Zarządzanie orkiestracją kroków zadania. Aplikacja może wykonywać zadania składające się z wielu kroków, z których niektóre mogą wywoływać usługi zdalne lub uzyskiwać dostęp do zasobów zdalnych. Czasami poszczególne kroki są niezależne od siebie, ale są one orkiestrowane przez logikę aplikacji, która implementuje zadanie. Aby uzyskać więcej informacji, zobacz Wzorzec nadzorcy agenta harmonogramu.

  • Zarządzanie odzyskiwaniem kroków zadań, które kończą się niepowodzeniem. Jeśli co najmniej jeden krok zakończy się niepowodzeniem, aplikacja może wymagać cofnięcia pracy wykonanej przez serię kroków, co razem definiuje ostatecznie spójną operację. Aby uzyskać więcej informacji, zobacz Wzorzec transakcji wyrównywujących.

Uodpornianie zadań

Tworzenie odpornych zadań w tle w celu zapewnienia niezawodnych usług dla aplikacji. Podczas planowania i projektowania zadań w tle należy wziąć pod uwagę następujące kwestie:

  • Zadania w tle muszą bezpiecznie obsługiwać ponowne uruchomienia bez uszkodzenia danych lub wprowadzenia niespójności w aplikacji. W przypadku długotrwałych lub wieloetapowych zadań rozważ użycie punktów kontrolnych. Użyj punktów kontrolnych, aby zapisać stan zadań w magazynie trwałym lub jako komunikaty w kolejce. Można na przykład przechowywać informacje o stanie w komunikacie, który znajduje się w kolejce, i przyrostowo aktualizować te informacje o stanie przy użyciu postępu zadania. Zadanie można przetworzyć z ostatniego znanego punktu kontrolnego zamiast ponownego uruchamiania od początku.

    W przypadku kolejek usługi Service Bus użyj sesji komunikatów do tego celu. W przypadku sesji komunikatów zapisz i pobierz stan przetwarzania aplikacji przy użyciu metod SetState i GetState . Aby uzyskać więcej informacji na temat projektowania niezawodnych wieloetapowych procesów i przepływów pracy, zobacz Wzorzec nadzorcy agenta harmonogramu.

  • Jeśli używasz kolejek do komunikowania się z zadaniami w tle, kolejki mogą pełnić funkcję buforu do przechowywania żądań wysyłanych do zadań w czasie większego niż zwykle obciążenia aplikacji. Zadania mogą nadrobić zaległości w interfejsie użytkownika w mniej zajętych okresach, a ponowne uruchomienia nie blokują interfejsu użytkownika. Aby uzyskać więcej informacji, zobacz Wzorzec bilansowania obciążenia opartego na kolejce. Jeśli niektóre zadania są ważniejsze niż inne, rozważ zaimplementowanie wzorca kolejki priorytetów, aby upewnić się, że te zadania są uruchamiane jako pierwsze.

Wiadomości

Skonfiguruj zadania w tle inicjowane przez komunikaty lub przetwarzające komunikaty w celu obsługi niespójności, takich jak komunikaty wychodzące z kolejności, komunikaty, które wielokrotnie powodują błąd (komunikaty zatrute) i komunikaty dostarczane więcej niż raz. Rozważmy następujące zalecenia:

  • Czasami trzeba przetworzyć komunikaty w określonej kolejności, takie jak komunikaty, które zmieniają dane na podstawie istniejącej wartości danych, na przykład dodając wartość do istniejącej wartości. Wiadomości nie zawsze docierają w kolejności, w której zostały wysłane. Ponadto różne wystąpienia zadania w tle mogą przetwarzać komunikaty w innej kolejności ze względu na różne obciążenia poszczególnych wystąpień.

    W przypadku komunikatów, które muszą być przetwarzane w określonej kolejności, dołącz numer sekwencji, klucz lub inny wskaźnik, za pomocą którego zadania w tle mogą przetwarzać komunikaty w odpowiedniej kolejności. W przypadku usługi Service Bus użyj sesji komunikatów, aby zagwarantować poprawną kolejność dostarczania. Wydajniejsze jest zaprojektowanie procesu tak, aby kolejność komunikatów nie była ważna. Aby uzyskać więcej informacji, zobacz sekwencjonowanie komunikatów i znaczniki czasu.

  • Zazwyczaj zadanie w tle wyświetla komunikaty w kolejce, co tymczasowo ukrywa je przed innymi użytkownikami komunikatów. Gdy zadanie pomyślnie przetworzy komunikat, spowoduje usunięcie komunikatu. Jeśli zadanie w tle zakończy się niepowodzeniem podczas przetwarzania komunikatu, ten komunikat pojawi się ponownie w kolejce po upływie limitu czasu podglądu. Inne wystąpienie zadania przetwarza komunikat lub następny cykl przetwarzania oryginalnego wystąpienia przetwarza komunikat.

    Jeśli komunikat stale powoduje błąd użytkownika, blokuje zadanie, kolejkę i ostatecznie aplikację, gdy kolejka stanie się pełna. Ważne jest wykrywanie i usuwanie zatrutych komunikatów z kolejki. Jeśli używasz usługi Service Bus, automatycznie lub ręcznie przenosisz zatrute komunikaty do skojarzonej kolejki utraconych komunikatów.

  • Kolejki są co najmniej raz mechanizmami dostarczania, ale mogą dostarczać ten sam komunikat więcej niż raz. Jeśli zadanie w tle zakończy się niepowodzeniem po przetworzeniu komunikatu, ale przed usunięciem go z kolejki, komunikat będzie dostępny do ponownego przetworzenia.

    Zadania w tle powinny być idempotentne, co oznacza, że gdy zadanie przetwarza ten sam komunikat więcej niż raz, nie powoduje błędu ani niespójności w danych aplikacji. Niektóre operacje są naturalnie idempotentne, na przykład jeśli przechowywana wartość jest ustawiona na określoną nową wartość. Jednak niektóre operacje powodują niespójności, na przykład jeśli wartość jest dodawana do istniejącej przechowywanej wartości bez sprawdzania, czy przechowywana wartość jest nadal taka sama jak w przypadku pierwotnego wysłania komunikatu. Skonfiguruj kolejki usługi Service Bus, aby automatycznie usuwać zduplikowane komunikaty. Aby uzyskać więcej informacji, zobacz Idempotentne przetwarzanie komunikatów.

  • Niektóre systemy obsługi komunikatów, takie jak kolejki usługi Azure Storage i kolejki usługi Service Bus, obsługują właściwość dequeue count, która wskazuje, ile razy jest odczytywany komunikat z kolejki. Te dane są przydatne do obsługi powtarzających się komunikatów i komunikatów zatrutych. Aby uzyskać więcej informacji, zobacz Asynchroniczne wzorce podstaw obsługi komunikatów i Wzorce idempotentności.

Umożliwianie skalowania zadań

Zadania w tle muszą zapewnić wystarczającą wydajność, aby upewnić się, że nie blokują aplikacji ani nie opóźniają operacji, gdy system jest pod obciążeniem. Zazwyczaj wydajność poprawia się podczas skalowania wystąpień obliczeniowych hostujących zadania w tle. Podczas planowania i projektowania zadań w tle należy wziąć pod uwagę następujące kwestie związane ze skalowalnością i wydajnością:

  • Usługa Azure Virtual Machines i funkcja Web Apps usługi aplikacja systemu Azure mogą hostować wdrożenia. Obsługują automatyczne skalowanie, zarówno skalowanie w górę, jak i skalowanie w. Automatyczne skalowanie zależy od zapotrzebowania i obciążenia lub wstępnie zdefiniowanego harmonogramu. Użyj automatycznego skalowania, aby upewnić się, że aplikacja ma wystarczające możliwości wydajności, jednocześnie minimalizując koszty środowiska uruchomieniowego.

  • Niektóre zadania w tle mają inną funkcję wydajności w porównaniu z innymi częściami aplikacji, na przykład interfejsem użytkownika lub składnikami, takimi jak warstwa dostępu do danych. W tym scenariuszu hostowanie zadań w tle w oddzielnej usłudze obliczeniowej, dzięki czemu interfejs użytkownika i zadania w tle mogą być skalowane niezależnie w celu zarządzania obciążeniem. Jeśli wiele zadań w tle ma znacznie różne możliwości wydajności, podziel je i skaluj każdy typ niezależnie. Ta technika może zwiększyć koszty środowiska uruchomieniowego.

  • Aby zapobiec utracie wydajności pod obciążeniem, może być również konieczne skalowanie kolejek magazynu i innych zasobów, dzięki czemu pojedynczy punkt łańcucha przetwarzania nie powoduje wąskiego gardła. Rozważ inne ograniczenia, takie jak maksymalna przepływność magazynu i innych usług, na których polega aplikacja i zadania w tle.

  • Projektowanie zadań w tle na potrzeby skalowania. Na przykład zadania w tle muszą dynamicznie wykrywać liczbę używanych kolejek magazynu w celu monitorowania komunikatów lub wysyłania komunikatów do odpowiedniej kolejki.

  • Domyślnie usługa WebJob skaluje się wraz ze skojarzonym wystąpieniem usługi Web Apps. Jeśli jednak chcesz, aby zadanie WebJob było uruchamiane tylko jako pojedyncze wystąpienie, możesz utworzyć plik Settings.job zawierający dane { "is_singleton": true }JSON. Ta metoda wymusza na platformie Azure uruchomienie tylko jednego wystąpienia zadania WebJob, nawet jeśli istnieje wiele wystąpień skojarzonej aplikacji internetowej. Ta technika jest przydatna w przypadku zaplanowanych zadań, które muszą być uruchamiane tylko jako pojedyncze wystąpienie.

  • Zadania w tle mogą powodować wyzwania związane z synchronizacją danych i koordynacją procesów, zwłaszcza jeśli zadania w tle zależą od siebie lub innych źródeł danych. Na przykład zadania w tle mogą obsługiwać problemy ze spójnością danych, warunki wyścigu, zakleszczenia lub przekroczenia limitu czasu.

  • Zadania w tle mogą mieć wpływ na środowisko użytkownika, jeśli wyniki zadań w tle są prezentowane użytkownikowi. Na przykład zadania w tle mogą wymagać od użytkownika oczekiwania na powiadomienie, odświeżenia strony lub ręcznego sprawdzenia stanu zadania. Te zachowania mogą zwiększyć złożoność interakcji użytkownika i negatywnie wpłynąć na środowisko użytkownika.

Kompromis: Zadania w tle wprowadzają więcej składników i zależności do systemu, co może zwiększyć złożoność i koszty konserwacji rozwiązania. Na przykład zadania w tle mogą wymagać oddzielnej usługi kolejki, usługi procesu roboczego, usługi monitorowania i mechanizmu ponawiania prób.

Ułatwienia platformy Azure

W poniższych sekcjach opisano usługi platformy Azure, których można używać do hostowania, uruchamiania, konfigurowania i zarządzania zadaniami w tle.

Środowiska hosta

Istnieje kilka usług platformy Azure, które mogą hostować zadania w tle:

  • Web Apps i WebJobs: funkcja WebJobs usługi App Service umożliwia uruchamianie zadań niestandardowych opartych na różnych skryptach lub programach, które można uruchamiać w aplikacji internetowej.

  • Azure Functions: używaj aplikacji funkcji do zadań w tle, które nie są uruchamiane przez długi czas. Możesz również użyć aplikacji funkcji, jeśli hostujesz obciążenie w nie w pełni wykorzystanym planie usługi App Service.

  • Maszyny wirtualne: jeśli masz usługę systemu Windows lub chcesz użyć harmonogramu zadań systemu Windows, hostuj zadania w tle na dedykowanej maszynie wirtualnej.

  • Azure Batch: usługa Batch to usługa platformy, której można użyć do planowania prac intensywnie korzystających z obliczeń w celu uruchomienia na zarządzanej kolekcji maszyn wirtualnych. Umożliwia też automatyczne skalowanie zasobów obliczeniowych.

  • Azure Kubernetes Service (AKS): usługa AKS udostępnia zarządzane środowisko hostingu dla platformy Kubernetes na platformie Azure.

  • Azure Container Apps: za pomocą usługi Container Apps można tworzyć mikrousługi bezserwerowe oparte na kontenerach.

W poniższych sekcjach opisano zagadnienia dotyczące każdej z tych opcji, które pomogą Ci wybrać najlepszą opcję.

Web Apps i WebJobs

Funkcja Zadań WebJob umożliwia uruchamianie niestandardowych zadań jako zadań w tle w aplikacji internetowej. Zadanie WebJob działa jako ciągły proces w kontekście aplikacji internetowej. Usługa WebJob może również działać w odpowiedzi na zdarzenie wyzwalacza z usługi Logic Apps lub czynników zewnętrznych, takich jak zmiany w obiektach blob magazynu lub kolejkach komunikatów. Zadania WebJob można uruchamiać i zatrzymywać na żądanie oraz bezpiecznie zamykać. Jeśli ciągłe uruchamianie zadania WebJob zakończy się niepowodzeniem, zostanie ono automatycznie uruchomione ponownie. Można skonfigurować akcje ponawiania i błędów.

Podczas konfigurowania zadania WebJob:

  • Jeśli chcesz, aby zadanie odpowiadało na wyzwalacz sterowany zdarzeniami, skonfiguruj je do ciągłego uruchamiania. Skrypt lub program jest przechowywany w folderze o nazwie site/wwwroot/app_data/jobs/continuous.

  • Jeśli chcesz, aby zadanie odpowiadało na wyzwalacz sterowany harmonogramem, skonfiguruj je do uruchamiania zgodnie z harmonogramem. Skrypt lub program będzie przechowywany w folderze o nazwie site/wwwroot/app_data/jobs/triggered.

  • Jeśli podczas konfigurowania zadania zostanie wybrana opcja Uruchom na żądanie , uruchamia ten sam kod co opcja Uruchom zgodnie z harmonogramem po uruchomieniu zadania.

Usługa WebJob jest uruchamiana w piaskownicy aplikacji internetowej. Ma dostęp do zmiennych środowiskowych i może udostępniać informacje, takie jak parametry połączenia, za pomocą aplikacji internetowej. Usługa WebJob ma dostęp do unikatowego identyfikatora maszyny uruchamianej zadania WebJob. Nazwana parametry połączenia AzureWebJobsStorage zapewnia dostęp do kolejek, obiektów blob i tabel usługi Storage dla danych aplikacji. Zapewnia również dostęp do usługi Service Bus na potrzeby obsługi komunikatów i komunikacji. Nazwana parametry połączenia AzureWebJobsDashboard zapewnia dostęp do plików dziennika akcji zadania WebJob.

Zadania WebJob mają następujące cechy:

  • Zabezpieczenia: poświadczenia wdrożenia aplikacji internetowej zapewniają ochronę zadań WebJob.

  • Obsługiwane typy plików: Definiowanie zadań WebJob przy użyciu skryptów poleceń (.cmd), plików wsadowych (.bat), skryptów programu PowerShell (ps1), skryptów powłoki Bash (.sh), skryptów PHP (.php), skryptów języka Python (.py), kodu JavaScript (.js) i programów wykonywalnych (.exe i .jar).

  • Wdrożenie: skrypty i pliki wykonywalne można wdrażać przy użyciu witryny Azure Portal, programu Visual Studio lub zestawu SDK usługi WebJobs albo skopiować je bezpośrednio do następujących lokalizacji:

    • W przypadku wdrożenia wyzwalanego: site/wwwroot/app_data/jobs/triggered/<job name>

    • W przypadku ciągłego wdrażania: site/wwwroot/app_data/jobs/continuous/<job name>

  • Pliki dziennika: Console.Out są traktowane lub oznaczone jako INFO. Console.Error jest traktowany jako ERROR. Użyj portalu, aby uzyskać dostęp do informacji dotyczących monitorowania i diagnostyki. Pobierz pliki dziennika bezpośrednio z witryny internetowej. Pliki dziennika są zapisywane w następujących lokalizacjach:

    • W przypadku wdrożenia wyzwalanego: Vfs/data/jobs/triggered/<job name>

    • W przypadku ciągłego wdrażania: Vfs/data/jobs/continuous/<job name>

  • Konfiguracja: skonfiguruj zadania WebJob przy użyciu portalu, interfejsu API REST i programu PowerShell. Użyj pliku konfiguracji o nazwie settings.job, który znajduje się w tym samym katalogu głównym co skrypt zadania WebJob, aby udostępnić informacje o konfiguracji zadania WebJob. Na przykład:

    • { "stopping_wait_time": 60 }

    • { "is_singleton": true }

Zagadnienia dotyczące usługi Web Apps i zadań WebJob

  • Domyślnie zadania WebJob są skalowane wraz z aplikacją internetową. Aby skonfigurować zadania WebJob do uruchamiania w jednym wystąpieniu, ustaw is_singleton właściwość konfiguracji na truewartość . Zadania WebJob pojedynczego wystąpienia są przydatne w przypadku zadań, które nie mają być skalowane ani uruchamiane jako jednoczesne wiele wystąpień, takich jak ponowne indeksowanie lub analiza danych.

  • Aby zminimalizować wpływ zadań WebJob na wydajność aplikacji internetowej, utwórz puste wystąpienie aplikacji internetowej w nowym planie usługi App Service do hostowania długotrwałych lub intensywnie korzystających z zasobów zadań WebJob.

Azure Functions

Usługa Azure Functions jest podobna do zadań WebJob. Usługa Azure Functions jest bezserwerowa i najbardziej odpowiednia dla wyzwalaczy opartych na zdarzeniach uruchamianych przez krótki okres. Możesz również użyć usługi Azure Functions do uruchamiania zaplanowanych zadań za pośrednictwem wyzwalaczy czasomierza, jeśli skonfigurujesz funkcję do uruchamiania w określonych godzinach.

Usługa Azure Functions nie jest zalecana w przypadku dużych, długotrwałych zadań, ponieważ funkcja może powodować nieoczekiwane przekroczenia limitu czasu. Jednak w zależności od planu hostingu rozważ użycie funkcji dla wyzwalaczy opartych na harmonogramie.

Zagadnienia dotyczące usługi Azure Functions

Jeśli oczekujesz, że zadanie w tle będzie uruchamiane przez krótki czas w odpowiedzi na zdarzenie, rozważ uruchomienie zadania w planie zużycia. Środowisko uruchomieniowe można skonfigurować do maksymalnego czasu. Funkcja, która działa dłużej, kosztuje więcej. Zadania intensywnie korzystające z procesora CPU, które zużywają więcej pamięci, mogą być droższe. Jeśli używasz dodatkowych wyzwalaczy dla usług w ramach zadania, są one rozliczane oddzielnie.

Plan Premium jest odpowiedni, jeśli masz kilka zadań, które są krótkie, ale są one uruchamiane w sposób ciągły. Ten plan jest droższy, ponieważ potrzebuje więcej pamięci i procesora CPU. Z korzyścią można korzystać z innych funkcji, takich jak integracja z siecią wirtualną.

Dedykowany plan jest odpowiedni dla zadań w tle, jeśli obciążenie jest już uruchomione w ramach dedykowanego planu. Jeśli masz nie w pełni wykorzystywane maszyny wirtualne, możesz uruchomić dedykowany plan na tej samej maszynie wirtualnej i współdzielić koszty obliczeń.

Aby uzyskać więcej informacji, zobacz:

Virtual Machines

Zadania w tle można zaimplementować, aby nie były wdrażane w usłudze Web Apps. Można na przykład zaimplementować zadania przy użyciu usług systemu Windows, narzędzi innych firm lub programów wykonywalnych. Można również użyć programów napisanych dla środowiska uruchomieniowego innego niż środowisko hostujące aplikację. Możesz na przykład użyć programu systemu Unix lub Linux, który chcesz uruchomić z poziomu aplikacji systemu Windows lub .NET. Wybierz spośród kilku systemów operacyjnych dla maszyny wirtualnej platformy Azure i uruchom usługę lub plik wykonywalny na tej maszynie wirtualnej.

Aby uzyskać więcej informacji, zobacz:

Aby zainicjować zadanie w tle na oddzielnej maszynie wirtualnej, możesz:

  • Wyślij żądanie do punktu końcowego uwidacznianego przez zadanie w celu uruchomienia zadania na żądanie bezpośrednio z poziomu aplikacji. Żądanie przesyła dane wymagane przez zadanie. Punkt końcowy wywołuje zadanie.

  • Użyj harmonogramu lub czasomierza z wybranego systemu operacyjnego, aby skonfigurować zadanie do uruchomienia zgodnie z harmonogramem. Na przykład w systemie Windows można użyć harmonogramu zadań systemu Windows do uruchamiania skryptów i zadań. Jeśli na maszynie wirtualnej jest zainstalowany program SQL Server, uruchom skrypty i zadania za pomocą agenta programu SQL Server.

  • Użyj usługi Logic Apps, aby zainicjować zadanie przez dodanie komunikatu do kolejki monitorowanej przez zadanie lub wysyłając żądanie do interfejsu API uwidacznianego przez zadanie.

Aby uzyskać więcej informacji na temat inicjowania zadań w tle, zobacz poprzednią sekcję Wyzwalacze .

Zagadnienia dotyczące maszyn wirtualnych

Podczas wdrażania zadań w tle na maszynie wirtualnej platformy Azure należy wziąć pod uwagę następujące kwestie:

  • Hostowanie zadań w tle na oddzielnej maszynie wirtualnej platformy Azure w celu zapewnienia elastyczności i precyzyjnej kontroli nad inicjowaniem, wdrażaniem, planowaniem i alokacją zasobów. Jednak koszty środowiska uruchomieniowego zwiększają się, jeśli wdrażasz maszynę wirtualną wyłącznie na potrzeby zadań w tle.

  • Nie ma możliwości monitorowania zadań w portalu i nie ma możliwości automatycznego ponownego uruchamiania pod kątem zadań, które zakończyły się niepowodzeniem. Można jednak użyć poleceń cmdlet usługi Azure Resource Manager do monitorowania stanu maszyny wirtualnej i zarządzania nią. W węzłach obliczeniowych nie ma żadnych obiektów do kontrolowania procesów i wątków. Zazwyczaj w przypadku korzystania z maszyny wirtualnej należy zaimplementować mechanizm zbierający dane z instrumentacji w zadaniu, a także z systemu operacyjnego na maszynie wirtualnej. W tym celu można użyć pakietu administracyjnego programu System Center dla platformy Azure .

  • Rozważ utworzenie sond monitorowania uwidocznionych za pośrednictwem punktów końcowych HTTP. Możesz skonfigurować kod dla tych sond w celu przeprowadzania kontroli kondycji i zbierania informacji operacyjnych i statystyk. Sondy umożliwiają również sortowanie informacji o błędzie i zwracanie ich do aplikacji zarządzania.

Aby uzyskać więcej informacji, zobacz:

Batch

Rozważ usługę Batch , jeśli musisz uruchamiać duże, równoległe obciążenia obliczeń o wysokiej wydajności (HPC) na dziesiątkach, setkach lub tysiącach maszyn wirtualnych.

Usługa Batch umożliwia przygotowanie maszyn wirtualnych, przypisanie zadań do maszyn wirtualnych, uruchomienie zadań, monitorowanie postępu i automatyczne skalowanie maszyn wirtualnych w poziomie w odpowiedzi na obciążenie. Usługa Batch udostępnia również planowanie zadań i obsługuje maszyny wirtualne z systemem Linux i Windows.

Zagadnienia dotyczące usługi Batch

Usługa Batch jest odpowiednia dla obciążeń wewnętrznie równoległych. Za pomocą usługi Batch można wykonywać obliczenia równoległe z krokiem redukcji na końcu lub uruchamiać aplikacje interfejsu MPI (Message Passing Interface) na potrzeby zadań równoległych wymagających przekazywania komunikatów między węzłami.

Zadanie usługi Batch jest uruchamiane w puli węzłów lub maszyn wirtualnych. Pulę można przydzielić tylko w razie potrzeby, a następnie usunąć ją po zakończeniu zadania. Takie podejście maksymalizuje wykorzystanie, ponieważ węzły nie są bezczynne, ale zadanie musi czekać na przydzielenie węzłów. Alternatywnie można utworzyć pulę z wyprzedzeniem. Takie podejście minimalizuje czas potrzebny na uruchomienie zadania, ale może spowodować, że węzły znajdują się w stanie bezczynności.

Aby uzyskać więcej informacji, zobacz:

Azure Kubernetes Service

Użyj usługi AKS do zarządzania hostowanym środowiskiem Kubernetes, aby można było łatwo wdrażać aplikacje konteneryzowane i zarządzać nimi.

Kontenery są przydatne do uruchamiania zadań w tle. Oto niektóre korzyści:

  • Kontenery obsługują hosting o dużej gęstości. Można wyizolować zadanie w tle w kontenerze, umieszczając wiele kontenerów w każdej maszynie wirtualnej.

  • Orkiestrator kontenerów umożliwia wykonywanie wewnętrznego równoważenia obciążenia, konfigurowanie sieci wewnętrznej i wykonywanie innych zadań konfiguracyjnych.

  • Kontenery można uruchamiać i zatrzymywać zgodnie z potrzebami.

  • Usługa Azure Container Registry umożliwia rejestrowanie kontenerów w granicach platformy Azure w celu zapewnienia korzyści związanych z bezpieczeństwem, prywatnością i sąsiedztwem.

Zagadnienia dotyczące usługi AKS

Usługa AKS wymaga zrozumienia sposobu używania orkiestratora kontenerów.

Aby uzyskać więcej informacji, zobacz:

Aplikacje kontenera

Za pomocą usługi Container Apps można tworzyć mikrousługi bezserwerowe oparte na kontenerach. Aplikacje kontenera:

  • Jest zoptymalizowany pod kątem uruchamiania kontenerów ogólnego przeznaczenia, zwłaszcza aplikacji obejmujących wiele mikrousług wdrożonych w kontenerach.

  • Jest obsługiwany przez technologie Kubernetes i open source, takie jak Dapr, Kubernetes Event-driven Autoscaling (KEDA) i Envoy.

  • Obsługuje aplikacje w stylu Kubernetes i mikrousługi z funkcjami takimi jak odnajdywanie usług i dzielenie ruchu.

  • Umożliwia architektury aplikacji sterowane zdarzeniami, obsługując skalowanie oparte na ruchu i ściąganie ze źródeł zdarzeń, takich jak kolejki, w tym skalowanie do zera.

  • Obsługuje długotrwałe procesy i może uruchamiać zadania w tle.

Zagadnienia dotyczące usługi Container Apps

Usługa Container Apps nie zapewnia bezpośredniego dostępu do podstawowych interfejsów API platformy Kubernetes. Jeśli potrzebujesz dostępu do interfejsów API platformy Kubernetes i płaszczyzny sterowania, użyj usługi AKS. Jeśli chcesz tworzyć aplikacje w stylu Kubernetes i nie potrzebujesz bezpośredniego dostępu do natywnych interfejsów API platformy Kubernetes i zarządzania klastrem, użyj usługi Container Apps w celu uzyskania w pełni zarządzanego środowiska. Usługa Container Apps najlepiej nadaje się do tworzenia mikrousług kontenerów.

Aby uzyskać więcej informacji, zobacz:

Lista kontrolna dotycząca niezawodności

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna dotycząca niezawodności