Udostępnij za pośrednictwem

Zadania w tle

  • Artykuł

Wiele rodzajów aplikacji wymaga używania zadań w tle działających niezależnie od interfejsu użytkownika. Mogą to być na przykład zadania wsadowe, zadania wymagające intensywnego przetwarzania oraz długotrwałe procesy takie jak przepływy pracy. Zadania w tle mogą być wykonywane bez konieczności interakcji z użytkownikiem — aplikacja może rozpocząć zadanie, a następnie kontynuować przetwarzanie interaktywnych żądań od użytkowników. Zmniejsza to obciążenie interfejsu użytkownika aplikacji, a w efekcie poprawia dostępność i skraca czas odpowiedzi na interakcje.

Jeśli na przykład aplikacja musi wygenerować miniatury obrazów przekazywanych przez użytkowników, może zrobić to w tle, a po zakończeniu zapisać miniaturę w magazynie — użytkownik nie musi czekać na ukończenie tego procesu. Na podobnej zasadzie złożenie zamówienia przez użytkownika może zainicjować przepływ pracy w tle, który przetworzy to zamówienie, podczas gdy interfejs użytkownika umożliwi użytkownikowi dalsze przeglądanie aplikacji internetowej. Po zakończeniu zadania w tle można zaktualizować zapisane dane zamówień i wysłać do użytkownika wiadomość e-mail z potwierdzeniem zamówienia.

Podejmując decyzję, czy zaimplementować zadanie jako zadanie w tle, należy przede wszystkim określić, czy zadanie może zostać wykonane bez udziału użytkownika i bez konieczności oczekiwania przez interfejs użytkownika na ukończenie zadania. Zadania wymagające oczekiwania na ukończenie przez użytkownika lub interfejs użytkownika mogą nie być odpowiednie do wdrożenia jako zadania w tle.

Typy zadań w tle

Zadania w tle obejmują na ogół następujące typy zadań:

  • Zadania intensywnie obciążające procesor CPU, na przykład obliczenia matematyczne lub analiza modeli strukturalnych.
  • Zadania wykonujące bardzo wiele operacji we/wy, takie jak wykonanie serii transakcji magazynu lub indeksowanie plików.
  • Zadania wsadowe, na przykład nocne aktualizacje danych lub zaplanowane przetwarzanie.
  • Długotrwałe przepływy pracy, takie jak realizacja zamówień lub aprowizacja usług i systemów.
  • Przetwarzanie danych poufnych, w przypadku gdy zadanie jest przekazywane do bezpieczniejszej lokalizacji w celu przetworzenia. 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.

Wyzwalacze

Zadania w tle mogą zostać zainicjowane na kilka różnych sposobów. Dzielą się one na następujące kategorie:

  • Wyzwalacze sterowane zdarzeniami. Zadanie rozpoczyna się w odpowiedzi na zdarzenie, zwykle akcję podjętą przez użytkownika lub krok przepływu pracy.
  • Wyzwalacze sterowane harmonogramem. Zadanie jest wywoływane na podstawie harmonogramu opartego na czasomierzu. Może to być harmonogram cykliczny lub jednorazowe wywołanie zaplanowane na późniejszy czas.

Wyzwalacze sterowane zdarzeniami

Wywołanie sterowane zdarzeniami używa wyzwalacza, aby rozpocząć zadanie w tle. Wyzwalacze sterowane zdarzeniami to na przykład:

  • Umieszczenie komunikatu w kolejce przez interfejs użytkownika lub inne zadanie. Komunikat zawiera dane o wykonanej akcji — na przykład o złożeniu zamówienia przez użytkownika. Zadanie w tle nasłuchuje tej kolejki i wykrywa nadejście nowego komunikatu. Odczytuje komunikat i wykorzystuje zawarte w nim dane jako dane wejściowe dla zadania w tle. Ten wzorzec jest nazywany asynchroniczną komunikacją opartą na komunikatach.
  • Zapisanie lub zaktualizowanie wartości w magazynie przez interfejs użytkownika lub inne zadanie. Zadanie w tle monitoruje magazyn i wykrywa zmiany. Odczytuje dane i wykorzystuje je jako dane wejściowe dla zadania w tle.
  • Wysłanie żądania do punktu końcowego, na przykład identyfikatora URI protokołu HTTPS lub interfejsu API uwidocznionego jako usługa internetowa, przez interfejs użytkownika lub inne zadanie. Dane wymagane do ukończenia zadania w tle są przekazywane jako część żądania. Punkt końcowy lub usługa internetowa wywołuje zadanie w tle, które wykorzystuje te dane jako dane wejściowe.

Przykłady zadań odpowiednich do wywołania sterowanego zdarzeniem to przetwarzanie obrazów, przepływy danych, wysyłanie informacji do usług zdalnych, wysyłanie wiadomości e-mail oraz aprowizowanie nowych użytkowników w aplikacjach wielodostępnych.

Wyzwalacze sterowane harmonogramem

