Zalecenia dotyczące tworzenia zadań w tle

  • Artykuł

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

RE:07 Wzmacnianie odporności i możliwości odzyskiwania obciążenia przez zaimplementowanie środków samozachowawczych i samonaprawiania. Tworzenie 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 funkcje w systemie w celu wykrywania awarii składników rozwiązania i automatycznego inicjowania akcji naprawczej, podczas gdy obciążenie nadal działa w pełnej lub zmniejszonej funkcjonalności.

Powiązane przewodniki:Przejściowe błędy | Samozachowawcza

W tym przewodniku opisano zalecenia dotyczące tworzenia zadań w tle. Zadania w tle są uruchamiane automatycznie bez konieczności interakcji użytkownika. 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, intensywne zadania przetwarzania i długotrwałe procesy, takie jak przepływy pracy. Aplikacja uruchamia zadanie i przetwarza żądania interakcyjne 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. Innym przykładem jest umieszczenie zamówienia przez klienta, który 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 zmniejsza interakcyjny czas odpowiedzi.

Kluczowe strategie projektowania

Aby wybrać zadanie do wyznaczenia jako zadanie w tle, rozważ, 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, zwykle nie są odpowiednie zadania w tle.

Typy zadań 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 przesyła zadanie do bezpieczniejszej lokalizacji do przetwarzania. Na przykład przetwarzanie danych poufnych w aplikacji internetowej może być niewskazane. Zamiast tego można użyć wzorca, takiego jak wzorzec gatekeeper , do transferu danych do izolowanego procesu w tle, który ma dostęp do chronionego magazynu.

Wyzwalacze

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 uruchomienia.

Wyzwalacze sterowane zdarzeniami

Akcja wyzwala wywołanie oparte na zdarzeniach, 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ść, która jest w magazynie. Zadanie w tle monitoruje magazyn i wykrywa zmiany. Odczytuje dane i używa ich jako danych wejściowych zadania w tle.

  • Interfejs użytkownika lub inne zadanie wysyła żądanie do punktu końcowego, takie jak identyfikator URI HTTPS lub interfejs API, który jest udostępniany jako usługa internetowa. W ramach żądania interfejs użytkownika lub zadania 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 opartego na zdarzeniach 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 opartych na harmonogramie obejmują:

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

  • Czasomierz działający 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 na podstawie ich ostatniego zachowania), 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, które uruchamia harmonogram, takie jak maszyna wirtualna korzystająca z zaplanowanych zadań systemu Windows, jest skalowane, uruchamiasz 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ć inne wystąpienie zadania, podczas gdy poprzednie zadanie jest uruchamiane.

Zwracanie wyników

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. W idealnym przypadku zadania w tle są uruchamiane i pomijane . Ich postęp w czasie wykonywania nie ma wpływu na interfejs użytkownika ani proces wywoływania, co oznacza, że proces wywoływania nie czeka na ukończenie zadań. Interfejs użytkownika i proces wywoływania nie mogą wykryć, gdy zadanie zakończy się.

Jeśli potrzebujesz zadania w tle do komunikowania się z zadaniem wywołującym w celu wskazania postępu lub ukończenia, 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, które zadanie w tle zwraca do obiekt wywołujący, można umieścić w tym samym magazynie.

  • Ustanów kolejkę odpowiedzi monitorowaną przez interfejs użytkownika lub obiekt wywołujący. Zadanie w tle może wysyłać komunikaty do kolejki, które wskazują stan. Dane zwracane przez zadanie w tle do elementu wywołującego można umieścić w komunikatach. W przypadku Azure Service Bus użyj ReplyTo właściwości iCorrelationId, 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, które zadanie w tle zwraca do elementu 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 zgłaszane 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 wymagać tego samego poziomu dostępności co 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ą odporność na opóźnienia, ponawiane błędy połączeń i 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 w celu zaspokojenia szczytów 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 kończy się niepowodzeniem, może to nie mieć krytycznego wpływu na całą aplikację. Żądania dotyczące tych zadań mogą być kolejkowane lub odroczone do momentu udostępnienia zadania. Jeśli wystąpienie obliczeniowe lub zadania 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: jeśli dodasz wystąpienia obliczeniowe do uruchamiania zadań w tle, koszty hostingu wzrosną. Starannie rozważ kompromis między większą pojemnością a dodatkowymi kosztami.

