Wzorzec sprawdzania oświadczeń

Przechowuj duży ładunek komunikatów w zewnętrznym magazynie danych i wysyłaj tylko odwołanie do przechowywanego ładunku za pośrednictwem systemu obsługi komunikatów. Aplikacje odbierające przedstawiają token referencyjny, nazywany kuponem odbioru, aby pobrać duży ładunek danych, gdy muszą go przetworzyć. Takie podejście umożliwia zadaniom przesyłanie dużych ładunków danych bez przechowywania ich w systemie komunikatów.

Kontekst i problem

Tradycyjne systemy obsługi komunikatów są zoptymalizowane pod kątem zarządzania dużą ilością małych komunikatów i często ograniczają rozmiar komunikatów, które mogą obsłużyć. Duże komunikaty nie tylko przekraczają limity rozmiaru, ale mogą również obniżyć wydajność systemu, gdy system obsługi komunikatów je przechowuje.

Poniższe ograniczenia sprawiają, że przesyłanie ładunku inline przez system komunikatów jest niewystarczające:

• Odrzucenie z powodu limitu rozmiaru. Systemy obsługi komunikatów odrzucają komunikaty, które przekraczają skonfigurowaną maksymalną wartość.

• Ciśnienie zasobów brokera. Przechowywanie dużych porcji danych w brokerze pochłania nieproporcjonalnie dużo pamięci i miejsca na dysku w porównaniu z ilością metadanych potrzebnych brokerowi do kierowania i dostarczania komunikatu. To zużycie konkuruje o zasoby potrzebne do obsługi innych komunikatów w systemie.

• Obniżenie przepływności. Większe komunikaty zwiększają czas serializacji, transferu i deserializacji na operację.

• Eskalacja kosztów. Niektóre systemy komunikatów pobierają opłaty w zależności od rozmiaru komunikatu, poziomu taryfy lub liczby jednostek pojemności. Przesyłanie dużych ładunków danych inline może przenosić obciążenia do droższych warstw lub przydziałów pojemności.

Rozwiązanie

Wzorzec Claim Check oddziela przechowywanie ładunku wiadomości od dostarczania wiadomości. Aplikacja wysyłająca zapisuje pełny ładunek do zewnętrznego magazynu danych i wysyła odwołanie do tego ładunku za pośrednictwem systemu obsługi komunikatów. System obsługi komunikatów nigdy nie widzi ani nie przechowuje ładunku. Aplikacje odbierające używają odwołania do bezpośredniego pobrania ładunku danych z magazynu danych. Odwołanie jest identyfikatorem, który aplikacja odbierająca musi rozpoznać.

Wzorzec jest zgodny z następującą sekwencją:

1. Aplikacja wysyłająca generuje ładunek danych.
2. Aplikacja wysyłająca zapisuje ładunek w zewnętrznym magazynie danych.
3. Po pomyślnym zapisaniu danych aplikacja wysyłająca generuje odwołanie do zapisanych danych i publikuje je w systemie komunikatów jako komunikat typu claim check.
4. Aplikacja odbierana pobiera komunikat i odczytuje token sprawdzania oświadczeń.
5. Aplikacja odbierająca używa tokenu do pobrania ładunku danych z magazynu danych.
6. Aplikacja odbierająca przetwarza ładunek danych.

System obsługi komunikatów obsługuje tylko mały komunikat sprawdzania oświadczeń, który pozwala uniknąć odrzucenia rozmiaru komunikatu i konieczności użycia zasobów do transferu i przechowywania dużych ładunków komunikatów. Zewnętrzny magazyn danych stosuje zasady kontroli dostępu i cyklu życia do ładunku niezależnie od systemu obsługi komunikatów.

Problemy i zagadnienia

Podczas podejmowania decyzji o sposobie implementacji tego wzorca należy wziąć pod uwagę następujące kwestie:

• Odpowiedzialność za cykl życia ładunku danych. Określ, który komponent odpowiada za usuwanie danych i w jaki sposób komponent ustala, że dane nie są już potrzebne. Koordynowanie wygasania komunikatów i przechowywania ładunku, aby sprawdzanie prawidłowego oświadczenia nie wskazywało usuniętych danych.

• Aplikacja warunkowa. Zdecyduj, czy zastosować wzorzec claim-check do wszystkich komunikatów, czy podejmować decyzję o zastosowaniu wzorca claim-check dla każdego komunikatu. Jeśli jest to warunkowe, upewnij się, że schemat określa, czy ładunek jest wbudowany, czy zewnętrzny.

• Bezpieczeństwo tokenów i przechowywania. Nie osadzaj tokenów zabezpieczających w ramach sprawdzania oświadczeń. Pozostaw autoryzację jako niezależną interakcję między systemami producentów lub konsumentów a magazynem danych. Jeśli rozwiązanie wymaga jawnego udzielenia dostępu tymczasowego użytkownikom, zamiast tego użyj wzorca klucza valet .