Wywołanie sterowane harmonogramem korzysta z czasomierza, aby rozpocząć zadanie w tle. Wyzwalacze sterowane harmonogramem to na przykład:

  • Czasomierz działający lokalnie w aplikacji lub w ramach systemu operacyjnego aplikacji regularnie wywołuje zadanie w tle.
  • Czasomierz działający w innej aplikacji, na przykład Azure Logic Apps, wysyła żądanie do interfejsu API lub usługi internetowej w regularnych odstępach czasu. Interfejs API lub usługa internetowa wywołuje zadanie w tle.
  • Oddzielny proces lub aplikacja uruchamia czasomierz, co sprawia, że zadanie w tle jest wywoływane z określonym opóźnieniem lub w określonym czasie.

Typowe zadania odpowiednie do wywołania sterowanego harmonogramem to na przykład procedury przetwarzania wsadowego (takie jak aktualizowanie list powiązanych produktów dla użytkowników na podstawie ich niedawnego zachowania), rutynowe zadania przetwarzania danych (takie jak aktualizowanie indeksów lub generowanie skumulowanych wyników), analiza danych do codziennych raportów, oczyszczanie przechowywanych danych i sprawdzanie spójności danych.

W przypadku używania zadania sterowanego harmonogramem, które musi zostać uruchomione jako pojedyncze wystąpienie, należy pamiętać o następujących kwestiach:

  • Skalowanie wystąpienia obliczeniowego obsługującego harmonogram (na przykład maszyny wirtualnej używającej zadań zaplanowanych w systemie Windows) spowoduje uruchomienie wielu wystąpień harmonogramu. Mogą one uruchomić wiele wystąpień zadania. Aby uzyskać więcej informacji na ten temat, przeczytaj ten wpis w blogu o idempotence.
  • Jeśli czas wykonywania zadania przekracza czas pomiędzy zdarzeniami harmonogramu, harmonogram może uruchomić kolejne wystąpienie zadania w czasie, kiedy poprzednie nadal trwa.

Zwracanie wyników

Zadania w tle są wykonywane asynchronicznie w oddzielnym procesie albo nawet w innej lokalizacji niż interfejs użytkownika lub proces, który wywołał zadanie w tle. W idealnym przypadku zadania w tle są operacjami "wyzwalania i zapominania", a ich postęp wykonywania nie ma wpływu na interfejs użytkownika ani proces wywoływania. Oznacza to, że proces wywołujący zadania nie czeka na ich ukończenie. W związku z tym nie może automatycznie wykryć, kiedy zadanie zostanie zakończone.

Jeśli zadanie w tle musi komunikować się z wywołującym je zadaniem i informować o postępie lub zakończeniu, należy w tym celu zaimplementować odpowiedni mechanizm. Niektóre przykłady:

  • Zapisanie wartości wskaźnika stanu do magazynu, który jest dostępny dla interfejsu użytkownika lub wywołującego zadania, w celu monitorowania lub sprawdzania tej wartości wedle potrzeb. Inne dane zwracane przez zadanie w tle do elementu wywołującego można umieścić w tym samym magazynie.
  • Utworzenie kolejki odpowiedzi, której nasłuchuje interfejs użytkownika lub element wywołujący. Zadanie w tle może wysyłać do kolejki komunikaty wskazujące stan oraz moment zakończenia. Dane zwracane przez zadanie w tle do elementu wywołującego można umieścić w komunikatach. Jeśli korzystasz z usługi Azure Service Bus, możesz użyć właściwości ReplyTo 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. Dane, które zadanie w tle musi zwrócić do elementu wywołującego, można umieścić w odpowiedzi.
  • Wysłanie przez zadanie w tle wywołania zwrotnego do interfejsu użytkownika lub elementu wywołującego za pośrednictwem interfejsu API w celu wskazania stanu w określonych punktach lub w momencie zakończenia. Do tego celu można użyć zdarzeń wywoływanych lokalnie lub mechanizmu publikowania i subskrybowania. Dane, które zadanie w tle musi zwrócić do elementu wywołującego, można umieścić w ładunku żądania lub zdarzenia.

Środowisko hostingu

Zadania w tle można hostować, korzystając z kilku różnych usług platformy Azure:

  • Azure Web Apps i WebJobs. Usługa WebJobs umożliwia wykonywanie niestandardowych zadań w oparciu o różne typy skryptów lub programów wykonywalnych w kontekście aplikacji internetowej.
  • Usługa Azure Functions. Funkcji można używać w przypadku zadań w tle, które nie są uruchamiane przez długi czas. Innym przypadkiem użycia jest to, że obciążenie jest już hostowane w planie usługi App Service i jest niedostatecznie wykorzystywane.
  • Azure Virtual Machines. Jeśli masz usługę systemu Windows lub chcesz użyć usługi Harmonogram zadań systemu Windows, typowym rozwiązaniem jest hostowanie zadań w tle na dedykowanej maszynie wirtualnej.
  • Azure Batch. Jest to usługa platformy, która umożliwia planowanie pracy wymagającej intensywnych obliczeń na zarządzanym zestawie maszyn wirtualnych. Umożliwia też automatyczne skalowanie zasobów obliczeniowych.
  • Azure Kubernetes Service (AKS). Usługa Azure Kubernetes Service udostępnia zarządzane środowisko hostingu dla platformy Kubernetes na platformie Azure.
  • Azure Container Apps. Usługa Azure Container Apps umożliwia tworzenie mikrousług bezserwerowych na podstawie kontenerów.

W poniższych sekcjach opisano te opcje bardziej szczegółowo i opisano zagadnienia ułatwiające wybranie odpowiedniej opcji.