Aby uzyskać więcej informacji, zobacz Wzorzec wyboru lidera i Wzorzec konkurujących konsumentów.

Konflikty

Jeśli masz wiele wystąpień zadania w tle, mogą 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 do blokowania. Takie podejście zapobiega współbieżnym uzyskiwaniu dostępu do usługi lub uszkodzeniu danych przez konkurencyjne wystąpienia zadania.

Innym podejściem do rozwiązywania konfliktów jest zdefiniowanie zadań w tle jako pojedynczego, 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 zapewnić zajętość więcej niż jednego zadania w tle.

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.

Koordynacja

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 często są wielokrotnego użytku w wielu zadaniach. Można również łatwo dodawać, usuwać lub modyfikować kolejność kroków.

Może to stanowić 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 zadania, 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 definiuje ostatecznie spójną operację. Aby uzyskać więcej informacji, zobacz Wzorzec transakcji wyrównywujących.

Zagadnienia związane z odpornością

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 wprowadzania 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.

Komunikaty

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

  • Czasami komunikaty muszą być przetwarzane w określonej kolejności, na przykład 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 z powodu różnych obciążeń w każdym wystąpieniu.

    W przypadku komunikatów, które muszą być przetwarzane w określonej kolejności, dołącz numer sekwencji, klucz lub inny wskaźnik, którego zadania w tle mogą używać do przetwarzania komunikatów w odpowiedniej kolejności. W przypadku usługi Service Bus użyj sesji komunikatów, aby zagwarantować poprawną kolejność dostarczania. Wydajniejsze jest zaprojektowanie procesu, 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. Po pomyślnym zakończeniu przetwarzania komunikatu przez zadanie program usuwa komunikat. Jeśli zadanie w tle zakończy się niepowodzeniem podczas przetwarzania komunikatu, ten komunikat pojawi się ponownie w kolejce po upływie limitu czasu wglądu. Inne wystąpienie zadania przetwarza komunikat lub następny cykl przetwarzania oryginalnego wystąpienia przetwarza komunikat.

    Jeśli komunikat stale powoduje błąd w odbiorcy, blokuje zadanie, kolejkę i ostatecznie samą aplikację, gdy kolejka stanie się pełna. Ważne jest, aby wykrywać i usuwać trujące komunikaty 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 oryginalnego 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 komunikat z kolejki jest odczytywany. Te dane są przydatne do obsługi powtarzających się komunikatów i zatrutych komunikatów. Aby uzyskać więcej informacji, zobacz Asynchronous messaging primer and Idempotency patterns (Wzorce asynchronicznej obsługi komunikatów i idempotentności).

Zagadnienia związane ze skalowaniem i wydajnością

Zadania w tle muszą zapewniać wystarczającą wydajność, aby upewnić się, że nie blokują aplikacji ani nie opóźniają operacji, gdy system jest obciążony. Zwykle 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 Azure App Service mogą hostować wdrożenia. Obsługują one automatyczne skalowanie, zarówno skalowanie w pęk, jak i skalowanie w pęk. Automatyczne skalowanie zależy od zapotrzebowania i obciążenia lub wstępnie zdefiniowanego harmonogramu. Użyj automatycznego skalowania, aby zapewnić, że aplikacja ma wystarczające możliwości wydajności przy jednoczesnym zminimalizowaniu kosztów środowiska uruchomieniowego.

  • Niektóre zadania w tle mają inne możliwości wydajności w porównaniu z innymi częściami aplikacji, na przykład interfejs użytkownika lub składniki, takie jak warstwa dostępu do danych. W tym scenariuszu hostowanie zadań w tle w oddzielnej usłudze obliczeniowej umożliwia niezależne skalowanie interfejsu użytkownika i zadań w tle 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. Weź pod uwagę inne ograniczenia, takie jak maksymalna przepływność magazynu i inne usługi, 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 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, aby platforma Azure uruchamiała tylko jedno wystąpienie 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 od 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 kolejkowania, usługi procesu roboczego, usługi monitorowania i mechanizmu ponawiania prób.

