Wzorzec sprawdzania oświadczeń

Podziel duży komunikat na sprawdzanie oświadczenia i ładunek. Wyślij kontrolę oświadczenia do platformy obsługi komunikatów i zapisz ładunek w usłudze zewnętrznej. Ten wzorzec umożliwia przetwarzanie dużych komunikatów, jednocześnie chroniąc magistralę komunikatów i klienta przed przeciążeniem lub spowolnieniem. Ten wzorzec pomaga również zmniejszyć koszty, ponieważ magazyn jest zwykle tańszy niż jednostki zasobów używane przez platformę obsługi komunikatów.

Ten wzorzec jest również znany jako Reference-Based Messaging i został pierwotnie opisany w książce Enterprise Integration Patterns, autorstwa Gregora Hohpe'a i Bobby'ego Woolfa.

Kontekst i problem

Architektura oparta na komunikatach musi być w pewnym momencie w stanie wysyłać, odbierać i manipulować dużymi komunikatami. Takie komunikaty mogą zawierać dowolne elementy, w tym obrazy (na przykład skany MRI), pliki dźwiękowe (na przykład wywołania call-center), dokumenty tekstowe lub dowolne dane binarne o dowolnym rozmiarze.

Bezpośrednie wysyłanie takich dużych komunikatów do magistrali komunikatów nie jest zalecane, ponieważ wymagają one większej ilości zasobów i przepustowości do użycia. Duże komunikaty mogą również spowalniać całe rozwiązanie, ponieważ platformy obsługi komunikatów są zwykle dostosowane do obsługi ogromnych ilości małych komunikatów. Ponadto większość platform obsługi komunikatów ma limity rozmiaru komunikatów, więc może być konieczne obejście tych limitów dla dużych komunikatów.

Rozwiązanie

Zapisz cały ładunek komunikatu w usłudze zewnętrznej, takiej jak baza danych. Pobierz odwołanie do przechowywanego ładunku i wyślij tylko to odwołanie do magistrali komunikatów. Odwołanie działa jak kontrola roszczeń używana do pobierania bagażu, stąd nazwa wzorca. Klienci zainteresowani przetwarzaniem tego konkretnego komunikatu mogą w razie potrzeby użyć uzyskanego odwołania do pobrania ładunku.

1. Wyślij wiadomość
2. Przechowywanie komunikatu w magazynie danych
3. Kolejkuj odwołanie do wiadomości
4. Przeczytaj odwołanie do wiadomości
5. Pobieranie komunikatu
6. Przetwarzanie komunikatu

Problemy i kwestie do rozważenia

Podczas podejmowania decyzji o sposobie wdrożenia tego wzorca należy rozważyć następujące punkty:

• Rozważ usunięcie danych wiadomości po ich użyciu, jeśli nie musisz archiwizować komunikatów. Chociaż magazyn obiektów blob jest stosunkowo tani, kosztuje trochę pieniędzy w dłuższej perspektywie, zwłaszcza jeśli istnieje wiele danych. Usunięcie komunikatu można wykonać synchronicznie przez aplikację, która odbiera i przetwarza komunikat, lub asynchronicznie przez oddzielny dedykowany proces. Podejście asynchroniczne usuwa stare dane bez wpływu na przepływność i wydajność przetwarzania komunikatów odbieranej aplikacji.

• Przechowywanie i pobieranie komunikatu powoduje pewne dodatkowe obciążenie i opóźnienie. Możesz zaimplementować logikę w aplikacji wysyłającej, aby używać tego wzorca tylko wtedy, gdy rozmiar komunikatu przekracza limit danych magistrali komunikatów. Wzorzec zostanie pominięty dla mniejszych komunikatów. Takie podejście spowodowałoby warunkowy wzorzec sprawdzania oświadczeń.

Kiedy używać tego wzorca

