Edytuj

System multimediów w chmurze Gridwich

Azure Blob Storage
Azure Event Grid
Azure Functions
Azure Logic Apps

Potoki gridwich pozyskiwania, przetwarzania, przechowywania i dostarczania zasobów multimedialnych za pomocą dwóch nowych metod, kanapki usługi Azure Event Grid i kanapki programu Terraform.

Architektura

Architektura Gridwich zawiera dwie kanapki , które spełniają wymagania asynchronicznego przetwarzania zdarzeń i infrastruktury jako kodu:

  • Kanapka usługi Event Grid wyodrębnia zdalne i długotrwałe procesy, takie jak kodowanie multimediów z zewnętrznego systemu przepływu pracy sagi, dzieląc je między dwoma procedurami obsługi usługi Event Grid. Ta kanapka umożliwia systemowi zewnętrznego wysyłanie zdarzenia żądania, monitorowanie zaplanowanych zdarzeń i oczekiwanie na ostateczną odpowiedź powodzenia lub niepowodzenia, która może pojawić się kilka minut lub godzin później.

    Diagram showing the Event Grid handler sandwich.

    Pobierz plik programu Visio z tą architekturą.

  • Terraform Sandwich to wieloetapowy wzorzec narzędzia Terraform zaktualizowany w celu obsługi infrastruktury jako kodu. Oddzielenie wersji infrastruktury i oprogramowania oznacza, że aplikacja usługi Azure Functions musi zostać zwolniona i uruchomiona, zanim program Terraform będzie mógł wdrożyć subskrypcję usługi Event Grid. Aby rozwiązać to wymaganie, w potoku ciągłej integracji/ciągłego wdrażania istnieją dwa zadania narzędzia Terraform:

    Diagram showing the Terraform sandwich jobs.

    • Program Terraform 1 tworzy wszystkie zasoby z wyjątkiem subskrypcji usługi Azure Event Grid.
    • Narzędzie Terraform 2 tworzy subskrypcje usługi Event Grid po uruchomieniu oprogramowania.

    Dzięki temu program Terraform może w pełni zarządzać infrastrukturą rozwiązania i wdrażać ją, nawet jeśli nie wszystkie zasoby platformy Azure można utworzyć przed wdrożeniem artefaktów oprogramowania.

Przepływ pracy

Proces żądania i odpowiedzi usługi Gridwich obejmuje następujące żądania:

  • Tworzenie
  • Transport
  • Recepcji
  • Wysyłanie do składników gridwich
  • Potwierdzenie i akcje
  • Odpowiedzi

W poniższych krokach opisano proces żądania i odpowiedzi między systemem zewnętrznym a usługą Gridwich. W usłudze Gridwich system zewnętrzny jest systemem orkiestracji przepływu pracy MAM i saga. Aby uzyskać dokładne formaty zdarzeń komunikatów operacji gridwich, zobacz Gridwich message formats (Formaty komunikatów gridwich).

Diagram showing the Gridwich request-response process.

  1. System zewnętrzny tworzy żądanie i wysyła je do brokera żądań.

  2. Broker żądań jest odpowiedzialny za wysyłanie żądań do odbiorników żądań Gridwich w tradycyjnym modelu subskrypcji publikacji. W tym rozwiązaniu broker żądań to Azure Event Grid. Wszystkie żądania są hermetyzowane przy użyciu schematu zdarzeń usługi Event Grid.

  3. Aplikacja Gridwich Azure Functions używa zdarzeń z usługi Event Grid. W celu uzyskania lepszej przepływności usługa Gridwich definiuje punkt końcowy HTTP jako model wypychania inicjowany przez usługę Event Grid, a nie model sondowania powiązania usługi Event Grid zapewniany przez usługę Azure Functions.

  4. Aplikacja usługi Azure Functions odczytuje właściwości zdarzenia i wysyła zdarzenia do części kodu Gridwich obsługującego ten typ zdarzenia i wersję.

  5. Każda procedura obsługi, która będzie działać z bieżącym żądaniem, używa wspólnej klasy EventGridHandlerBase , aby natychmiast wysłać komunikat potwierdzenia po odebraniu żądania. Procedura obsługi wysyła następnie pracę do klasy pochodnej.

    Przepływy pracy żądań gridwich mogą być synchroniczne lub asynchroniczne w naturze. W przypadku żądań, które są łatwe do wykonania i szybkie do ukończenia, program obsługi synchronicznej wykonuje pracę i zwraca zdarzenie Powodzenie lub Niepowodzenie niemal natychmiast po wysłaniu potwierdzenia.

    W przypadku żądań długotrwałych program obsługi asynchronicznej ocenia żądanie, weryfikuje argumenty i inicjuje długotrwałą operację. Procedura obsługi zwraca następnie odpowiedź Zaplanowana, aby potwierdzić, że zażądała działania pracy. Po zakończeniu działania służbowego program obsługi żądań jest odpowiedzialny za dostarczenie zdarzenia Powodzenie lub Niepowodzenie zakończone dla pracy.

    Usługa publikacji zdarzeń komunikuje komunikaty o potwierdzeniu, niepowodzeniu, zaplanowanym lub powodzeniu do brokera żądań usługi Event Grid.

  6. Wydawca zdarzeń w funkcji platformy Azure wysyła zdarzenie odpowiedzi do tematu usługi Event Grid, który działa jako niezawodny broker komunikatów. System zewnętrzny subskrybuje temat i używa komunikatów. Platforma Event Grid udostępnia normalną logikę ponawiania prób publikacji w systemie zewnętrznym.