Usługi Azure Web Apps i WebJobs

Usługa Azure WebJobs służy do wykonywania niestandardowych zadań w tle w ramach aplikacji internetowej platformy Azure. Zadania WebJobs są uruchamiane w kontekście aplikacji internetowej jako ciągły proces. Zadania WebJob są również uruchamiane w odpowiedzi na zdarzenie wyzwalacza z usługi Azure Logic Apps lub czynników zewnętrznych, takich jak zmiany w obiektach blob magazynu i kolejkach komunikatów. Zadania można rozpoczynać i zatrzymywać na żądanie oraz prawidłowo zamykać. Jeśli stale działające zadanie WebJob ulegnie awarii, zostanie ono automatycznie ponownie uruchomione. Akcje ponownych prób i błędów można konfigurować.

Podczas konfigurowania zadania WebJob:

  • Jeśli chcesz, aby zadanie odpowiadało na wyzwalacz sterowany wydarzeniem, wybierz konfigurację Wykonuj ciągle. Skrypt lub program będzie przechowywany w folderze o nazwie site/wwwroot/app_data/jobs/continuous.
  • Jeśli chcesz, aby zadanie odpowiadało na wyzwalacz sterowany harmonogramem, wybierz konfigurację Uruchamiaj według harmonogramu. Skrypt lub program będzie przechowywany w folderze o nazwie site/wwwroot/app_data/jobs/triggered.
  • Jeśli podczas konfiguracji zdecydujesz się na wybranie opcji Uruchamiaj na żądanie, zadanie po uruchomieniu wykona taki sam kod, jak w przypadku wybrania opcji Uruchamiaj według harmonogramu.

Zadania Azure WebJobs są uruchamiane w piaskownicy aplikacji internetowej. Oznacza to, że mają one dostęp do zmiennych środowiskowych i mogą udostępniać aplikacji internetowej informacje, na przykład parametry połączenia. Zadanie ma dostęp do unikatowego identyfikatora maszyny, na której jest uruchamiane. Parametry połączenia o nazwie AzureWebJobsStorage zapewnia dostęp do kolejek, obiektów blob i tabel usługi Azure Storage dla danych aplikacji oraz dostępu do usługi Service Bus na potrzeby obsługi komunikatów i komunikacji. Parametr połączenia o nazwie AzureWebJobsDashboard zapewnia dostęp do plików dziennika akcji zadania.

Zadania Azure WebJobs mają następujące cechy:

  • Zabezpieczenia: zadania WebJobs są chronione przez poświadczenia wdrażania aplikacji internetowej.
  • Obsługiwane typy plików: zadania WebJob można definiować przy użyciu skryptów poleceń (.cmd), plików wsadowych (.bat), skryptów programu PowerShell (.ps1), skryptów powłoki Bash (), skryptów PHP (.php.sh), skryptów języka Python (.py), kodu JavaScript (.js) i programów wykonywalnych (.exe, .jari innych).
  • Wdrożenie: skrypty i pliki wykonywalne można wdrażać przy użyciu witryny Azure Portal, przy użyciu programu Visual Studio, zestawu SDK usługi Azure WebJobs lub kopiując je bezpośrednio do następujących lokalizacji:
    • W przypadku wykonywania wyzwalanego: site/wwwroot/app_data/jobs/triggered/{nazwa zadania}
    • W przypadku wykonywania ciągłego: site/wwwroot/app_data/jobs/continuous/{nazwa zadania}
  • Rejestrowanie: wyjście Console.Out jest traktowane (oznaczane) jako INFO (Informacja). Wyjście Console.Error jest traktowane jako ERROR (Błąd). W witrynie Azure Portal możesz uzyskać dostęp do funkcji monitorowania oraz informacji diagnostycznych. Pliki dziennika można pobrać bezpośrednio z tej witryny. Są one zapisywane w następujących lokalizacjach:
    • W przypadku wykonywania wyzwalanego: Vfs/data/jobs/triggered/nazwa_zadania
    • W przypadku wykonywania ciągłego: Vfs/data/jobs/continuous/nazwa_zadania
  • Konfiguracja: zadania WebJob można konfigurować przy użyciu portalu, interfejsu API REST lub programu PowerShell. Możesz użyć pliku konfiguracji o nazwie settings.job w tym samym folderze głównym, w którym znajduje się skrypt zadania, aby wprowadzić informacje dotyczące konfiguracji zadania. Na przykład: .
    • { „stopping_wait_time”: 60 }
    • { „is_singleton”: true }

Kwestie wymagające rozważenia

  • Domyślnie zadania WebJob są skalowane wraz z aplikacją internetową. Możesz jednak skonfigurować zadania tak, aby były uruchamiane w ramach jednego wystąpienia, ustawiając właściwość konfiguracji is_singleton na true. Zadania WebJob uruchamiane w ramach jednego wystąpienia przydają się podczas pracy z zadaniami, których nie chcesz skalować ani uruchamiać w wielu jednoczesnych wystąpieniach — na przykład w przypadku ponownego indeksowania, analizy danych itp.
  • Aby zminimalizować wpływ zadań na wydajność aplikacji internetowej, rozważ utworzenie pustego wystąpienia aplikacji internetowej platformy Azure w nowym planie usługi App Service do hostowania długotrwałych lub intensywnie korzystających z zasobów zadań WebJob.