Ten wzorzec może być używany, gdy komunikat nie może pasować do obsługiwanego limitu komunikatów wybranej technologii magistrali komunikatów. Na przykład usługa Service Bus ma obecnie limit 100 MB (warstwa Premium), a usługa Event Grid obsługuje maksymalnie 1 MB komunikatów.

Wzorzec może być również używany, jeśli ładunek powinien być dostępny tylko przez usługi, które są autoryzowane do jego wyświetlenia. Odciążając ładunek do zasobu zewnętrznego, można wprowadzić bardziej rygorystyczne reguły uwierzytelniania i autoryzacji, aby zapewnić wymuszanie zabezpieczeń podczas przechowywania poufnych danych w ładunku.

Projekt obciążenia

Architekt powinien ocenić, w jaki sposób wzorzec sprawdzania oświadczeń może być używany w projekcie obciążenia, aby sprostać celom i zasadom opisanym w filarach platformy Azure Well-Architected Framework. Na przykład:

Podobnie jak w przypadku każdej decyzji projektowej, należy rozważyć wszelkie kompromisy w stosunku do celów innych filarów, które mogą zostać wprowadzone przy użyciu tego wzorca.

Przykłady

Na platformie Azure ten wzorzec można zaimplementować na kilka sposobów i z różnymi technologiami, ale istnieją dwie główne kategorie. W obu przypadkach odbiorca ponosi odpowiedzialność za odczytanie sprawdzania oświadczenia i użycie go do pobrania ładunku.

• Automatyczne generowanie sprawdzania oświadczeń. To podejście używa usługi Azure Event Grid do automatycznego generowania sprawdzania oświadczenia i wypychania go do magistrali komunikatów.

• Ręczne generowanie sprawdzania oświadczeń. W tym podejściu nadawca jest odpowiedzialny za zarządzanie ładunkiem. Nadawca przechowuje ładunek przy użyciu odpowiedniej usługi, pobiera lub generuje sprawdzanie oświadczeń i wysyła sprawdzanie oświadczenia do magistrali komunikatów.

Event Grid to usługa routingu zdarzeń i próbuje dostarczać zdarzenia w konfigurowalnym czasie do 24 godzin. Następnie zdarzenia są odrzucane lub nieaktywne. Jeśli musisz zarchiwizować ładunki zdarzeń lub odtworzyć strumień zdarzeń, możesz dodać subskrypcję usługi Event Grid do usługi Event Hubs lub Queue Storage, gdzie komunikaty mogą być przechowywane przez dłuższy czas i obsługiwane są archiwizowanie komunikatów. Aby uzyskać informacje na temat dostrajania dostarczania komunikatów usługi Event Grid i ponawiania prób oraz konfiguracji utraconych wiadomości, zobacz Dead letter and retry policies (Zasady martwych listów i ponawiania prób).

Automatyczne generowanie sprawdzania oświadczeń za pomocą usługi Blob Storage i Event Grid

W tym podejściu nadawca pominie ładunek komunikatu do wyznaczonego kontenera usługi Azure Blob Storage. Usługa Event Grid automatycznie generuje tag/odwołanie i wysyła go do obsługiwanej magistrali komunikatów, takiej jak kolejki usługi Azure Storage. Odbiorca może sondować kolejkę, pobrać komunikat, a następnie użyć przechowywanych danych referencyjnych, aby pobrać ładunek bezpośrednio z usługi Blob Storage.

Ten sam komunikat usługi Event Grid może być używany bezpośrednio przez usługę Azure Functions bez konieczności przechodzenia przez magistralę komunikatów. Takie podejście w pełni wykorzystuje bezserwerowy charakter zarówno usługi Event Grid, jak i usługi Functions.

Przykładowy kod dla tego podejścia można znaleźć tutaj.

Usługa Event Grid z usługą Event Hubs