Kolejność komunikatów

Potwierdzenie poprzedza zarówno odpowiedzi Powodzenie, jak i Zaplanowane, jednak usługa Gridwich nie gwarantuje, że zaplanowana odpowiedź będzie zawsze poprzedzać odpowiednią odpowiedź Powodzenie. Prawidłową sekwencją odpowiedzi może być potwierdzony zaplanowany >> sukces lub Zaplanowany sukces potwierdzony >>.

Niepowodzenia żądań

Błędy żądań mogą być spowodowane przez nieprawidłowe żądania, brakujące warunki wstępne, błędy przetwarzania, wyjątki zabezpieczeń lub nieobsługiwane wyjątki. Prawie wszystkie błędy mają ten sam formularz komunikatu i zawierają oryginalną wartość kontekstu operacji. Typowa klasa EventGridHandlerBase zwykle wysyła odpowiedzi na błędy do usługi Event Grid za pośrednictwem interfejsu wydawcy zdarzeń funkcji platformy Azure. Aplikacja Szczegółowe informacje również rejestruje błędy za pośrednictwem rejestrowania strukturalnego.

Kontekst operacji

System zewnętrzny może generować tysiące żądań dziennie, na godzinę lub na sekundę. Każde zdarzenie żądania usługi Gridwich musi zawierać właściwość obiektu JSON o nazwie operationContext.

Jeśli żądanie zawiera kontekst operacji, taki jak {"id"="Op1001"}, każda odpowiedź Gridwich musi zawierać odpowiedni nieprzezroczystym kontekst operacji, niezależnie od tego, czy żądanie jest krótkotrwałe, czy długotrwałe. Ten kontekst operacji utrzymuje się przez okres istnienia nawet bardzo długotrwałych żądań.

Wymaganie odpowiedzi dotyczy "odpowiadającego" zamiast "tego samego" obiektu JSON. Funkcje gridwich, takie jak wyciszanie kontekstu, korzystają z faktu, że system zewnętrzny przetwarza zwrócony obiekt JSON w sposób od góry do dołu.

W szczególności system zewnętrzny ma:

  • Brak zależności od kolejności właściwości, więc Gridwich może wysłać obiekt z tymi samymi właściwościami, prawdopodobnie w innej kolejności. Na przykład {"a":1,"b":2} vs. {"b":2,"a":1}.

  • Brak problemu z dodatkowymi właściwościami, więc Gridwich, po otrzymaniu {"b":2,"a":1}polecenia , może prawidłowo zwrócić {"a":1,"b":2,"~somethingExtra":"yes"}. Aby zminimalizować możliwość kolizji, Gridwich prefiksuje nazwy dodanych właściwości z tyldą (~), na przykład ~muted.

  • Brak zależności formatowania JSON. Na przykład nie ma żadnych założeń dotyczących miejsca, w którym wypełnienie białych znaków może należeć do reprezentacji ciągu w formacie JSON. Gridwich wykorzystuje ten brak zależności formatowania przez kompresowanie niepotrzebnych białych znaków w reprezentacjach ciągów obiektów JSON. Zobacz JSONHelpers.SerializeOperationContext.

Uczestnicy sagi i kontekst operacji

W systemie orkiestracji sagi Gridwich każdy uczestnik sagi przyczynia się do co najmniej jednej działalności roboczej w systemie. Każdy uczestnik sagi działa niezależnie od innych uczestników, a więcej niż jeden uczestnik sagi może działać na pojedyncze żądanie.