Azure Functions

Opcja podobna do zadań WebJob to Azure Functions. Ta usługa jest bezserwerowa, która jest najbardziej odpowiednia dla wyzwalaczy sterowanych zdarzeniami uruchamianych przez krótki okres. Funkcja może również służyć do uruchamiania zaplanowanych zadań za pomocą wyzwalaczy czasomierza, gdy jest skonfigurowana do uruchamiania w określonych godzinach.

Usługa Azure Functions nie jest zalecaną opcją dla dużych, długotrwałych zadań, ponieważ mogą powodować nieoczekiwane problemy z przekroczeniem limitu czasu. Jednak w zależności od planu hostingu można je uznać za wyzwalacze sterowane harmonogramem.

Kwestie wymagające rozważenia

Jeśli zadanie w tle ma być uruchamiane przez krótki czas w odpowiedzi na zdarzenie, rozważ uruchomienie zadania w planie Zużycie. Czas wykonywania można skonfigurować do maksymalnego czasu. Funkcja, która działa dłużej, kosztuje więcej. Ponadto 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 bardziej odpowiedni, jeśli masz dużą liczbę zadań, które są krótkie, ale oczekuje się ciągłego uruchamiania. Ten plan jest droższy, ponieważ potrzebuje więcej pamięci i procesora CPU. Zaletą jest możliwość korzystania z funkcji, takich jak integracja z siecią wirtualną.

Plan dedykowany jest najbardziej odpowiedni dla zadań w tle, jeśli obciążenie jest już na nim uruchomione. Jeśli masz nieużytkowane maszyny wirtualne, możesz uruchomić je na tej samej maszynie wirtualnej i współdzielić koszty obliczeń.

Więcej informacji można znaleźć w tych artykułach:

Azure Virtual Machines

Zadania w tle mogą być implementowane w sposób uniemożliwiający ich wdrażanie w usłudze Azure Web Apps lub te opcje mogą nie być wygodne. Typowym przykładem są usługi systemu Windows oraz narzędzia i programy wykonywalne innych firm. Kolejnym przykładem są programy napisane dla środowiska wykonawczego innego niż środowisko, w którym jest hostowana aplikacja. Może to być na przykład program systemu Unix lub Linux, który ma zostać wykonany z poziomu aplikacji systemu Windows lub .NET. Maszyny wirtualne platformy Azure są dostępne dla wielu systemów operacyjnych, a na maszynie wirtualnej możesz uruchomić swoją usługę lub program wykonywalny.

Temat Porównanie usług Azure App Service, Cloud Services i Virtual Machines może pomóc w podjęciu decyzji o użyciu usługi Virtual Machines. Aby uzyskać informacje o opcjach maszyn wirtualnych, zobacz Rozmiary maszyn wirtualnych z systemem Windows na platformie Azure. Aby uzyskać więcej informacji na temat systemów operacyjnych i wstępnie utworzonych obrazów dostępnych dla maszyn wirtualnych, zobacz maszyny wirtualne dla platformy Azure w witrynie Marketplace.

Jeśli chcesz zainicjować zadanie w tle na oddzielnej maszynie wirtualnej, masz kilka opcji do wyboru:

  • Wykonywanie zadania na żądanie bezpośrednio z poziomu aplikacji, wysyłając żądanie do punktu końcowego uwidocznionego przez zadanie. To powoduje przekazanie wszelkich danych wymaganych przez zadanie. Ten punkt końcowy wywołuje zadanie.
  • Skonfigurowanie uruchamiania zadania według harmonogramu, używając usługi harmonogramu lub czasomierza dostępnej w wybranym systemie operacyjnym. Na przykład w systemie Windows do wykonywania skryptów i zadań można użyć Harmonogramu zadań systemu Windows. Jeśli na maszynie wirtualnej zainstalowano program SQL Server, do wykonywania skryptów i zadań możesz użyć agenta programu SQL Server.
  • Za pomocą usługi Azure Logic Apps możesz zainicjować zadanie, dodając komunikat do kolejki, na której nasłuchuje zadanie, lub wysyłając żądanie do interfejsu API uwidacznianego przez zadanie.

Zapoznaj się z wcześniejszą sekcją Wyzwalacze, aby uzyskać więcej informacji na temat inicjowania zadań w tle.

Kwestie wymagające rozważenia

Przy podejmowaniu decyzji dotyczącej wdrożenia zadań w tle na maszynie wirtualnej platformy Azure należy wziąć pod uwagę następujące kwestie:

  • Hostowanie zadania w tle na oddzielnej maszynie wirtualnej platformy Azure zapewnia elastyczność i umożliwia ścisłą kontrolę nad uruchamianiem, wykonywaniem i planowaniem oraz przydzielaniem zasobów. Wdrożenie maszyny wirtualnej tylko po to, aby uruchamiać zadania w tle, zwiększa jednak koszt środowiska uruchomieniowego.
  • W witrynie Azure Portal nie ma możliwości monitorowania zadań i automatycznego ponownego uruchamiania zadań zakończonych niepowodzeniem, chociaż można monitorować podstawowy stan maszyny wirtualnej i zarządzać nią, korzystając z poleceń cmdlet usługi Azure Resource Manager. Nie ma jednak możliwości kontrolowania procesów i wątków w węzłach obliczeniowych. Zwykle korzystanie z maszyny wirtualnej będzie wymagało włożenia dodatkowego wysiłku i zaimplementowania mechanizmu do zbierania danych z instrumentacji w zadaniu oraz z systemu operacyjnego maszyny wirtualnej. Właściwym rozwiązaniem może być użycie pakietu System Center Management Pack dla platformy Azure.
  • Rozważyć można utworzenie sond monitorujących, które będą uwidaczniane za pośrednictwem punktów końcowych HTTP. Kod tych sond może sprawdzać kondycję, zbierać informacje operacyjne oraz statystyczne lub sortować informacje o błędach i zwracać je do aplikacji zarządzania. Aby uzyskać więcej informacji, zobacz Wzorzec monitorowania punktu końcowego kondycji.

