Pojęcia dotyczące przestrzeni nazw usługi Azure Event Grid

  • Artykuł

W tym artykule przedstawiono główne pojęcia i funkcje związane z tematami przestrzeni nazw.

Zdarzenia

Zdarzenie to najmniejsza ilość informacji, które w pełni opisują coś, co wydarzyło się w systemie. Często odnosimy się do zdarzenia jako odrębnego zdarzenia, ponieważ reprezentuje on odrębny, samodzielny fakt dotyczący systemu, który zapewnia wgląd, który może być możliwy do działania. Każde zdarzenie ma typowe informacje, takie jak source zdarzenie, time miało miejsce zdarzenie i unikatowy identyfikator. Zdarzenie ma również typewartość , która zazwyczaj jest unikatowym identyfikatorem opisujący rodzaj ogłoszenia, dla którego jest używane zdarzenie.

Na przykład zdarzenie dotyczące tworzenia nowego pliku w usłudze Azure Storage zawiera szczegóły pliku, takie jak wartość lastTimeModified. Zdarzenie usługi Event Hubs ma adres URL przechwyconego pliku. Zdarzenie o nowej kolejności w mikrousłudze Orders może mieć orderId atrybut i atrybut ADRESU URL do reprezentacji stanu zamówienia. Oto kilka innych przykładów typów zdarzeń: com.yourcompany.Orders.OrderCreated, org.yourorg.GeneralLedger.AccountChanged, io.solutionname.Auth.MaximumNumberOfUserLoginAttemptsReached.

Oto przykładowe zdarzenie:

{
    "specversion" : "1.0",
    "type" : "com.yourcompany.order.created",
    "source" : "/orders/account/123",
    "subject" : "O-28964",
    "id" : "A234-1234-1234",
    "time" : "2018-04-05T17:31:00Z",
    "comexampleextension1" : "value",
    "comexampleothervalue" : 5,
    "datacontenttype" : "application/json",
    "data" : {
       "orderId" : "O-28964",
       "URL" : "https://com.yourcompany/orders/O-28964"
    }
}

Inny rodzaj zdarzenia

Społeczność użytkowników odnosi się również jako "zdarzenia" do komunikatów zawierających punkt danych, takich jak odczyt pojedynczego urządzenia lub kliknięcie strony aplikacji internetowej. Tego rodzaju zdarzenie jest zwykle analizowane w przedziale czasu w celu uzyskania szczegółowych informacji i podjęcia akcji. W dokumentacji usługi Event Grid odwołujemy się do tego rodzaju zdarzenia jako punktu danych, danych przesyłanych strumieniowo lub po prostu jako telemetrii. Wśród innych typów komunikatów tego rodzaju zdarzenia są używane z funkcją brokera usługi Event Grid do kolejkowania komunikatów telemetrycznych (MQTT).

CloudEvents

Tematy dotyczące przestrzeni nazw usługi Event Grid akceptują zdarzenia zgodne z otwartą standardową specyfikacją CloudEvents CloudEvents 1.0 przy użyciu powiązania protokołu HTTP z formatem JSON. CloudEvent to rodzaj komunikatu, który zawiera informacje, które są przekazywane, nazywane danymi zdarzenia i metadanymi. Dane zdarzenia w architekturach opartych na zdarzeniach zwykle zawierają informacje ogłaszające zmianę stanu systemu. Metadane CloudEvents składają się z zestawu atrybutów, które zapewniają kontekstowe informacje o wiadomości, takie jak miejsce jego utworzenia (system źródłowy), jego typ itp. Wszystkie prawidłowe komunikaty zgodne ze specyfikacjami CloudEvents muszą zawierać następujące wymagane atrybuty kontekstu:

Specyfikacja CloudEvents definiuje również opcjonalne i rozszerzenia atrybuty kontekstu, które można uwzględnić podczas korzystania z usługi Event Grid.