Każdy uczestnik sagi musi zachować kontekst operacji, ale może go zaimplementować inaczej. Na przykład:

  • Krótkoterminowe operacje synchroniczne zachowują kontekst operacji.
  • Usługa Azure Storage udostępnia nieprzezroczystą właściwość ciągu wywoływaną ClientRequestId dla większości operacji.
  • Niektóre usługi mają Job.CorrelationData właściwość .
  • Inne interfejsy API chmury oferują podobne pojęcia do nieprzezroczystego kontekstu operacji, które mogą zwracać podczas sygnalizowania postępu, zakończenia lub awarii.

Aby uzyskać więcej informacji na temat sag i uczestników sagi, zobacz Orkiestracja Saga.

Programy obsługi synchronicznej i asynchronicznej

Każda procedura obsługi zdarzeń w systemie używa typowej klasy EventGridHandlerBase do świadczenia ogólnych usług, takich jak potwierdzenie żądania, obsługa błędów i publikacja zdarzeń odpowiedzi. Usługa publikacji zdarzeń komunikuje komunikaty o potwierdzeniu, niepowodzeniu, zaplanowanym lub powodzeniu do brokera żądań usługi Event Grid.

Każda procedura obsługi, która planuje pracować z bieżącym żądaniem, musi podać potwierdzenie po odebraniu żądania. Klasa bazowa natychmiast wysyła komunikat potwierdzenie, a następnie wysyła pracę do klasy pochodnej.

Diagram showing the Acknowledgment message flow.

Synchroniczne przetwarzanie zdarzeń

W przypadku żądań, które są łatwe do wykonania i szybkie do ukończenia, procedura obsługi wykonuje synchronicznie i zwraca zdarzenie Powodzenie z kontekstem operacji niemal natychmiast po wysłaniu potwierdzenia.

Diagram showing a synchronous request-response message flow..

Na przykład ChangeBlobTierHandler jest prostym synchronicznym przepływem. Procedura obsługi pobiera obiekt żądania transferu danych (DTO), wywołuje i oczekuje na pojedynczą usługę do wykonania tej pracy i zwraca odpowiedź Powodzenie lub Niepowodzenie.

Diagram showing the ChangeBlobTierHandler synchronous flow example.

Asynchroniczne przetwarzanie zdarzeń

Niektóre żądania są długotrwałe. Na przykład kodowanie plików multimedialnych może potrwać kilka godzin. W takich przypadkach asynchroniczna procedura obsługi żądań ocenia żądanie, weryfikuje argumenty i inicjuje długotrwałą operację. Procedura obsługi zwraca następnie odpowiedź Zaplanowana, aby potwierdzić, że zażądała działania pracy.

Diagram showing an asynchronous request-response message flow.

Po zakończeniu działania służbowego program obsługi żądań jest odpowiedzialny za dostarczenie zdarzenia Powodzenie lub Niepowodzenie zakończone dla pracy. Pozostając bezstanowy, program obsługi musi pobrać oryginalny kontekst operacji i umieścić go w ładunku komunikatu o zdarzeniu Ukończono.

Na przykład program BlobCopyHandler przedstawia prosty przepływ asynchroniczny. Procedura obsługi pobiera żądanie DTO, wywołuje i oczekuje na pojedynczą usługę w celu zainicjowania pracy i publikuje odpowiedź Zaplanowana lub Niepowodzenie.

Diagram showing the BlobCopyHandler asynchronous flow example with event scheduled.

Aby ukończyć długotrwały przepływ żądań, program BlobCreatedHandler używa zdarzenia Microsoft.Storage.BlobCreatedplatformy , wyodrębnia oryginalny kontekst operacji i publikuje odpowiedź na zakończenie powodzenia lub niepowodzenia.

Diagram showing the BlobCopyHandler asynchronous flow example with event successful.

Funkcje długotrwałe

Gdy usługa Gridwich wdraża nową aplikację usługi Functions, może ona usuwać bieżące długotrwałe procesy. Jeśli te procesy zakończą się nagle, nie ma stanu i nie ma raportu z powrotem do elementu wywołującego. Usługa Gridwich musi wdrażać nowe aplikacje usługi Functions, a jednocześnie bezpiecznie obsługiwać przejście dla długotrwałych funkcji i nie brakuje żadnych komunikatów.