Aby uzyskać więcej informacji, zobacz:

Usługa Azure Batch

Jeśli musisz równolegle uruchamiać duże obciążenia obliczeniowe o wysokiej wydajności na dziesiątkach, setkach lub tysiącach maszyn wirtualnych, możesz rozważyć użycie usługi Azure Batch.

Usługa Batch aprowizuje maszyny wirtualne, przypisuje do nich zadania, uruchamia zadania i monitoruje ich postęp. Usługa Batch automatycznie skaluje w poziomie maszyny wirtualne odpowiednio do obciążeń. Usługa Batch umożliwia również planowanie zadań. Usługa Azure Batch obsługuje maszyny wirtualne z systemem Linux i Windows.

Kwestie wymagające rozważenia

Usługa Batch dobrze działa z wewnętrznie równoległymi obciążeniami. W usłudze Batch można również wykonywać obliczenia równoległe zakończone czynnością redukcji oraz uruchamiać aplikacje MPI (Message Passing Interface) w przypadku zadań równoległych, które wymagają przekazywania komunikatów pomiędzy węzłami.

Zadanie usługi Azure Batch jest uruchamiane w ramach puli węzłów (maszyn wirtualnych). Jedna z metod zakłada przydzielenie puli tylko na czas, gdy jest ona potrzebna, i usunięcie jej po zakończeniu zadania. To maksymalizuje stopień wykorzystania puli, ponieważ węzły nie są bezczynne — ale zadanie musi czekać na przydzielenie węzłów. Alternatywnie można utworzyć pulę wcześniej. Takie podejście skraca czas potrzebny na rozpoczęcie zadania, ale może się zdarzyć, że węzły będą czekały bezczynnie. Aby uzyskać więcej informacji, zobacz Okres istnienia puli i węzła obliczeniowego.

Aby uzyskać więcej informacji, zobacz:

Azure Kubernetes Service

Usługa Azure Kubernetes Service (AKS) zarządza hostowanym środowiskiem Kubernetes, co ułatwia wdrażanie konteneryzowanych aplikacji i zarządzanie nimi.

Kontenery mogą być 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.
  • Koordynator kontenerów obsługuje wewnętrzne równoważenie obciążenia, konfigurowanie sieci wewnętrznej i inne zadania konfiguracji.
  • Kontenery mogą być uruchamiane i zatrzymywane według potrzeb.
  • Usługa Azure Container Registry umożliwia rejestrowanie kontenerów w granicach platformy Azure. Zapewnia to korzyści związane z zabezpieczeniami, prywatnością oraz bliskością.

Kwestie wymagające rozważenia

  • Wymagana jest wiedza dotycząca korzystania z koordynatora kontenerów. W zależności od zestawu umiejętności zespołu DevOps może to być problem lub nie może być problemem.

Aby uzyskać więcej informacji, zobacz:

Azure Container Apps

Usługa Azure Container Apps umożliwia tworzenie mikrousług bezserwerowych na podstawie kontenerów. Charakterystyczne funkcje usługi Container Apps obejmują:

  • Zoptymalizowany pod kątem uruchamiania kontenerów ogólnego przeznaczenia, szczególnie w przypadku aplikacji obejmujących wiele mikrousług wdrożonych w kontenerach.
  • Obsługiwane przez platformę Kubernetes i technologie open source, takie jak Dapr, Kubernetes Event-driven Autoscaling (KEDA) i wysłannik.
  • Obsługuje aplikacje w stylu Kubernetes i mikrousługi z funkcjami takimi jak odnajdywanie usługi i dzielenie ruchu.
  • Umożliwia architektury aplikacji sterowane zdarzeniami przez obsługę skalowania na podstawie ruchu i ściągania ze źródeł zdarzeń, takich jak kolejki, w tym skalowanie do zera.
  • Obsługa długotrwałych procesów i może uruchamiać zadania w tle.

Kwestie wymagające rozważenia

Usługa Azure 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 Azure Kubernetes Service. Jeśli jednak chcesz tworzyć aplikacje w stylu Kubernetes i nie wymagają bezpośredniego dostępu do wszystkich natywnych interfejsów API platformy Kubernetes i zarządzania klastrem, usługa Container Apps zapewnia w pełni zarządzane środowisko oparte na najlepszych rozwiązaniach. Z tych powodów wiele zespołów może preferować rozpoczęcie tworzenia mikrousług kontenerów za pomocą usługi Azure Container Apps.