W przypadku korzystania z usługi Event Grid usługa CloudEvents jest preferowanym formatem zdarzeń ze względu na dobrze udokumentowane przypadki użycia (tryby przesyłania zdarzeń, formatów zdarzeń itp.), rozszerzalność i ulepszoną współdziałanie. Rozwiązanie CloudEvents poprawia współdziałanie, zapewniając wspólny format zdarzeń do publikowania i korzystania z zdarzeń. Umożliwia to jednolite narzędzia i standardowe sposoby routingu i obsługi zdarzeń.

CloudEvents con tryb namiotu s

Specyfikacja CloudEvents definiuje trzy con tryb namiotu s: binarne, ustrukturyzowane i wsadowe.

Ważne

Z dowolnym con tryb namiotu można wymieniać tekst (JSON, tekst/*itp.) lub dane zdarzenia zakodowane binarnie. Plik binarny con tryb namiotu nie jest używany wyłącznie do wysyłania danych binarnych.

Con tryb namiotu s nie dotyczy kodowania używanego, binarnego lub tekstowego, ale o tym, jak są opisywane i wymieniane dane zdarzenia i jego metadane. Struktura con tryb namiotu używa pojedynczej struktury, na przykład obiektu JSON, gdzie zarówno atrybuty kontekstu, jak i dane zdarzenia są razem w ładunku HTTP. Binarny con tryb namiotu oddziela atrybuty kontekstu, które są mapowane na nagłówki HTTP i dane zdarzeń, które są ładunkiem HTTP zakodowanym zgodnie z typem nośnika ustawionym w pliku Content-Type.

Obsługa rozwiązania CloudEvents

W tej tabeli przedstawiono bieżącą obsługę specyfikacji CloudEvents:

CloudEvents con tryb namiotu Obsługiwane?
Ustrukturyzowany kod JSON Tak
Dane JSON ze strukturą wsadowe Tak, w przypadku zdarzeń publikowania
Binarnym Tak, w przypadku zdarzeń publikowania

Maksymalny dozwolony rozmiar zdarzenia to 1 MB. Zdarzenia powyżej 64 KB są naliczane w przyrostach 64 KB.

Konsrukturyzowane tryb namiotu

Komunikat w usłudze CloudEvents ze strukturą con tryb namiotu zawiera zarówno atrybuty kontekstu, jak i dane zdarzenia w ładunku HTTP.

Ważne

Obecnie usługa Event Grid obsługuje format JSON CloudEvents z protokołem HTTP.

Oto przykład rozwiązania CloudEvents w trybie ustrukturyzowanym przy użyciu formatu JSON. Oba metadane (wszystkie atrybuty, które nie są "danymi"), a dane komunikatu/zdarzenia (obiekt "dane") są opisane przy użyciu formatu JSON. Nasz przykład zawiera wszystkie wymagane atrybuty kontekstu wraz z niektórymi atrybutami opcjonalnymi (subject, time, i ) i datacontenttypeatrybutami rozszerzenia (comexampleextension1, comexampleothervalue).

{
    "specversion" : "1.0",
    "type" : "com.yourcompany.order.created",
    "source" : "/orders/account/123",
    "subject" : "O-28964",
    "id" : "A234-1234-1234",
    "time" : "2018-04-05T17:31:00Z",
    "comexampleextension1" : "value",
    "comexampleothervalue" : 5,
    "datacontenttype" : "application/json",
    "data" : {
       "orderId" : "O-28964",
       "URL" : "https://com.yourcompany/orders/O-28964"
    }
}

Format JSON z zawartością ustrukturyzowaną umożliwia wysyłanie danych zdarzeń, które nie są wartością JSON. W tym celu należy wykonać następujące czynności:

  1. Dołącz atrybut z typem datacontenttype nośnika, w którym dane są kodowane.
  2. Jeśli typ nośnika jest zakodowany w formacie tekstowym, na przykład text/plain, text/csvlub application/xml, należy użyć data atrybutu z ciągiem JSON zawierającym to, co komunikujesz jako wartość.
  3. Jeśli typ nośnika reprezentuje kodowanie binarne, należy użyć data_base64 atrybutu, którego wartość jest ciągiem JSON zawierającym zakodowaną wartość binarną BASE64.

Na przykład to rozwiązanie CloudEvent przenosi dane zdarzenia zakodowane w programie w application/protobuf celu wymiany komunikatów Protobuf.

{
    "specversion" : "1.0",
    "type" : "com.yourcompany.order.created",
    "source" : "/orders/account/123",
    "id" : "A234-1234-1234",
    "time" : "2018-04-05T17:31:00Z",
    "datacontenttype" : "application/protobuf",
    "data_base64" : "VGhpcyBpcyBub3QgZW5jb2RlZCBpbiBwcm90b2J1ZmYgYnV0IGZvciBpbGx1c3RyYXRpb24gcHVycG9zZXMsIGltYWdpbmUgdGhhdCBpdCBpcyA6KQ=="
}

Aby uzyskać więcej informacji na temat używania atrybutów data lub data_base64 , zobacz Obsługa danych .

Aby uzyskać więcej informacji na temat tego con tryb namiotu, zobacz CloudEvents HTTP structured con tryb namiotu specifications .

Batched con tryb namiotu

Usługa Event Grid obsługuje obecnie kod JSON wsadowy con tryb namiotu podczas publikowania usługi CloudEvents w usłudze Event Grid. Ten con tryb namiotu używa tablicy JSON wypełnionej biblioteką CloudEvents w strukturze con tryb namiotu. Na przykład aplikacja może publikować dwa zdarzenia przy użyciu tablicy podobnej do poniższej. Podobnie jeśli używasz zestawu SDK płaszczyzny danych usługi Event Grid, ten ładunek jest również wysyłany:

[
    {
        "specversion": "1.0",
        "id": "E921-1234-1235",
        "source": "/mycontext",
        "type": "com.example.someeventtype",
        "time": "2018-04-05T17:31:00Z",
        "data": "some data"
    },
    {
        "specversion": "1.0",
        "id": "F555-1234-1235",
        "source": "/mycontext",
        "type": "com.example.someeventtype",
        "time": "2018-04-05T17:31:00Z",
        "data": {
            "somekey" : "value",
            "someOtherKey" : 9
        }
    }
]

Aby uzyskać więcej informacji, zobacz CloudEvents Batched Content Mode specs (Specyfikacje trybu zawartości wsadowej w usłudze CloudEvents).

Dzielenie na partie

Aplikacja powinna wsadować kilka zdarzeń razem w tablicy, aby uzyskać większą wydajność i większą przepływność przy użyciu pojedynczego żądania publikowania. Partie mogą wynosić do 1 MB, a maksymalny rozmiar zdarzenia to 1 MB.

Binarne con tryb namiotu

Element CloudEvent w pliku binarnym con tryb namiotu ma atrybuty kontekstu opisane jako nagłówki HTTP. Nazwy nagłówków HTTP są nazwą atrybutu kontekstu poprzedzonego prefiksem ce-. Nagłówek Content-Type odzwierciedla typ nośnika, w którym dane zdarzenia są kodowane.

Ważne

W przypadku korzystania z pliku binarnego con tryb namiotu ce-datacontenttype nagłówek HTTP NIE MOŻE być również obecny.

Ważne

Jeśli planujesz uwzględnić własne atrybuty (tj. atrybuty rozszerzenia) podczas używania znaku binarnego con tryb namiotu, upewnij się, że ich nazwy składają się z małych liter ("a" do "z") lub cyfr ('0' do '9') z znaku ASCII i że nie przekraczają 20 znaków. Oznacza to, że konwencja nazewnictwa atrybutów kontekstu CloudEvents jest bardziej restrykcyjna niż w przypadku prawidłowych nazw nagłówków HTTP. Nie każda prawidłowa nazwa nagłówka HTTP jest prawidłową nazwą atrybutu rozszerzenia.

Ładunek HTTP to dane zdarzenia zakodowane zgodnie z typem nośnika w pliku Content-Type.

Żądanie HTTP używane do publikowania elementu CloudEvent w trybie binarnym zawartości może wyglądać następująco:

POST / HTTP/1.1
HOST mynamespace.eastus-1.eventgrid.azure.net/topics/mytopic
ce-specversion: 1.0
ce-type: com.example.someevent
ce-source: /mycontext
ce-id: A234-1234-1234
ce-time: 2018-04-05T17:31:00Z
ce-comexampleextension1: value
ce-comexampleothervalue: 5
content-type: application/protobuf

Binary data according to protobuf encoding format. No context attributes are included.

Kiedy należy używać konsumentu binarnego lub strukturalnego rozwiązania CloudEvents tryb namiotu

Możesz użyć struktury con tryb namiotu jeśli potrzebujesz prostego podejścia do przekazywania rozwiązania CloudEvents między przeskokami i protokołami. Ponieważ rozwiązanie CloudEvent w strukturze con tryb namiotu zawiera komunikat wraz z metadanymi, łatwo jest klientom używać go jako całości i przekazywać go do innych systemów.

Możesz użyć funkcji con tryb namiotu jeśli wiesz, że aplikacje podrzędne wymagają tylko komunikatu bez dodatkowych informacji (czyli atrybutów kontekstu). Mimo że ze strukturą con tryb namiotu nadal można pobrać dane zdarzenia (komunikat) z rozwiązania CloudEvent, łatwiej jest, jeśli aplikacja konsumenta po prostu znajduje się w ładunku HTTP. Na przykład inne aplikacje mogą używać innych protokołów i mogą być zainteresowane tylko podstawowym komunikatem, a nie jego metadanymi. W rzeczywistości metadane mogą być istotne tylko dla natychmiastowego pierwszego przeskoku. W takim przypadku posiadanie danych, które mają być wymieniane poza jego metadanymi, ułatwia obsługę i przekazywanie.

Wydawcy

Wydawca to aplikacja, która wysyła zdarzenia do usługi Event Grid. Może to być ta sama aplikacja, z której pochodzą zdarzenia, źródło zdarzeń. Zdarzenia z własnej aplikacji można publikować w tematach przestrzeni nazw.

Źródła zdarzeń

Źródłem zdarzeń jest miejsce, w którym odbywa się zdarzenie. Każde źródło zdarzeń obsługuje co najmniej jeden typ zdarzenia. Na przykład aplikacja jest źródłem zdarzeń niestandardowych, które definiuje system. W przypadku korzystania z tematów przestrzeni nazw obsługiwane źródła zdarzeń są własnymi aplikacjami.

Przestrzenie nazw

Przestrzeń nazw usługi Event Grid jest kontenerem zarządzania dla następujących zasobów:

Zasób Obsługiwany protokół
Tematy dotyczące przestrzeni nazw HTTP
Miejsca do tematów MQTT
Klienci MQTT
Grupy klientów MQTT
Certyfikaty urzędu certyfikacji MQTT
Powiązania uprawnień MQTT

Dzięki przestrzeni nazw usługi Azure Event Grid możesz grupować powiązane zasoby i zarządzać nimi jako pojedynczą jednostką w ramach subskrypcji platformy Azure. Zapewnia unikatową w pełni kwalifikowaną nazwę domeny (FQDN).

Przestrzeń nazw uwidacznia dwa punkty końcowe:

  • Punkt końcowy HTTP obsługujący ogólne wymagania dotyczące obsługi komunikatów przy użyciu tematów przestrzeni nazw.
  • Punkt końcowy MQTT dla komunikatów IoT lub rozwiązań korzystających z protokołu MQTT.

Przestrzeń nazw zapewnia również zintegrowane z systemem DNS punkty końcowe sieci. Zapewnia również szereg funkcji kontroli dostępu i zarządzania integracją sieci, takich jak filtrowanie publicznych adresów IP i łącza prywatne. Jest to również kontener tożsamości zarządzanych używanych dla zawartych zasobów w przestrzeni nazw.

Oto kilka dodatkowych kwestii dotyczących przestrzeni nazw:

  • Przestrzeń nazw to śledzony zasób z właściwościami tags i location , a po jego utworzeniu można go znaleźć na stronie resources.azure.com.
  • Nazwa przestrzeni nazw może mieć długość od 3 do 50 znaków. Może zawierać alfanumeryczne i łączniki(-) i bez spacji.
  • Nazwa musi być unikatowa dla każdego regionu.
  • Bieżące obsługiwane regiony: Środkowe stany USA, Azja Wschodnia, Wschodnie stany USA, Wschodnie stany USA 2, Europa Północna, Południowo-środkowe stany USA, Azja Południowo-Wschodnia, Europa Północna, Europa Zachodnia, Zachodnie stany USA 2, Zachodnie stany USA 3.

Jednostki przepływności

Jednostki przepływności definiują pojemność szybkości zdarzeń ruchu przychodzącego i wychodzącego w przestrzeniach nazw. Aby uzyskać więcej informacji, zobacz Limity przydziału i limity usługi Azure Event Grid.

Tematy

Temat zawiera zdarzenia, które zostały opublikowane w usłudze Event Grid. Zazwyczaj używasz zasobu tematu do zbierania powiązanych zdarzeń. Często określamy tematy w przestrzeni nazw jako tematy przestrzeni nazw.

Tematy dotyczące przestrzeni nazw

Tematy przestrzeni nazw to tematy tworzone w przestrzeni nazw usługi Event Grid. Aplikacja publikuje zdarzenia w punkcie końcowym przestrzeni nazw HTTP, określając temat przestrzeni nazw, w którym publikowane zdarzenia są logicznie zawarte. Podczas projektowania aplikacji musisz zdecydować, ile tematów należy utworzyć. W przypadku stosunkowo dużych rozwiązań utwórz temat przestrzeni nazw dla każdej kategorii powiązanych zdarzeń. Rozważmy na przykład aplikację, która zarządza kontami użytkowników i inną aplikacją dotyczącą zamówień klientów. Jest mało prawdopodobne, że wszyscy subskrybenci zdarzeń chcą zdarzeń z obu aplikacji. Aby rozdzielić obawy, utwórz dwa tematy przestrzeni nazw: jeden dla każdej aplikacji. Pozwól użytkownikom zdarzeń subskrybować temat zgodnie z ich wymaganiami. W przypadku małych rozwiązań możesz wolisz wysyłać wszystkie zdarzenia do jednego tematu.

Tematy dotyczące przestrzeni nazw obsługują dostarczanie ściągania i dostarczanie wypychane. Zobacz , kiedy używać dostarczania ściągania lub wypychania, aby pomóc w podjęciu decyzji, czy dostarczanie ściągnięcia jest właściwym podejściem, biorąc pod uwagę wymagania.

Subskrypcje zdarzeń

Subskrypcja zdarzeń to zasób konfiguracji skojarzony z jednym tematem. Między innymi używasz subskrypcji zdarzeń, aby ustawić kryteria wyboru zdarzeń, aby zdefiniować kolekcję zdarzeń dostępną dla subskrybenta z całkowitego zestawu zdarzeń dostępnych w temacie. Zdarzenia można filtrować zgodnie z wymaganiami subskrybenta. Można na przykład filtrować zdarzenia według ich typu zdarzenia. Można również zdefiniować kryteria filtrowania we właściwościach danych zdarzenia, jeśli jako wartość właściwości danych jest używany obiekt JSON. Aby uzyskać więcej informacji na temat właściwości zasobów, poszukaj operacji płaszczyzny sterowania w interfejsie API REST usługi Event Grid.

Diagram przedstawiający temat i skojarzone subskrypcje zdarzeń.

Aby zapoznać się z przykładem tworzenia subskrypcji dla tematów przestrzeni nazw, zobacz Publikowanie i używanie komunikatów przy użyciu tematów przestrzeni nazw przy użyciu interfejsu wiersza polecenia.

Uwaga

Subskrypcje zdarzeń w temacie przestrzeni nazw zawierają uproszczony model zasobów w porównaniu z subskrypcjami niestandardowymi, domenami, partnerami i systemami (Event Grid Basic). Aby uzyskać więcej informacji, zobacz Tworzenie, wyświetlanie subskrypcji zdarzeń i zarządzanie nimi.

Dostarczanie ściągnięcia

Dzięki dostarczaniu ściągnięcia aplikacja łączy się z usługą Event Grid w celu odczytywania komunikatów przy użyciu semantyki przypominającej kolejkę. Gdy aplikacje łączą się z usługą Event Grid w celu korzystania ze zdarzeń, są one pod kontrolą szybkości zużycia zdarzeń i jego chronometrażu. Aplikacje konsumenckie mogą również używać prywatnych punktów końcowych podczas nawiązywania połączenia z usługą Event Grid w celu odczytywania zdarzeń przy użyciu prywatnej przestrzeni IP.

Dostarczanie ściągania obsługuje następujące operacje odczytywania komunikatów i kontrolowania stanu komunikatów: odbieranie, potwierdzanie, zwalnianie, odrzucanie i odnawianie blokady. Aby uzyskać więcej informacji, zobacz Omówienie dostarczania ściągnięcia.

Kształt danych podczas odbierania zdarzeń przy użyciu dostarczania ściągnięcia

Podczas dostarczania zdarzeń przy użyciu dostarczania ściągania usługa Event Grid zawiera tablicę obiektów, które z kolei zawierają obiekty event i brokerProperties . Wartość właściwości zdarzenia to CloudEvent dostarczona ze strukturą con tryb namiotu. Obiekt brokerProperties zawiera token blokady skojarzony z dostarczonym rozwiązaniem CloudEvent. Następujący obiekt json to przykładowa odpowiedź z operacji odbierania, która zwraca dwa zdarzenia:

{
    "value": [
        {
            "brokerProperties": {
                "lockToken": "CiYKJDUwNjE4QTFFLUNDODQtNDZBQy1BN0Y4LUE5QkE3NjEwNzQxMxISChDXYS23Z+5Hq754VqQjxywE",
                "deliveryCount": 2
            },
            "event": {
                "specversion": "1.0",
                "id": "A234-1234-1235",
                "source": "/mycontext",
                "time": "2018-04-05T17:31:00Z",
                "type": "com.example.someeventtype",
                "data": "some data"
            }
        },
        {
            "brokerProperties": {
                "lockToken": "CiYKJDUwNjE4QTFFLUNDODQtNDZBQy1BN0Y4LUE5QkE3NjEwNzQxMxISChDLeaL+nRJLNq3/5NXd/T0b",
                "deliveryCount": 1
            },
            "event": {
                "specversion": "1.0",
                "id": "B688-1234-1235",
                "source": "/mycontext",
                "type": "com.example.someeventtype",
                "time": "2018-04-05T17:31:00Z",
                "data": {
                    "somekey" : "value",
                    "someOtherKey" : 9
                }
            }
        }
    ]
}

Dostarczanie wypychane

Usługa Event Grid wysyła zdarzenia do miejsca docelowego skonfigurowanego w subskrypcji zdarzeń wypychania (w trybie dostarczania). Zapewnia niezawodną logikę ponawiania prób w przypadku, gdy miejsce docelowe nie może odbierać zdarzeń.

Ważne

Dostarczanie wypychanych przestrzeni nazw usługi Event Grid obecnie obsługuje usługę Azure Event Hubs jako miejsce docelowe. W przyszłości przestrzenie nazw usługi Event Grid będą obsługiwać więcej miejsc docelowych, w tym wszystkich miejsc docelowych obsługiwanych przez usługę Event Grid Basic.

Dostarczanie zdarzeń usługi Event Hubs

Usługa Event Grid używa zestawu SDK usługi Event Hubs do wysyłania zdarzeń do usługi Event Hubs przy użyciu protokołu AMQP. Zdarzenia są wysyłane jako tablica bajtów z każdym elementem w tablicy zawierającej element CloudEvent.

Dostarczanie wypychania i ściągania

Usługa Event Grid obsługuje dostarczanie zdarzeń wypychania i ściągania przy użyciu protokołu HTTP. W przypadku dostarczania wypychanego należy zdefiniować miejsce docelowe w subskrypcji zdarzeń, element webhook lub usługę platformy Azure, do której usługa Event Grid wysyła zdarzenia. W przypadku dostarczania ściągnięcia aplikacje subskrybentów łączą się z usługą Event Grid w celu korzystania ze zdarzeń. Dostarczanie ściągania jest obsługiwane w przypadku tematów w przestrzeni nazw usługi Event Grid.

Ważne

Usługa Event Hubs jest obsługiwana jako miejsce docelowe dla subskrypcji w tematach przestrzeni nazw. W nadchodzących wersjach przestrzenie nazw usługi Event Grid będą obsługiwać wszystkie miejsca docelowe obecnie dostępne w usłudze Event Grid Basic wraz z dodatkowymi miejscami docelowymi.

Diagram wysokiego poziomu przedstawiający dostarczanie wypychane i dostarczanie ściągnięcia z rodzajem zaangażowanych zasobów.

Kiedy należy używać dostarczania wypychań a dostarczania ściągnięcia

Poniżej przedstawiono ogólne wskazówki ułatwiające podjęcie decyzji o tym, kiedy używać dostarczania ściągania lub wypychania.

Dostarczanie ściągnięcia

  • Potrzebujesz pełnej kontroli co do tego, kiedy odbierać zdarzenia. Na przykład aplikacja może nie być przez cały czas, nie wystarczająco stabilna lub przetwarzać dane w określonym czasie.
  • Potrzebna jest pełna kontrola nad zużyciem zdarzeń. Na przykład usługa podrzędna lub warstwa w aplikacji konsumenta ma problem uniemożliwiający przetwarzanie zdarzeń. W takim przypadku interfejs API dostarczania ściągnięcia umożliwia aplikacji konsumenta zwolnienie już odczytanego zdarzenia z powrotem do brokera, aby można było go dostarczyć później.
  • Chcesz użyć linków prywatnych podczas odbierania zdarzeń, co jest możliwe tylko w przypadku dostarczania ściągnięcia, a nie dostarczania wypychanych.
  • Nie masz możliwości uwidocznienia punktu końcowego i używania dostarczania wypychanego, ale możesz nawiązać połączenie z usługą Event Grid w celu korzystania ze zdarzeń.

Dostarczanie wypychane

  • Chcesz uniknąć ciągłego sondowania, aby określić, czy nastąpiła zmiana stanu systemu. Zamiast tego używasz usługi Event Grid do wysyłania zdarzeń do Ciebie w momencie wystąpienia zmian stanu.
  • Masz aplikację, która nie może wykonywać wywołań wychodzących. Na przykład Organizacja może być zaniepokojona eksfiltracją danych. Jednak aplikacja może odbierać zdarzenia za pośrednictwem publicznego punktu końcowego.

Następne kroki