Podobnie jak w poprzednim przykładzie usługa Event Grid automatycznie generuje komunikat, gdy ładunek jest zapisywany w kontenerze obiektów blob platformy Azure. Jednak w tym przykładzie magistrala komunikatów jest implementowana przy użyciu usługi Event Hubs. Klient może zarejestrować się w celu odbierania strumienia komunikatów podczas zapisywania ich w centrum zdarzeń. Centrum zdarzeń można również skonfigurować do archiwizowania komunikatów, udostępniając je jako plik Avro, który można wykonywać zapytania za pomocą narzędzi, takich jak Apache Spark, Apache Drill lub dowolna z dostępnych bibliotek Avro.

Przykładowy kod dla tego podejścia można znaleźć tutaj.

Generowanie sprawdzania oświadczeń za pomocą usługi Service Bus

To rozwiązanie korzysta z konkretnej wtyczki usługi Service Bus ServiceBus.AttachmentPlugin, która ułatwia implementowanie przepływu pracy sprawdzania oświadczeń. Wtyczka konwertuje treść komunikatu na załącznik, który jest przechowywany w usłudze Azure Blob Storage po wysłaniu komunikatu.

using ServiceBus.AttachmentPlugin;
...

// Getting connection information
var serviceBusConnectionString = Environment.GetEnvironmentVariable("SERVICE_BUS_CONNECTION_STRING");
var queueName = Environment.GetEnvironmentVariable("QUEUE_NAME");
var storageConnectionString = Environment.GetEnvironmentVariable("STORAGE_CONNECTION_STRING");

// Creating config for sending message
var config = new AzureStorageAttachmentConfiguration(storageConnectionString);

// Creating and registering the sender using Service Bus Connection String and Queue Name
var sender = new MessageSender(serviceBusConnectionString, queueName);
sender.RegisterAzureStorageAttachmentPlugin(config);

// Create payload
var payload = new { data = "random data string for testing" };
var serialized = JsonConvert.SerializeObject(payload);
var payloadAsBytes = Encoding.UTF8.GetBytes(serialized);
var message = new Message(payloadAsBytes);

// Send the message
await sender.SendAsync(message);

Komunikat usługi Service Bus działa jako kolejka powiadomień, którą klient może subskrybować. Gdy użytkownik otrzyma komunikat, wtyczka umożliwia bezpośrednie odczytywanie danych komunikatu z usługi Blob Storage. Następnie możesz wybrać sposób dalszego przetwarzania komunikatu. Zaletą tego podejścia jest abstrakcja przepływu pracy sprawdzania oświadczeń od nadawcy i odbiorcy.

Przykładowy kod dla tego podejścia można znaleźć tutaj.

Ręczne generowanie sprawdzania oświadczeń przy użyciu platformy Kafka

W tym przykładzie klient platformy Kafka zapisuje ładunek w usłudze Azure Blob Storage. Następnie wysyła komunikat powiadomienia przy użyciu usługi Event Hubs z obsługą platformy Kafka. Odbiorca odbiera komunikat i może uzyskać dostęp do ładunku z usługi Blob Storage. W tym przykładzie pokazano, jak można użyć innego protokołu obsługi komunikatów do zaimplementowania wzorca sprawdzania oświadczeń na platformie Azure. Na przykład może być konieczne obsługa istniejących klientów platformy Kafka.

Przykładowy kod dla tego podejścia można znaleźć tutaj.

Następne kroki

• Przykłady opisane powyżej są dostępne w witrynie GitHub.
• Witryna Wzorce integracji dla przedsiębiorstw zawiera opis tego wzorca.
• Aby zapoznać się z innym przykładem, zobacz Obsługa dużych komunikatów usługi Service Bus przy użyciu wzorca sprawdzania oświadczeń (wpis w blogu).
• Alternatywnym wzorcem obsługi dużych komunikatów jest podział i agregacja.
• Biblioteki, takie jak NServiceBus, zapewniają obsługę tego wzorca gotowego do użycia z funkcją "magistrali danych".

Powiązane zasoby

• Asynchroniczny wzorzec żądania-odpowiedzi
• Wzorzec konkurujących odbiorców
• Sekwencyjny wzorzec konwoju