• Ładunek danych i spójność tokenów. Zapis danych i publikacja tokenu odbywają się w oddzielnych systemach i nie stanowią jednej transakcji atomowej. Awaria po zapisaniu payloadu, ale przed opublikowaniem tokenu może pozostawić payload osierocony. Opublikowanie tokenu, zanim będzie można pobrać jego dane, może oznaczać, że odbiorcy otrzymają odwołania, których nie mogą rozwiązać. Opublikuj token dopiero po pomyślnym zakończeniu zapisu ładunku. Ponieważ ponowienia mogą dostarczyć ten sam claim check więcej niż raz, użyj wzorca Idempotent Consumer, aby bezpiecznie przetwarzać duplikaty.

• Integralność ładunku. Gdy konsumenci muszą zweryfikować integralność ładunku, dołącz skrót zawartości lub podpis cyfrowy w komunikacie. Zdefiniuj protokół postępowania na wypadek rozbieżności, na przykład odrzucenie ładunku danych, ponowienie próby pobrania lub przekazanie komunikatu do zbadania.

• Dostępność i trwałość ładunku danych. Zewnętrzny magazyn danych musi pozostać dostępny i trwały przez cały okres, w ramach którego odbierane aplikacje muszą pobrać ładunek. Jeśli w magazynie danych wystąpi awaria lub dojdzie do utraty danych, odbiorcy mający prawidłowe tokeny nie będą mogli pobrać swoich ładunków danych, a przetwarzanie ich komunikatów zostanie wstrzymane.

• Opóźnienie skoku pobierania. Wzorzec dodaje dodatkowe podróże sieciowe w porównaniu z wbudowanym dostarczaniem komunikatów. Aplikacje odbierające muszą wywołać zewnętrzny magazyn danych, aby pobrać ładunek danych przed rozpoczęciem przetwarzania.

• Obsługa sprawdzania oświadczeń zapewniana przez platformę. Skorzystaj z możliwości oferowanych przez zestaw SDK magistrali komunikatów. Na przykład NServiceBus ma funkcję DataBus , która umożliwia automatyzowanie magazynowania i pobierania ładunku.

Kiedy należy używać tego wzorca

Użyj tego wzorca, gdy:

• Ładunki komunikatów regularnie przekraczają maksymalny rozmiar komunikatu obsługiwany przez system obsługi komunikatów. Przeniesienie payloadu do zewnętrznego magazynu danych i przesyłanie jedynie lekkiego tokenu claim check pozwala uniknąć odrzucenia z powodu przekroczenia limitu rozmiaru.

• Duże komunikaty zużywają nieproporcjonalne zasoby brokera. Duże komunikaty wpływają na wydajność systemu obsługi komunikatów przez zwiększenie serializacji i czasu transferu lub obniżenie przepływności dla wszystkich producentów i konsumentów, którzy współużytkują system obsługi komunikatów.

• Ładunki danych zawierają poufne informacje, które nie powinny być widoczne dla systemu przesyłania komunikatów ani dla komponentów pośredniczących, takich jak narzędzia do monitorowania kolejek. Zastosuj wzorzec do całego ładunku lub tylko do jego poufnych części. Przechowuj zawartość wrażliwą w zabezpieczonym magazynie danych z dedykowanymi mechanizmami kontroli dostępu, aby zachować ją poza ścieżką obsługi komunikatów.

• Komunikaty mają złożone trasowanie z wielokrotną serializacją. Komunikaty przechodzą przez wiele składników routingu, które wykonują serializacji, deserializacji, szyfrowania lub odszyfrowywania. Przesyłaj tylko mały token za pośrednictwem pośredników, aby wyeliminować powtarzające się przetwarzanie pełnego ładunku przy każdym przeskoku i zmniejszyć skumulowane opóźnienie.

Ten wzorzec może nie być odpowiedni w następujących przypadkach:

• Ważność opóźnienia przewyższa obawy dotyczące rozmiaru ładunku. Obciążenia wymagające jak najniższego opóźnienia na całej ścieżce między producentem a konsumentem mogą nie akceptować dodatkowych przeskoków sieciowych związanych z przechowywaniem i pobieraniem danych. Jeśli komunikaty mogą być przekazywane bezpośrednio, bez przekraczania ograniczeń rozmiaru lub wydajności, ich bezpośrednie przekazywanie jest prostsze i szybsze.

• Możesz wybrać transport lub poziom, który obsługuje taki rozmiar ładunku. Gdy ładunki danych mieszczą się w limicie obsługiwanym przez dany mechanizm transportowy i nie powodują niedopuszczalnego spadku przepustowości ani wzrostu opóźnień, wysyłaj je bezpośrednio w wiadomości, aby uniknąć zależności od zewnętrznego magazynu. Na przykład warstwa Premium usługi Azure Service Bus obsługuje komunikaty protokołu Advanced Message Queuing Protocol (AMQP) o rozmiarze do 100 MB. Zachowaj możliwie najmniejsze komunikaty, ponieważ duże komunikaty zmniejszają przepływność i zwiększają opóźnienie.

