Udostępnij za pośrednictwem

Zadania w tle

Wiele typów aplikacji wymaga zadań w tle, które są uruchamiane niezależnie od interfejsu użytkownika. Przykłady obejmują zadania wsadowe, intensywne zadania przetwarzania i długotrwałe procesy, takie jak przepływy pracy. Zadania w tle można wykonywać bez konieczności interakcji z użytkownikiem — aplikacja może uruchomić zadanie, a następnie kontynuować przetwarzanie interakcyjnych żądań od użytkowników. Może to pomóc zminimalizować obciążenie interfejsu użytkownika aplikacji, co może poprawić dostępność i skrócić interakcyjne czasy odpowiedzi.

Na przykład, jeśli aplikacja ma za zadanie generować miniatury obrazów przekazanych przez użytkowników, może to zrobić jako zadanie w tle i zapisać miniaturę w pamięci masowej po zakończenia procesu – bez potrzeby oczekiwania na ukończenie procesu. W ten sam sposób użytkownik składający zamówienie może zainicjować przepływ pracy w tle, który przetwarza zamówienie, a interfejs użytkownika umożliwia użytkownikowi kontynuowanie przeglądania aplikacji internetowej. Po zakończeniu zadania w tle można zaktualizować przechowywane dane zamówień i wysłać wiadomość e-mail do użytkownika, który potwierdzi zamówienie.

Podczas rozważania, czy zadanie ma zostać zaimplementowane jako zadanie w tle, głównymi kryteriami jest to, czy zadanie może być uruchamiane bez interakcji użytkownika i bez interfejsu użytkownika, który musi czekać na ukończenie zadania. Zadania, które wymagają od użytkownika lub interfejsu użytkownika oczekiwania na ich ukończenie, mogą nie być odpowiednie jako zadania w tle.

Typy zadań w tle

Zadania w tle zazwyczaj obejmują co najmniej jeden z następujących typów zadań:

  • Zadania intensywnie korzystające z procesora CPU, takie jak obliczenia matematyczne lub analiza modelu strukturalnego.
  • Zadania wymagające dużej liczby operacji wejścia/wyjścia, takie jak wykonywanie serii transakcji na potrzeby przechowywania danych lub indeksowania plików.
  • Zadania wsadowe, takie jak nocna aktualizacja 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, w których zadanie jest przekazywane do bezpieczniejszej lokalizacji do przetwarzania. Na przykład może nie być konieczne przetwarzanie poufnych danych w aplikacji internetowej. 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.

Wyzwalaczy

Zadania w tle można inicjować na kilka różnych sposobów. Należą one do jednej z następujących kategorii:

  • Wyzwalacze sterowane zdarzeniami. Zadanie jest uruchamiane w odpowiedzi na zdarzenie, zazwyczaj akcję wykonywaną przez użytkownika lub krok w przepływie pracy.
  • Wyzwalacze sterowane harmonogramem. Zadanie jest wywoływane zgodnie z harmonogramem na podstawie czasomierza. Może to być harmonogram cykliczny lub jednorazowe wywołanie zaprogramowane na późniejszy termin.

Wyzwalacze oparte na zdarzeniu

Wywołanie sterowane zdarzeniami używa wyzwalacza do uruchomienia zadania w tle. Przykłady użycia wyzwalaczy sterowanych zdarzeniami obejmują:

  • Interfejs użytkownika lub inne zadanie umieszcza komunikat w kolejce. Komunikat zawiera dane dotyczące wykonanej akcji, takiej jak użytkownik składający zamówienie. Proces w tle monitoruje tę kolejkę i wykrywa pojawienie się nowej wiadomości. Odczytuje komunikat i używa w nim danych jako danych wejściowych do zadania w tle. Ten wzorzec jest nazywany asynchroniczną komunikacją opartą na komunikatach.
  • Interfejs użytkownika lub inne zadanie zapisuje lub aktualizuje wartość w pamięci. Zadanie w tle monitoruje magazyn i wykrywa zmiany. Odczytuje dane i używa ich jako danych wejściowych do zadania w tle.
  • Interfejs użytkownika lub inne zadanie wysyła żądanie do punktu końcowego, takiego jak URI HTTPS, lub do interfejsu API udostępnianego jako usługa internetowa. Przekazuje dane wymagane do ukończenia zadania w tle, jako część żądania. Punkt końcowy lub usługa internetowa wywołuje zadanie w tle, które używa danych jako swoich danych wejściowych.