Rozwiązanie musi:

  • Nie należy przechowywać stanu uruchomionych wystąpień aplikacji Gridwich.
  • Nie zabijaj procesów tylko dlatego, że coś nowego jest wdrażane lub nowy komunikat żąda tego samego działania.
  • Nie należy wywoływać żadnych dodatkowych obciążeń platformy Azure, takich jak Durable Functions, Functions Apps, Logic Apps lub Azure Container Instances.

Usługa Gridwich używa tokenów wdrażania i anulowania miejsca usługi Azure Functions, aby spełnić te wymagania dotyczące niezawodnych, długotrwałych funkcji.

Na poniższym diagramie pokazano, jak działają większość zadań gridwich. Zielone pole reprezentuje zadanie, które usługa Gridwich przekazuje do usługi zewnętrznej. Usługa Gridwich reaguje następnie w sposób sterowany zdarzeniami do stanu. Czerwone pole pokazuje funkcję, która jest długotrwała w samej usłudze Gridwich.

Diagram showing short-running and long-running functions.

Środowisko uruchomieniowe usługi Functions dodaje token anulowania po zamknięciu aplikacji. Usługa Gridwich wykrywa token i zwraca kody błędów dla wszystkich żądań i aktualnie uruchomionych procesów.

Wdrożenie miejsca wdraża nowe wersje oprogramowania. Miejsce produkcyjne ma uruchomioną aplikację, a miejsce przejściowe ma nową wersję. Platforma Azure wykonuje szereg kroków wdrażania, a następnie zamienia wystąpienia miejsca. Stare wystąpienie jest uruchamiane ponownie w ostatnim kroku procesu.

Gridwich czeka 30 sekund po ponownym mapowania nazw hostów, więc w przypadku funkcji wyzwalanych przez protokół HTTP usługa Gridwich gwarantuje co najmniej 30 sekund przed ponownym uruchomieniem starego miejsca produkcyjnego. Inne wyzwalacze mogą być kontrolowane przez ustawienia aplikacji, które nie mają mechanizmu oczekiwania na aktualizacje ustawień aplikacji. Te funkcje ryzykują przerwę w działaniu, jeśli wykonanie rozpoczyna się bezpośrednio przed ponownym uruchomieniem starego miejsca produkcyjnego.

Aby uzyskać więcej informacji, zobacz Co się dzieje podczas zamiany miejsca dla usług Azure Functions i Miejsc wdrożenia usługi Azure Functions.

Elementy

Rozwiązanie przetwarzania multimediów Gridwich korzysta z usług Azure Event Grid, Azure Functions, Azure Blob Storage, Azure Logic Apps i Azure Key Vault. Procesy orkiestracji ciągłej integracji/ciągłego wdrażania i sagi używają usług Azure Repos, Azure Pipelines i Terraform.

  • Usługa Azure Event Grid zarządza routingiem zdarzeń usługi Gridwich z dwoma zadaniami usługi Event Grid, które umożliwiają asynchroniczne przetwarzanie zdarzeń multimediów. Event Grid to wysoce niezawodny punkt końcowy dostarczania żądań. Platforma Azure zapewnia niezbędny czas pracy i stabilność punktu końcowego dostarczania żądań.

    Gridwich hermetyzuje zdarzenia w obiekcie właściwości schematuEvent.Data usługi Event Grid, który jest nieprzezroczystym dla brokera usługi Event Grid i warstwy transportu. Gridwich używa eventType również pól obiektów i dataVersion do kierowania zdarzeń. Aby broker żądań usługi Event Grid mógł zostać zastąpiony innymi brokerami zdarzeń subskrypcji publikacji, usługa Gridwich zależy od najmniejszych pól zdarzeń i nie używa topic pól lub subject .

  • Usługa Azure Functions umożliwia uruchamianie kodu wyzwalanego przez zdarzenia bez konieczności jawnego aprowizowania infrastruktury ani zarządzania nią. Gridwich to aplikacja usługi Azure Functions, która hostuje wykonywanie różnych funkcji.

  • Usługa Azure Blob Storage zapewnia skalowalny, ekonomiczny magazyn w chmurze i dostęp do danych bez struktury, takich jak zasoby multimedialne. Usługa Gridwich używa blokowych obiektów blob i kontenerów usługi Azure Storage.

  • Usługa Azure Key Vault chroni klucze kryptograficzne, hasła i inne wpisy tajne używane przez platformę Azure i aplikacje i usługi innych firm.

  • Azure DevOps to zestaw usług deweloperskich i operacyjnych, w tym repozytoriów kodu opartych na usłudze Git oraz zautomatyzowanych potoków kompilacji i wydań, które integrują się z platformą Azure. Usługa Gridwich używa usługi Azure Repos do przechowywania i aktualizowania projektów kodu oraz usługi Azure Pipelines na potrzeby ciągłej integracji/ciągłego wdrażania i innych przepływów pracy.

  • Terraform to narzędzie typu open source, które używa infrastruktury jako kodu do aprowizowania infrastruktury i usług oraz zarządzania nimi.