Ułatwienia dla 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 zadania WebJob: funkcja WebJobs 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żyj aplikacji funkcji dla 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 na niedostatecznie używanym planie App Service.

  • Virtual Machines: 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 mocy obliczeniowej do uruchomienia w 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 zadania WebJob

Funkcja Zadań WebJob umożliwia uruchamianie zadań niestandardowych jako zadań w tle w aplikacji internetowej. Zadanie WebJob jest uruchamiane 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żesz skonfigurować akcje ponawiania prób 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.

  • W przypadku wybrania opcji Uruchom na żądanie podczas konfigurowania zadania program uruchamia ten sam kod co opcja Uruchom zgodnie z harmonogramem podczas uruchamiania 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, z aplikacją internetową. Usługa WebJob ma dostęp do unikatowego identyfikatora maszyny, na których uruchomiono 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 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 sieci Web. Pliki dziennika są zapisywane w następujących lokalizacjach:

    • W przypadku wdrożenia wyzwolonego: 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 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 App Service plan hostowania długotrwałych lub intensywnie korzystających z zasobów zadań WebJob.

Azure Functions

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

Azure Functions nie jest zalecane 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 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 zużywające 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. Jako korzyść można użyć innych funkcji, takich jak integracja z siecią wirtualną.

Dedykowany plan jest odpowiedni dla zadań w tle, jeśli obciążenie jest już uruchamiane 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ółużytkować koszty obliczeń.

Aby uzyskać więcej informacji, zobacz:

Virtual Machines

Zadania w tle można zaimplementować, aby nie były wdrażane w 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 jeden z 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 wykonać następujące czynności:

  • Wyślij żądanie do punktu końcowego uwidocznionego 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 zainstalowano SQL Server, użyj agenta SQL Server do uruchamiania skryptów i zadań.

  • Usługa Logic Apps umożliwia zainicjowanie zadania przez dodanie komunikatu do kolejki monitorowej przez zadanie lub wysłanie żądania do interfejsu API uwidocznionego przez zadanie.

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

zagadnienia dotyczące Virtual Machines

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żesz 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 funkcji sterowania procesami i wątkami. Zazwyczaj jeśli używasz maszyny wirtualnej, musisz 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, które są uwidocznione za pośrednictwem punktów końcowych HTTP. Kod dla tych sond można skonfigurować pod kątem przeprowadzania kontroli kondycji i zbierania informacji operacyjnych i statystyk. Sondy umożliwiają również sortowanie informacji o błędach i zwracanie ich do aplikacji zarządzania.

Aby uzyskać więcej informacji, zobacz:

Batch

Rozważ użycie usługi 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 partii

Usługa Batch jest odpowiednia dla obciążeń wewnętrznie równoległych. Za pomocą usługi Batch można wykonywać równoległe obliczenia 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żesz 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

Usługa AKS umożliwia zarządzanie hostowanym środowiskiem Kubernetes w celu łatwego wdrażania aplikacji konteneryzowanych i zarządzania 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.

  • Użyj koordynatora kontenerów, aby wykonać wewnętrzne równoważenie obciążenia, skonfigurować sieć wewnętrzną i wykonać inne zadania konfiguracyjne.

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

  • Dzięki Azure Container Registry możesz zarejestrować kontenery w granicach platformy Azure, aby zapewnić korzyści związane 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:

Kontener Apps

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

  • 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 opartej na zdarzeniach, 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