Typowe 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 oparte na harmonogramie

Wywołanie sterowane harmonogramem używa czasomierza do uruchomienia zadania w tle. Przykłady użycia wyzwalaczy opartych na harmonogramie obejmują:

  • 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, który powoduje wywołanie zadania w tle raz po określonym opóźnieniu czasu lub w określonym czasie.

Typowe przykłady zadań dostosowanych do wywołania opartego na harmonogramie obejmują procedury przetwarzania wsadowego (takie jak aktualizowanie list produktów powiązanych dla użytkownikó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, należy pamiętać o następujących kwestiach:

  • Jeśli wystąpienie obliczeniowe, które obsługuje harmonogram (takie jak maszyna wirtualna wykorzystująca zaplanowane zadania systemu Windows), zostanie skalowane/zwiększone, uruchomi się wiele równoczesnych wystąpień harmonogramu. Mogą one uruchamiać wiele wystąpień zadania. Aby uzyskać więcej informacji na ten temat, przeczytaj ten wpis w blogu o idempotence.
  • 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 jest nadal uruchomione.

Zwracanie wyników

Zadania w tle są wykonywane 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ą 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 nie czeka na ukończenie zadań. W związku z tym nie może automatycznie wykrywać po zakończeniu zadania.

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

  • Zapisz wartość wskaźnika stanu w pamięci dostępnej dla UI lub zadania wywołującego, które mogą monitorować lub sprawdzać tę wartość w razie potrzeby. Inne dane, które zadanie w tle musi zwrócić do wywołującego, można umieścić w tym samym magazynie.
  • Ustanów kolejkę odpowiedzi, na którą nasłuchuje interfejs użytkownika lub wywołujący. Zadanie w tle może wysyłać komunikaty do kolejki, które wskazują stan i zakończenie procesu. Dane, które zadanie w tle musi zwrócić do obiektu wywołującego, można umieścić w komunikatach. Jeśli używasz usługi Azure Service Bus, możesz użyć właściwości ReplyTo i CorrelationId , aby zaimplementować tę funkcję.
  • Udostępnij interfejs API lub punkt końcowy z zadania w tle, aby uzyskać dostęp do interfejsu użytkownika lub wywołującego, aby uzyskać informacje o stanie. Dane, które zadanie w tle musi zwrócić do obiektu wywołującego, mogą być zawarte w odpowiedzi.
  • Zadanie w tle powinno komunikować się z interfejsem użytkownika lub modułem wywołującym poprzez API w celu wskazywania stanu w określonych punktach lub po zakończeniu. Może to dotyczyć zdarzeń zgłaszanych lokalnie lub za pośrednictwem mechanizmu publikowania i subskrybowania. Dane, które zadanie w tle musi zwrócić do obiektu wywołującego, mogą być zawarte w treści żądania lub zdarzenia.

Środowisko hostingu

Zadania w tle można hostować przy użyciu różnych usług platformy Azure:

  • Azure Web Apps i WebJobs. Za pomocą zadań WebJob można wykonywać zadania niestandardowe na podstawie różnych typów 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. Inny przypadek to sytuacja, gdy obciążenie robocze jest już hostowane na planie usług App Service i jest niedostatecznie wykorzystywane.
  • Maszyny wirtualne platformy Azure. Jeśli masz usługę systemu Windows lub chcesz używać harmonogramu zadań systemu Windows, to często hostuje się zadania w tle na dedykowanej maszynie wirtualnej.
  • Azure Batch. Batch to usługa platformy, która planuje wykonywanie prac intensywnie korzystających z obliczeń w ramach zarządzanej kolekcji maszyn wirtualnych. Umożliwia 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.
  • Usługa 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.

Azure Web Apps i WebJobs

Za pomocą zadań WebJob platformy Azure można wykonywać zadania niestandardowe jako zadania w tle w aplikacji internetowej platformy Azure. Zadania WebJobs są uruchamiane w ramach aplikacji internetowej jako proces ciągły. WebJobs są również uruchamiane w odpowiedzi na zdarzenie wyzwalacza z usługi Azure Logic Apps lub zewnętrznych czynników, takich jak zmiany w blobach magazynowych i kolejkach komunikatów. Zadania 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 działania w przypadku błędów.

Kiedy konfigurujesz zadanie WebJob:

  • Jeśli chcesz, aby zadanie odpowiadało na wyzwalacz sterowany zdarzeniami, należy skonfigurować je jako Uruchamianie w sposób ciągły. 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, należy skonfigurować je jako Uruchom zgodnie z harmonogramem. Skrypt lub program jest przechowywany w folderze o nazwie site/wwwroot/app_data/jobs/triggered.
  • Jeśli podczas konfigurowania zadania zostanie wybrana opcja Uruchom na żądanie , po uruchomieniu wykona ten sam kod co opcja Uruchom zgodnie z harmonogramem .

Zadania WebJob platformy Azure są uruchamiane w piaskownicy aplikacji internetowej. Oznacza to, że mogą uzyskiwać dostęp do zmiennych środowiskowych i udostępniać informacje, takie jak parametry połączenia, za pomocą aplikacji internetowej. Zadanie ma dostęp do unikatowego identyfikatora maszyny, na którym uruchomiono zadanie. Parametr połączenia o nazwie AzureWebJobsStorage umożliwia dostęp do kolejek, obiektów blob i tabel usługi Azure Storage dla danych aplikacji oraz do usługi Service Bus na potrzeby obsługi komunikatów i komunikacji. Parametry połączenia o nazwie AzureWebJobsDashboard zapewniają dostęp do plików dziennika akcji zadania.

Zadania WebJob platformy Azure mają następujące cechy:

  • Zabezpieczenia: WebJobs są chronione przez poświadczenia wdrożeniowe aplikacji webowej.
  • Obsługiwane typy plików: WebJobs można definiować 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, .jar i 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 wyzwalanego wykonywania: site/wwwroot/app_data/jobs/triggered/{nazwa zadania}
    • W przypadku ciągłego wykonywania: site/wwwroot/app_data/jobs/continuous/{nazwa zadania}
  • Rejestrowanie: Obiekt Console.Out jest traktowany (oznaczany) jako INFO. Console.Error jest traktowany jako BŁĄD. Dostęp do informacji monitorowania i diagnostyki można uzyskać za pomocą witryny Azure Portal. Pliki dziennika można pobrać bezpośrednio z witryny. Są one zapisywane w następujących lokalizacjach:
    • W przypadku wyzwalanego wykonywania: Vfs/data/jobs/triggered/jobName
    • W przypadku ciągłego wykonywania: Vfs/data/jobs/continuous/jobName
  • Konfiguracja: zadania WebJob można skonfigurować przy użyciu portalu, interfejsu API REST i programu PowerShell. Możesz użyć pliku konfiguracji o nazwie settings.job w tym samym katalogu głównym co skrypt zadania, aby udostępnić informacje o konfiguracji zadania. Przykład:
    • { "stopping_wait_time": 60 }
    • { "is_singleton": true }

Rozważania

  • Domyślnie zadania WebJob są skalowane za pomocą aplikacji internetowej. Można jednak skonfigurować zadania do uruchamiania w jednym wystąpieniu, ustawiając właściwość konfiguracji is_singleton na true. WebJobs w pojedynczym wystąpieniu są przydatne dla zadań, które nie mają być skalowane ani uruchamiane jednocześnie jako wiele wystąpień, takich jak ponowne indeksowanie, analiza danych i podobne zadania.
  • 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.

Funkcje platformy Azure

Podobną opcją do zadań WebJob są 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.

Rozważania

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 mają być uruchamiane ciągle. 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 do zadań w tle, jeśli już na nim działa Twoje obciążenie. Jeśli masz nieużytkowane maszyny wirtualne, możesz uruchomić je na tej samej maszynie wirtualnej i współdzielić koszty obliczeń.

Aby uzyskać więcej informacji, zobacz następujące artykuły:

Maszyny wirtualne platformy Azure

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. Typowe przykłady to usługi systemu Windows, narzędzia innych firm i programy wykonywalne. Innym przykładem mogą być programy napisane dla środowiska wykonawczego, które różni się od hostowania aplikacji. Na przykład może to być program systemu Unix lub Linux, który chcesz wykonać z aplikacji systemu Windows lub .NET. Możesz wybrać spośród różnych systemów operacyjnych dla maszyny wirtualnej platformy Azure i uruchomić usługę lub plik wykonywalny na tej maszynie wirtualnej.

Aby ułatwić wybór, kiedy używać maszyn wirtualnych, zobacz Porównanie usług Azure App Services, Cloud Services i 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 Azure Virtual Machines Marketplace.

Aby zainicjować zadanie w tle na oddzielnej maszynie wirtualnej, masz szereg opcji:

  • Zadanie można wykonać na żądanie bezpośrednio z aplikacji, wysyłając żądanie do punktu końcowego uwidacznianego przez zadanie. Przekazuje to wszystkie dane wymagane przez zadanie. Ten punkt końcowy wywołuje zadanie.
  • Zadanie można skonfigurować do uruchamiania zgodnie z harmonogramem przy użyciu harmonogramu lub czasomierza dostępnego w wybranym systemie operacyjnym. Na przykład w systemie Windows można użyć harmonogramu zadań systemu Windows do wykonywania skryptów i zadań. Jeśli program SQL Server jest zainstalowany na maszynie wirtualnej, możesz użyć agenta programu SQL Server do wykonywania skryptów i zadań.
  • Za pomocą usługi Azure Logic Apps możesz zainicjować zadanie, dodając wiadomość do kolejki, na której nasłuchuje zadanie, lub wysyłając żądanie do interfejsu API udostępnianego przez zadanie.

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

Rozważania

Podczas podejmowania decyzji o wdrożeniu 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 zapewnia elastyczność i umożliwia precyzyjną kontrolę nad inicjowaniem, wykonywaniem, planowaniem i alokacją zasobów. Jednak zwiększy to koszt środowiska uruchomieniowego, jeśli maszyna wirtualna musi zostać wdrożona tylko w celu uruchamiania zadań w tle.
  • Nie ma możliwości monitorowania zadań w witrynie Azure Portal i nie ma możliwości automatycznego ponownego uruchamiania dla zadań, które zakończyły się niepowodzeniem— chociaż można monitorować podstawowy stan maszyny wirtualnej i zarządzać nią przy użyciu 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. Zazwyczaj użycie maszyny wirtualnej wymaga dodatkowego nakładu pracy w celu zaimplementowania mechanizmu, który zbiera dane z instrumentacji w zadaniu i z systemu operacyjnego na maszynie wirtualnej. Jednym z rozwiązań, które może być odpowiednie, jest użycie pakietu administracyjnego programu System Center dla platformy Azure.
  • Możesz rozważyć utworzenie sond monitorujących, które są udostępniane poprzez punkty końcowe HTTP. Kod dla tych sond może wykonywać kontrole kondycji, zbierać informacje operacyjne i statystyki — 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

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

Usługa Batch aprowizuje maszyny wirtualne, przypisuje zadania do maszyn wirtualnych, uruchamia zadania i monitoruje postęp. Usługa Batch może automatycznie skalować maszyny wirtualne w poziomie w odpowiedzi na obciążenie. Usługa Batch udostępnia również planowanie zadań. Usługa Azure Batch obsługuje maszyny wirtualne z systemami Linux i Windows.

Rozważania

Usługa Batch dobrze współpracuje z obciążeniami wewnętrznie równoległymi. Może również 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, które wymagają przekazywania komunikatów między węzłami.

Zadanie Azure Batch działa na puli węzłów (maszyn wirtualnych). Jedną z metod jest przydzielenie puli tylko w razie potrzeby, a następnie usunięcie jej po zakończeniu zadania. Pozwala to zmaksymalizować 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 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. Niektóre korzyści obejmują:

  • Kontenery obsługują hosting o wysokiej gęstości. Zadanie w tle można odizolować w kontenerze, umieszczając wiele kontenerów na każdej maszynie wirtualnej.
  • Orkiestrator kontenerów obsługuje wewnętrzne równoważenie obciążenia, konfigurowanie sieci wewnętrznej i inne zadania konfiguracji.
  • Kontenery można uruchamiać i zatrzymywać zgodnie z potrzebami.
  • Usługa Azure Container Registry umożliwia rejestrowanie kontenerów w granicach platformy Azure. Zapewnia to korzyści z bezpieczeństwa, prywatności i zbliżenia.

Rozważania

  • Wymaga zrozumienia, jak używać orkiestratora 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 (aplikacje kontenerowe Azure)

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

Rozważania

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 zacząć tworzyć swoją pierwszą aplikację kontenerową za pomocą szybkich startów.

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. Te czynniki pomogą Ci zdecydować, czy umieścić zadania przy istniejącym wystąpieniu obliczeniowym, czy utworzyć dla nich oddzielne wystąpienie obliczeniowe:

  • Dostępność: zadania w tle mogą nie wymagać takiego samego poziomu dostępności, jak inne części aplikacji, w szczególności interfejs użytkownika i inne części, które są bezpośrednio zaangażowane w interakcję użytkownika. Zadania w tle mogą być bardziej odporne 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łyby blokować kolejki i wpływać na całą aplikację.

  • 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ść: Niepowodzenie wystąpienia obliczeniowego, które hostuje tylko zadania w tle, może nie mieć krytycznego wpływu na aplikację jako całość, jeśli żądania dotyczące tych zadań można umieścić w kolejce lub odroczyć do momentu ponownego udostępnienia zadania. Jeśli wystąpienie obliczeniowe lub zadania można uruchomić ponownie w odpowiednim przedziale czasowym, użytkownicy aplikacji mogą nie odczuć wpływu.

  • Zabezpieczenia: zadania w tle mogą mieć inne wymagania dotyczące zabezpieczeń lub ograniczenia niż interfejs użytkownika lub inne części aplikacji. Używając oddzielnego wystąpienia obliczeniowego, można określić inne środowisko zabezpieczeń dla zadań. Można również użyć wzorców, takich jak Gatekeeper, aby odizolować wystąpienia obliczeniowe w tle od interfejsu użytkownika, aby zmaksymalizować bezpieczeństwo i separację.

  • Wydajność: możesz wybrać typ wystąpienia obliczeniowego dla zadań w tle, aby dokładnie dopasować wymagania dotyczące wydajności zadań podrzędnych. Może to oznaczać użycie tańszej opcji obliczeniowej, jeśli zadania nie wymagają tych samych możliwości przetwarzania co interfejs użytkownika lub większego wystąpienia, jeśli wymagają dodatkowej pojemności i zasobów.

  • Możliwość zarządzania: zadania w tle mogą mieć inny rytm programowania i wdrażania z głównego kodu aplikacji lub interfejsu użytkownika. Wdrażanie ich w osobnym wystąpieniu obliczeniowym może uprościć aktualizacje i przechowywanie wersji.

  • Koszt: dodawanie wystąpień obliczeniowych w celu wykonywania zadań w tle zwiększa koszty hostingu. Należy dokładnie rozważyć kompromis między dodatkową pojemnością a tymi 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, możliwe, że będą konkurować o dostęp do zasobów i usług, takich jak bazy danych i pamięć masowa. Ten współbieżny dostęp może spowodować rywalizację o zasoby, co może powodować konflikty dostępności usług i integralności danych w magazynie. Konflikt zasobów można rozwiązać, stosując podejście pesymistycznej blokady. Zapobiega to współbieżnym uzyskiwaniu dostępu do usługi przez konkurencyjne wystąpienia zadania lub uszkodzeniu danych.

Innym podejściem do rozwiązywania konfliktów jest zdefiniowanie zadań w tle jako singleton, aby zawsze była uruchomiona tylko jedna instancja. Jednak w ten sposób eliminowane są korzyści z niezawodności i wydajności, które może zapewnić konfiguracja z wieloma wystąpieniami. Jest to szczególnie istotne, jeśli interfejs użytkownika może dostarczyć wystarczającą pracę, aby zachować więcej niż jedno zadanie w tle zajęte.

Należy upewnić się, że zadanie w tle może być automatycznie uruchamiane ponownie i że ma wystarczającą pojemność, aby poradzić sobie ze szczytami zapotrzebowania. Można to osiągnąć, przydzielając wystąpienie obliczeniowe z wystarczającą ilością zasobów, implementując mechanizm kolejkowania, który może przechowywać żądania do późniejszego wykonania, gdy zapotrzebowanie się zmniejsza lub przy użyciu kombinacji tych technik.

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ń. W tych scenariuszach typowe jest podzielenie zadania na mniejsze dyskretne kroki lub podzadania, które mogą być wykonywane przez wielu użytkowników. Zadania wieloetapowe mogą być bardziej wydajne i bardziej elastyczne, ponieważ poszczególne kroki mogą być wielokrotnego użytku w wielu zadaniach. Można również łatwo dodawać, usuwać lub modyfikować kolejność kroków.

Koordynowanie wielu zadań i kroków może być trudne, ale istnieją trzy typowe wzorce, których można użyć do kierowania implementacją rozwiązania:

  • Dekompozycja zadania na wiele 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. Prostym, ale nieelastycznym podejściem do implementowania tej aplikacji może być wykonanie tego przetwarzania jako modułu monolitycznego. Jednak takie podejście może zmniejszyć możliwości refaktoryzacji kodu, optymalizacji go lub ponownego korzystania z niego, jeśli części tego samego przetwarzania są wymagane w innym miejscu w aplikacji. Aby uzyskać więcej informacji, zobacz Wzorzec potoków i filtrów.

  • Zarządzanie wykonywaniem 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). 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 schemat nadzorcy agenta planującego.

  • Zarządzanie przywracaniem kroków zadań, które nie powiodły się. Aplikacja może wymagać cofnięcia pracy wykonywanej przez serię kroków (które razem definiują ostatecznie spójną operację), jeśli co najmniej jeden krok 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, aby zapewnić niezawodne usługi aplikacji. 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ń należy rozważyć stosowanie punktów kontrolnych przez zapisanie stanu zadań w pamięci trwałej lub jako komunikaty w kolejce, jeśli jest to odpowiednie. Na przykład można utrwalać informacje o stanie w komunikacie w kolejce i przyrostowo aktualizować te informacje o stanie z postępem zadania, aby można było przetworzyć zadanie z ostatniego znanego dobrego punktu kontrolnego — zamiast ponownego uruchamiania od początku. Korzystając z kolejek usługi Azure Service Bus, możesz użyć sesji komunikatów, aby osiągnąć ten sam efekt. Sesje umożliwiają zapisywanie i pobieranie stanu 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.

  • Gdy kolejki są używane do komunikacji z zadaniami w tle, kolejki mogą pełnić rolę bufora w celu przechowywania żądań wysyłanych do zadań, gdy aplikacja ma ładunek niższy od zwykłego. Dzięki temu zadania nadrabiają zaległości w interfejsie użytkownika w mniej zajętych okresach. Oznacza to również, że ponowne uruchomienia nie będą blokować interfejsu użytkownika. Aby uzyskać więcej informacji, zobacz wzorzecQueue-Based równoważenia obciążenia. 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 przez komunikaty lub przetwarzają komunikaty, muszą być zaprojektowane tak, aby obsługiwały niespójności, takie jak komunikaty wychodzące z kolejności, komunikaty, które wielokrotnie powodują błąd (często nazywanych komunikatami trucizny) i komunikaty dostarczane więcej niż raz. Rozważ następujące kwestie:

    • Komunikaty, które muszą być przetwarzane w określonej kolejności, takie jak te, które zmieniają dane na podstawie istniejącej wartości danych (na przykład dodanie wartości do istniejącej wartości), mogą nie zostać dostarczone w oryginalnej kolejności, w której zostały wysłane. Alternatywnie mogą być obsługiwane przez różne instancje tego samego zadania w tle w innej kolejności ze względu na różny poziom obciążenia każdej instancji. Komunikaty, które muszą być przetwarzane w określonej kolejności, powinny zawierać numer sekwencji, klucz lub inny wskaźnik, za pomocą którego zadania w tle mogą być używane w celu zapewnienia, że są przetwarzane w odpowiedniej kolejności. Jeśli używasz usługi Azure Service Bus, możesz użyć sesji komunikatów, aby zagwarantować kolejność dostarczania. Jednak zwykle jest to bardziej wydajne, jeśli to możliwe, aby zaprojektować proces, aby kolejność komunikatów nie była ważna.

    • Zazwyczaj zadanie w tle podejrzy wiadomości w kolejce, co tymczasowo ukrywa je przed innymi konsumentami wiadomości. Następnie usuwa komunikaty po pomyślnym przetworzeniu. 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. Zostanie on przetworzony przez inne wystąpienie zadania lub podczas następnego cyklu przetwarzania tego wystąpienia. Jeśli komunikat stale powoduje błąd w odbiorcy, zablokuje zadanie, kolejkę i ostatecznie aplikację, gdy kolejka stanie się pełna. W związku z tym istotne jest detekcja i usuwanie wiadomości błędnych 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 są gwarantowane co najmniej raz w mechanizmach dostarczania, ale mogą dostarczać 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 zostanie ponownie udostępniony do przetworzenia. 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ą naturalnie idempotentne, takie jak ustawienie przechowywanej wartości na określoną nową wartość. Jednak operacje, takie jak dodanie wartości do istniejącej przechowywanej wartości bez sprawdzania, czy przechowywana wartość jest nadal taka sama, jak w przypadku, gdy wiadomość została pierwotnie wysłana, spowoduje niespójności. Kolejki usługi Azure Service Bus można skonfigurować do automatycznego usuwania zduplikowanych komunikatów. 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 Azure Queue Storage i kolejki Azure Service Bus, obsługują właściwość licznika odczytów z kolejki, która wskazuje, ile razy komunikat został odczytany z kolejki. Może to być przydatne w obsłudze powtarzających się i szkodliwych komunikatów. Aby uzyskać więcej informacji, zobacz Asynchronous Messaging Primer i Idempotency Patterns.