Alternatywy

  • Rozszerzenie Durable Functions, które ma wbudowany magazyn stanów dla długotrwałych operacji, może również zapewnić nieprzezroczystym kontekst operacji. Rozszerzenie Durable Functions może utworzyć serię zadań w ramach operacji i zapisać kontekst operacji jako dane wejściowe lub wyjściowe dla operacji. W rzeczywistości usługa Gridwich może używać rozszerzenia Durable Functions dla wszystkich działań służbowych, ale takie podejście zwiększy złożoność kodu.

  • Można osiągnąć lepsze oddzielenie od infrastruktury usługi Event Grid, refaktoryzując bazę EventGridHandlerBase do RequestHandlerBaseelementu i usuwając wszelkie powiązania z obiektami lub typami usługi Event Grid. Ta refaktoryzowana klasa będzie obsługiwać tylko podstawowe obiekty DTO, a nie w typach obiektów specyficznych dla transportu. Podobnie usługa IEventGridDispatcher może stać się IResponseDispatcher elementem z określoną EventGridDispatcher implementacją.

  • Biblioteka Gridwich.SagaParticipants.Storage.AzureStorage zawiera również usługi magazynu używane przez innych uczestników sagi. Posiadanie interfejsów w podstawowym projekcie pozwala uniknąć problemów z inwersją kontroli (IoC), ale można wyodrębnić interfejsy do oddzielnej podstawowej biblioteki bramy infrastruktury magazynu.

  • Aplikacja Gridwich Functions używa iniekcji zależności do rejestrowania co najmniej jednego programu obsługi żądań dla określonych typów zdarzeń i wersji danych. Aplikacja wprowadza element EventGridDispatcher z kolekcją programów obsługi zdarzeń usługi Event Grid, a dyspozytor wysyła zapytania do procedur obsługi w celu określenia, które z nich będą przetwarzać zdarzenie.

    Alternatywnie można użyć mechanizmu subskrypcji zdarzeń i filtrowania zapewnianego przez platformę Event Grid. Ten mechanizm nakłada model wdrażania 1:1, w którym jedna funkcja platformy Azure hostuje tylko jedną procedurę obsługi zdarzeń. Chociaż usługa Gridwich korzysta z modelu 1:wielu, jego czysta architektura oznacza, że refaktoryzacja rozwiązania dla wersji 1:1 nie byłaby trudna.

  • Aby uzyskać alternatywną mikrousługę, a nie monolityczną architekturę Gridwich, zobacz Alternatywa mikrousług.

Szczegóły scenariusza

Znany konglomerat mediów masowych i rozrywkowych zastąpił swoją lokalną usługę przesyłania strumieniowego wideo za pomocą opartego na chmurze rozwiązania do pozyskiwania, przetwarzania i publikowania zasobów wideo. Głównymi celami firmy było wykorzystanie pojemności, kosztów i elastyczności chmury platformy Azure:

  • Pozyskiwanie nieprzetworzonych plików wideo, przetwarzanie i publikowanie ich oraz wypełnianie żądań multimediów.
  • Usprawnij zarówno kodowanie, jak i nowe możliwości wprowadzania i dystrybucji na dużą skalę, oraz przy użyciu czysto zaprojektowanego podejścia.
  • Zaimplementuj ciągłą integrację i ciągłe dostarczanie (CI/CD) dla potoku zarządzania zasobami multimedialnymi (MAM).

Aby osiągnąć te cele, zespół inżynierów firmy Microsoft opracował gridwich, bezstanową strukturę przetwarzania zdarzeń opartą na zewnętrznym systemie aranżacji przepływu pracy sagi.

Potencjalne przypadki użycia

Zespół inżynierów opracował usługę Gridwich, aby dostosować się do zasad i standardów branżowych dla:

System Gridwich zawiera najlepsze rozwiązania dotyczące przetwarzania i dostarczania zasobów multimedialnych na platformie Azure. Mimo że system Gridwich jest specyficzny dla nośnika, struktura przetwarzania komunikatów i zdarzeń może być stosowana do dowolnego bezstanowego przepływu pracy przetwarzania zdarzeń.

Wdrażanie tego scenariusza