Aby uzyskać więcej informacji, zobacz:

Możesz rozpocząć tworzenie pierwszej aplikacji kontenera przy użyciu przewodników Szybki start.

Partycjonowanie

Jeśli zdecydujesz się uwzględnić zadania w tle w istniejącym wystąpieniu obliczeniowym, należy rozważyć, w jaki sposób będzie to miało wpływ na atrybuty jakości wystąpienia obliczeniowego i samego zadania w tle. Poniższe zagadnienia pomogą Ci zdecydować, czy umieścić zadania w istniejącym, czy w oddzielnym wystąpieniu obliczeniowym:

  • Dostępność: zadania w tle nie wymagają takiego samego poziomu dostępności, jak inne części aplikacji, a zwłaszcza interfejs użytkownika i inne elementy bezpośrednio uczestniczące w interakcji z użytkownikiem. Zadania w tle mogą lepiej tolerować opóźnienia, ponawiane próby połączenia zakończone niepowodzeniem i inne czynniki, które mają wpływ na dostępność, ponieważ operacje można umieścić w kolejce. Potrzebna jest jednak wystarczająca pojemność, aby nie dopuścić do zablokowania kolejki przez nadmiar żądań, co wpłynęłoby na działanie całej aplikacji.

  • Skalowalność: zadania w tle mogą mieć inne wymagania dotyczące skalowalności niż interfejs użytkownika i interaktywne części aplikacji. Skalowanie interfejsu użytkownika może być konieczne, aby sprostać szczytom zapotrzebowania, podczas gdy zaległe zadania w tle mogą być wykonywane w krótszym czasie pracy przez mniej wystąpień obliczeniowych.

  • Odporność: błąd wystąpienia obliczeniowego, które hostuje tylko zadania w tle, może nie mieć krytycznego wpływu na całą aplikację, jeśli żądania związane z tymi zadaniami można umieścić w kolejce lub odłożyć do momentu, w którym zadanie stanie się ponownie dostępne. Jeśli wystąpienie obliczeniowe lub zadania można uruchomić ponownie w odpowiednim interwale, użytkownicy aplikacji mogą nie mieć wpływu.

  • Zabezpieczenia: zadania w tle mogą mieć inne wymagania lub ograniczenia związane z zabezpieczeniami niż interfejs użytkownika lub inne części aplikacji. Używając oddzielnego wystąpienia obliczeniowego, możesz określić odmienne środowisko zabezpieczeń dla zadań. Możesz również użyć wzorców takich jak Strażnik, aby oddzielić wystąpienia obliczeniowe zadań w tle od interfejsu użytkownika, a przez to zwiększyć poziom bezpieczeństwa i separacji.

  • Wydajność: możesz dobrać rodzaj wystąpienia obliczeniowego dla zadań w tle do potrzeb związanych z wydajnością zadań. Może to oznaczać użycie tańszej opcji obliczeniowej, jeśli zadania nie potrzebują tych samych możliwości przetwarzania, co interfejs użytkownika, albo użycie większego wystąpienia, jeśli wymagają dodatkowej pojemności lub zasobów.

  • Możliwości zarządzania: zadania w tle mogą mieć inny cykl tworzenia i wdrażania niż główny kod aplikacji czy interfejs użytkownika. Wdrożenie ich w oddzielnym wystąpieniu obliczeniowym może uprościć aktualizacje i obsługę wersji.

  • Koszt: dodawanie wystąpień obliczeniowych na potrzeby wykonywania zadań w tle zwiększa koszty hostingu. Należy rozważyć, czy większa pojemność warta jest dodatkowych kosztów.

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

Konflikty

Jeśli istnieje wiele wystąpień zadań w tle, mogą one konkurować o dostęp do zasobów i usług, takich jak bazy danych i magazyny. Równoczesny dostęp może prowadzić do rywalizacji o zasoby i konfliktów mających wpływ na dostępność usług i integralność danych w magazynie. Problem rywalizacji o zasoby możesz rozwiązać, używając metody pesymistycznego blokowania. Uniemożliwia ona konkurującym wystąpieniom zadania jednoczesny dostęp do usługi i uszkodzenie danych.

Innym sposobem rozwiązania konfliktów jest zdefiniowanie zdań w tle jako pojedynczych, tak aby zawsze uruchamiane było tylko jedno wystąpienie zadania. Oznacza to jednak rezygnację z większej niezawodności i wydajności, jaką zapewnia konfiguracja z wieloma wystąpieniami. Dzieje się tak szczególnie wtedy, gdy interfejs użytkownika wymaga wykonania pracy przekraczającej możliwości jednego zadania w tle.

Kluczowe jest zagwarantowanie, że zadanie w tle może zostać automatycznie ponownie uruchomione i że ma dostatecznie dużą pojemność, aby poradzić sobie z okresami większego zapotrzebowania. Można to osiągnąć, przydzielając do wystąpienia obliczeniowego wystarczającą ilość zasobów, implementując mechanizm kolejki, który umożliwi przechowywanie żądań do późniejszego wykonania w okresie mniejszego zapotrzebowania, lub korzystając z obu tych technik jednocześnie.

Koordynacja