Zagadnienia dotyczące skalowania i wydajności

Zadania w tle muszą zapewnić wystarczającą wydajność, aby upewnić się, że nie blokują aplikacji lub powodują niespójności z powodu opóźnionej operacji, gdy system jest obciążony. Zazwyczaj wydajność jest poprawiana przez skalowanie wystąpień obliczeniowych hostujących zadania w tle. Podczas planowania i projektowania zadań w tle należy wziąć pod uwagę następujące kwestie dotyczące skalowalności i wydajności:

  • Platforma Azure obsługuje skalowanie automatyczne (skalowanie w pionie i skalowanie z powrotem) na podstawie bieżącego zapotrzebowania i obciążenia lub wstępnie zdefiniowanego harmonogramu w przypadku wdrożeń hostowanych w usłudze Web Apps i maszyn wirtualnych. Użyj tej funkcji, aby zapewnić, że aplikacja jako całość ma wystarczające możliwości wydajności, jednocześnie minimalizując koszty ś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. Może być również konieczne skalowanie kolejek składowania i innych zasobów, aby zapobiec powstaniu wąskiego gardła w jednym z punktów całego łańcucha przetwarzania. Należy również wziąć pod uwagę inne ograniczenia, takie jak maksymalna przepływność magazynu i inne usługi, na których polega aplikacja i zadania w tle.

  • Zadania w tle muszą być zaprojektowane pod kątem skalowania. Na przykład muszą być w stanie dynamicznie wykrywać liczbę używanych kolejek pamięci masowej w celu nasłuchiwania lub wysyłania komunikatów do odpowiedniej kolejki.

  • Domyślnie WebJobs skaluje się wraz z wystąpieniem skojarzonego z nim serwisu Azure 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 JSON { "is_singleton": true }. To powoduje, że Azure uruchamia wyłącznie jedno wystąpienie WebJob, nawet jeśli istnieje wiele instancji skojarzonej aplikacji internetowej. Może to być przydatna technika w przypadku zaplanowanych zadań, które muszą być uruchamiane jako pojedyncze wystąpienia.

Dalsze kroki