• Koordynacja między dwoma systemami nie jest możliwa. Wzorzec wymaga koordynacji między dwoma niezależnymi systemami. Wartość claim check musi być zapisywana w sposób, który system odbierający będzie w stanie zinterpretować, a jej format może wymagać dostosowywania z czasem.

Alternatives

Rozważ następujące podejścia jako alternatywy dla tego wzorca:

• Zmniejsz rozmiar ładunku wbudowanego. Kompresja może zmniejszyć powtarzające się ładunki tekstowe lub binarne, a bardziej kompaktowy serializator może zmniejszyć obciążenie komunikatów. Wybierz to podejście, gdy zmniejszony ładunek mieści się wygodnie w limicie transportu, a każdy producent i konsument może korzystać z tego samego formatu kompresji i serializacji.

• Podziel i agreguj ładunek danych w naturalny sposób. Podziel duży ładunek danych na sekwencję mniejszych komunikatów, gdy odbiorcy mogą przetwarzać fragmenty niezależnie lub złożyć je ponownie po dostarczeniu. Takie podejście pozostawia dane w systemie komunikatów, ale dodaje wymagania dotyczące sekwencjonowania, korelacji, obsługi duplikatów i ponownego składania. Aby uzyskać więcej informacji, zobacz wzorce Splitter i Aggregator opisane w Enterprise Integration Patterns.

Projektowanie obciążenia pracy

Oceń, jak użyć wzorca Claim Check w projekcie obciążenia, aby zrealizować cele i zasady opisane w filarach platformy Azure Well-Architected Framework. Poniższa tabela zawiera wskazówki dotyczące sposobu, w jaki ten wzorzec obsługuje cele filarów.

Jeśli ten wzorzec wprowadza kompromisy w ramach filaru, rozważ je przed celami innych filarów.

Examples

Ta sekcja zawiera linki do przykładów wzorców chmury GitHub Claim-check, które pokazują, jak usługi Azure implementują wzorzec sprawdzania oświadczeń. Każdy przykład używa Azure Blob Storage jako zewnętrznego magazynu danych i paruje go z innym systemem obsługi komunikatów Azure. Przykłady od 1 do 3 używają adresu URL obiektu blob w powiadomieniu usługi Azure Event Grid jako elementu wzorca claim check. Przykład 4 używa niestandardowego mechanizmu claim check publikowanego przez aplikację wysyłającą.

W przykładach od 1 do 3:

1. Aplikacja wysyłająca przekazuje duży ładunek do Blob Storage.
2. Przesłanie wyzwala zdarzenie Microsoft.Storage.BlobCreated za pośrednictwem tematu systemowego usługi Event Grid.
3. Usługa Event Grid kieruje do skonfigurowanego systemu komunikatów powiadomienie zawierające bezpośredni adres URL obiektu blob, którego przykłady używają jako identyfikatora odwołania.
4. Aplikacja odbierana, zaimplementowana jako aplikacja funkcji Azure Functions lub klient wiersza polecenia, pobiera powiadomienie, wyodrębnia adres URL obiektu blob i pobiera ładunek bezpośrednio z Blob Storage na potrzeby przetwarzania.

W implementacji produkcyjnej filtruje się subskrypcję zdarzeń pod kątem operacji wskazujących na w pełni zatwierdzony blokowy blob oraz projektuje odbiornik tak, aby obsługiwał zdarzenia opóźnione, zduplikowane i dostarczane w niewłaściwej kolejności.

Przykład 4 używa innego podejścia. Zamiast kierowania powiadomienia Blob Storage za pośrednictwem usługi Event Grid, aplikacja wysyłająca tworzy sprawdzanie oświadczeń po przekazaniu ładunku do Blob Storage. Następnie aplikacja wysyłająca publikuje sprawdzanie oświadczenia w punkcie końcowym platformy Kafka Azure Event Hubs przy użyciu protokołu Apache Kafka. Takie podejście jest odpowiednie dla środowisk, które już korzystają z producentów zgodnych z platformą Kafka lub wymagają niestandardowych formatów tokenów.

Poniższa tabela zawiera każdy przykład wraz z jego systemem komunikatów, publikatorem claim check, aplikacją odbierającą i zależnościami magazynu. Wybierz każdy link, aby wyświetlić przykładowy kod w GitHub.

Następne kroki

• Przeczytaj kanoniczny opis wzorców integracji przedsiębiorstwa z sprawdzaniem oświadczeń.
• Zapoznaj się z inną implementacją w artykule Obsługa dużych komunikatów Service Bus przy użyciu wzorca claim check.
• Wybierz między Azure Event Grid, usługą Event Hubs i Service Bus.

Powiązane zasoby

• wzorzec asynchroniczny "Request-Reply"
• Wzorzec konkurujących odbiorców
• Sekwencyjny wzorzec konwoju
• Wzorzec Valet Key