Zadania w tle mogą być złożone i mogą wymagać wykonania wielu pojedynczych zadań w celu wygenerowania wyniku lub spełnienia wszystkich wymagań. Bardzo często w takich scenariuszach zadania są dzielone na mniejsze czynności lub podzadania, które mogą być wykonywane przez wielu odbiorców. Zadania wieloetapowe mogą zapewniać większą wydajność i elastyczność, ponieważ poszczególne kroki można wykorzystać powtórnie w wielu różnych zadaniach. Łatwo można również dodawać i usuwać kroki oraz modyfikować ich kolejność.

Koordynowanie wielu zadań i kroków może stanowić wyzwanie, ale istnieją trzy powszechnie używane wzorce, które mogą pomóc w zaimplementowaniu odpowiedniego rozwiązania:

  • Podzielenie zadania na wiele kroków wielokrotnego użytku. Aplikacja może wymagać wykonania serii zadań o różnym stopniu skomplikowania względem informacji, które przetwarza. Prostą, ale mało elastyczną metodą zaimplementowania takiej aplikacji jest przetwarzanie informacji przy użyciu modułu monolitycznego. Jednak to podejście może ograniczyć możliwości refaktoryzacji kodu, zoptymalizowania go lub ponownego użycia, jeśli części tego samego procesu przetwarzania są wymagane w innym miejscu aplikacji. Aby uzyskać więcej informacji, zobacz Wzorzec potoków i filtrów.

  • Zarządzanie wykonywaniem kroków zadania. Aplikacja może wykonywać zadania złożone z wielu kroków (w tym kroków wywołujących zdalne usługi lub uzyskujących dostęp do zdalnych zasobów). Poszczególne kroki mogą być od siebie niezależne, ale są koordynowane przez logikę aplikacji, która implementuje zadanie. Aby uzyskać więcej informacji, zobacz Wzorzec nadzorcy agenta harmonogramu.

  • Zarządzanie odzyskiwaniem kroków zadania zakończonych niepowodzeniem. Może wystąpić potrzeba cofnięcia przez aplikację pracy wykonanej w ramach serii kroków (które razem definiują operację ze spójnością ostateczną), jeśli co najmniej jeden z tych kroków zakończy się niepowodzeniem. Aby uzyskać więcej informacji, zobacz Wzorzec transakcji wyrównywujących.

Zagadnienia związane z odpornością

Zadania w tle muszą być odporne na błędy, aby zapewnić aplikacji niezawodność usług. Podczas planowania i projektowania zadań w tle należy wziąć pod uwagę następujące kwestie:

  • Zadania w tle muszą być w stanie bezpiecznie obsługiwać ponowne uruchomienia bez uszkodzenia danych lub wprowadzenia niespójności w aplikacji. W przypadku długotrwałych lub wieloetapowych zadań rozważ korzystanie z funkcji sprawdzania postępu polegającej na zapisywaniu stanu zadań w trwałym magazynie lub w postaci komunikatów w kolejce, stosownie do potrzeb. Na przykład można utrwalić informacje o stanie w komunikacie w kolejce i przyrostowo aktualizować te informacje o stanie w miarę postępu zadania, aby umożliwić przetwarzanie zadania od ostatniego prawidłowego punktu kontrolnego — zamiast ponownego uruchamiania go od początku. W przypadku korzystania z kolejek usługi Azure Service Bus można zrealizować ten sam scenariusz przy użyciu sesji komunikatów. Sesje umożliwiają zapisywanie i pobieranie stanu przetwarzania aplikacji za pomocą 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. Dzięki temu rozwiązaniu w okresach mniejszego obciążenia można zredukować opóźnienie zadań w stosunku do interfejsu użytkownika. Oznacza to również, że ponowne uruchomienia nie będą blokować 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 przed mniej ważnymi zadaniami.

  • Zadania w tle, które są inicjowane za pomocą komunikatów lub przetwarzają komunikaty, muszą być zaprojektowane tak, aby radziły sobie z niespójnościami, takimi jak komunikaty przychodzące w nieprawidłowej kolejności, komunikaty powodujące powtarzające się błędy (często nazywane skażonymi komunikatami) oraz komunikaty dostarczane więcej niż raz. Rozważ następujące źródła:

    • Komunikaty, które muszą zostać przetworzone w konkretnej kolejności, takie jak komunikaty zmieniające dane w oparciu o istniejącą wartość danych (na przykład dodające wartość do istniejącej wartości), mogą nie zostać odebrane w takiej kolejności, w jakiej je wysłano. Mogą też być obsługiwane przez różne wystąpienia zadań w tle w różnej kolejności z powodu różnych obciążeń w poszczególnych wystąpieniach. Komunikaty, które muszą zostać przetworzone w określonej kolejności, powinny zawierać numer sekwencji, klucz lub inny wskaźnik, na podstawie którego zadanie w tle może określić właściwą kolejność przetwarzania. W przypadku korzystania z usługi Azure Service Bus można zagwarantować kolejność dostarczania przy użyciu sesji komunikatów. Zwykle jednak bardziej skuteczne jest zaprojektowanie procesu tak, aby kolejność komunikatów nie miała znaczenia, o ile jest to możliwe.

    • Zwykle zadania w tle uzyskują wgląd w komunikaty w kolejce, co tymczasowo ukrywa je przed innymi odbiorcami komunikatów. Następnie komunikaty są usuwane po pomyślnym zakończeniu ich przetwarzania. W przypadku niepowodzenia zadania w tle podczas przetwarzania komunikatu ten komunikat pojawi się ponownie w kolejce po upływie limitu czasu wglądu. Następnie zostanie on przetworzony przez inne wystąpienie zadania lub podczas następnego cyklu przetwarzania tego wystąpienia. Jeśli komunikat ciągle powoduje błąd u odbiorcy, spowoduje zablokowanie zadania, kolejki, a w końcu całej aplikacji, gdy kolejka zostanie zapełniona. W związku z tym skażone komunikaty muszą być wykrywane i usuwane z kolejki. Jeśli używasz usługi Azure Service Bus, komunikaty, które powodują błąd, mogą zostać przeniesione automatycznie lub ręcznie do skojarzonej kolejki utraconych wiadomości.

    • Kolejki gwarantują dostarczenie co najmniej raz, ale mogą dostarczyć ten sam komunikat więcej niż raz. Ponadto, jeśli zadanie w tle zakończy się niepowodzeniem po przetworzeniu komunikatu, ale przed usunięciem go z kolejki, komunikat będzie mógł zostać przetworzony ponownie. Zadania w tle powinny być idempotentne, co oznacza, że przetwarzanie tego samego komunikatu więcej niż raz nie powoduje błędu lub niespójności w danych aplikacji. Niektóre operacje są idempotentne z natury, na przykład zmiana wartości przechowywanej na określoną nową wartość. Jednak operacje takie jak dodanie wartości do istniejącej wartości przechowywanej bez sprawdzania, czy wartość przechowywana jest nadal taka sama, jak wtedy, gdy komunikat został pierwotnie wysłany, spowodują powstanie niespójności. Kolejki usługi Azure Service Bus można skonfigurować tak, aby automatycznie usuwały zduplikowane komunikaty. Aby uzyskać więcej informacji na temat wyzwań związanych z co najmniej jednokrotnym dostarczaniem komunikatów, zobacz wskazówki dotyczące idempotentnego przetwarzania komunikatów.

    • Niektóre systemy obsługi komunikatów, takie jak usługa Azure Queue Storage i kolejki usługi Azure Service Bus, obsługują właściwość liczby de kolejki, która wskazuje, ile razy komunikat został odczytany z kolejki. Może to być przydatne w przypadku powtarzających się i skażonych komunikatów. Aby uzyskać więcej informacji, zobacz Asynchronous Messaging Primer (Podstawy asynchronicznej obsługi komunikatów) i Idempotency Patterns (Wzorce idempotentności).

Zagadnienia związane ze skalowaniem i wydajnością

Zadania w tle muszą oferować taką wydajność, która zagwarantuje, że nie zablokują aplikacji i nie spowodują niespójności z powodu opóźnionego działania w warunkach obciążenia systemu. Zwykle wydajność poprawia skalowanie wystąpień obliczeniowych, które hostują zadania w tle. Podczas planowania i projektowania zadań w tle należy wziąć pod uwagę następujące kwestie dotyczące skalowania i wydajności:

  • pomoc techniczna platformy Azure skalowanie automatyczne (skalowanie w pionie i skalowanie z powrotem) na podstawie bieżącego zapotrzebowania i obciążenia lub wstępnie zdefiniowanego harmonogramu dla wdrożeń hostowanych usługi Web Apps i maszyn wirtualnych. Dzięki tej funkcji możesz zagwarantować, że cała aplikacja będzie miała wystarczającą wydajność przy jednoczesnym ograniczeniu kosztów środowiska uruchomieniowego.

  • Jeśli zadania w tle mają inną funkcję wydajności niż inne części aplikacji (na przykład interfejs użytkownika lub składniki, takie jak warstwa dostępu do danych), 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, rozważ podzielenie ich i niezależne skalowanie każdego typu. Należy jednak pamiętać, że może to zwiększyć koszty środowiska uruchomieniowego.

  • Po prostu skalowanie zasobów obliczeniowych może nie być wystarczające, aby zapobiec utracie wydajności pod obciążeniem. Konieczne może być również skalowanie kolejek magazynu i innych zasobów, aby zapobiec powstaniu wąskiego gardła w jednym punkcie całego łańcucha przetwarzania. Uwzględnij również inne ograniczenia, takie jak maksymalna przepływność magazynu i innych usług używanych przez aplikację i zadania w tle.

  • Zadania w tle muszą być zaprojektowane tak, aby umożliwić skalowanie. Muszą na przykład być w stanie dynamicznie wykryć liczbę używanych kolejek magazynu, aby nasłuchiwać komunikatów lub wysyłać komunikaty do odpowiedniej kolejki.

  • Zadania WebJob są domyślnie skalowane wraz z powiązanym wystąpieniem aplikacji internetowej platformy Azure. Jeśli jednak chcesz, aby zadanie WebJob było uruchamiane jako pojedyncze wystąpienie, możesz utworzyć plik Settings.job, który będzie zawierał dane JSON { "is_singleton": true }. Wówczas platforma Azure uruchomi tylko jedno wystąpienie zadania WebJob, nawet jeśli istnieje wiele wystąpień skojarzonej aplikacji internetowej. Ta technika może być przydatna w przypadku zaplanowanych zadań, które muszą być uruchamiane jako pojedyncze wystąpienie.

Następne kroki