Podejścia architektury do obsługi komunikatów w rozwiązaniach wielodostępnych

Aplikacje rozproszone, które obejmują wiele usług wewnętrznych i zewnętrznych, wymagają asynchronicznej komunikacji komunikatów i komunikacji sterowanej zdarzeniami. Podczas opracowywania rozwiązania o architekturze wielodostępnej, musisz zdecydować, jak udostępniać lub dzielić komunikaty pomiędzy różnych najemców.

Możesz udostępnić system obsługi komunikatów lub usługę przesyłania strumieniowego zdarzeń we wszystkich dzierżawach, aby zmniejszyć koszty operacyjne i złożoność zarządzania. Alternatywnie, możesz użyć dedykowanego systemu komunikacji dla każdej dzierżawy, aby uzyskać lepszą izolację danych, zmniejszyć ryzyko wycieku danych, wyeliminować problem głośnego sąsiada i łatwiej rozliczać koszty platformy Azure pomiędzy dzierżawców.

Ten artykuł pomaga architektom rozwiązań zdecydować, jak używać infrastruktury obsługi komunikatów lub zdarzeń w rozwiązaniu wielodostępnym.

Komunikaty, punkty danych i zdarzenia dyskretne

Należy zrozumieć różnicę między usługami, które dostarczają zdarzenia i systemy wysyłające komunikat. Zdarzenie jest lekkim powiadomieniem o zmianie warunku lub stanu. Zdarzenie zwykle opisuje coś, co już się stało. Komunikat zawiera nieprzetworzone dane generowane przez usługę do korzystania lub przechowywania w innym miejscu. Komunikaty są instrukcjami niejawnymi lub żądaniami.

W poniższej tabeli opisano kluczowe typy komunikatów i przykładowe rozwiązania multitenant, które mogą używać tego typu elementu.

Aby uzyskać więcej informacji, zobacz Wybieranie odpowiedniej usługi komunikacyjnej platformy Azure dla danych.

Platforma Azure udostępnia kilka usług obsługi komunikatów, które mogą obsługiwać wymagania dotyczące obsługi komunikatów. Te usługi obejmują usługi Azure Event Hubs, Azure Event Grid i Azure Service Bus. Aby uzyskać więcej informacji, zobacz Wybieranie między usługami obsługi komunikatów platformy Azure.

Możesz również wdrażać własną usługę obsługi komunikatów i zarządzać nią na maszynach wirtualnych, w kontenerach lub w usługach takich jak Azure Kubernetes Service (AKS). Takie podejście wymaga wdrożenia, zarządzania i utrzymania infrastruktury wiadomości.

Kluczowe zagadnienia i wymagania

Wybrany model wdrażania i dzierżawy wpływa na bezpieczeństwo, wydajność, izolację danych, zarządzanie i możliwość krzyżowego naliczania kosztów zasobów dzierżawcom. Podczas tej analizy należy również wziąć pod uwagę model wybrany dla infrastruktury obsługi komunikatów i zdarzeń. W poniższych sekcjach opisano kluczowe decyzje, które należy podjąć podczas planowania systemu obsługi komunikatów w rozwiązaniu wielodostępnym.

Skala

Podczas planowania infrastruktury obsługi komunikatów lub zdarzeń należy wziąć pod uwagę liczbę dzierżaw, złożoność przepływów komunikatów i strumieni zdarzeń, ilość komunikatów, oczekiwany profil ruchu i poziom izolacji.

Najpierw zaplanuj pojemność i ustal maksymalną pojemność przepływności dla systemu obsługi komunikatów. To planowanie pomaga prawidłowo obsługiwać oczekiwaną ilość komunikatów podczas regularnego i szczytowego ruchu.

Gdy rozwiązanie obsługuje wiele dzierżaw i ma oddzielny system obsługi komunikatów dla każdej dzierżawy, zastosuj spójną strategię automatyzacji. Ta strategia powinna zautomatyzować wdrażanie, monitorowanie, alerty i skalowanie każdej infrastruktury.

Na przykład można wdrożyć system komunikacji dla dzierżawcy podczas procesu aprowizacji, korzystając z narzędzia infrastruktury jako kodu (IaC), takiego jak Terraform, Bicep lub Szablony Azure Resource Manager (szablony ARM), oraz z systemu DevOps, takiego jak Azure DevOps lub GitHub Actions. Aby uzyskać więcej informacji, zobacz Architektoniczne podejścia do wdrażania i konfiguracji rozwiązań wielodostępnych.

Można określić wielkość systemu wiadomości z maksymalną przepustowością wiadomości na jednostkę czasu. Jeśli system obsługuje dynamiczne skalowanie automatyczne, może on automatycznie zwiększyć lub zmniejszyć pojemność na podstawie warunków ruchu i metryk, aby spełnić oczekiwaną umowę dotyczącą poziomu usług (SLA).

Przewidywalność wydajności i niezawodność

W przypadku tylko kilku dzierżawców pojedynczy system obsługi komunikatów może spełniać wymagania dotyczące przepływności funkcjonalnej i zmniejszyć całkowity koszt posiadania (TCO). Aplikacja wielodostępna może współdzielić te same obiekty komunikacyjne, takie jak kolejki i tematy, dla wielu klientów. Alternatywnie możesz użyć dedykowanego zestawu komponentów dla każdego najemcy, aby zwiększyć izolację najemców. Jednak udostępniona infrastruktura obsługi komunikatów w wielu dzierżawach może uwidocznić całe rozwiązanie problemu hałaśliwego sąsiada. Aktywność jednego lokatora może zakłócić wydajność i funkcjonalność innych lokatorów.

W takim przypadku należy prawidłowo określić rozmiar systemu obsługi komunikatów w celu utrzymania oczekiwanego obciążenia ruchu w czasie szczytu. W idealnym przypadku system powinien obsługiwać autoskalowanie, które dynamicznie zwiększa swoją skalę, gdy ruch rośnie, i zmniejsza ją, gdy ruch maleje. Dedykowany system komunikacji dla każdego najemcy może również ograniczyć ryzyko hałaśliwego sąsiada, ale zarządzanie wieloma systemami komunikacyjnymi zwiększa złożoność rozwiązania.

Aplikacja wielodostępna może używać podejścia hybrydowego. W tym podejściu podstawowe usługi używają tego samego zestawu kolejek i tematów w jednym, udostępnionym systemie obsługi komunikatów w celu zaimplementowania wewnętrznej, asynchronicznej komunikacji. Z kolei inne usługi mogą przyjąć dedykowaną grupę jednostek obsługi komunikatów, a nawet dedykowany system obsługi komunikatów dla każdej dzierżawy, aby rozwiązać problem z hałaśliwym sąsiadem i zagwarantować izolację danych.

Złożoność zarządzania i działania

Od początku zaplanuj sposób działania, monitorowania i obsługi infrastruktury obsługi komunikatów i zdarzeń oraz sposobu, w jaki podejście wielodostępności wpływa na operacje i procesy. Rozważmy na przykład następujące czynniki:

• Gdy udostępniasz system obsługi komunikatów w wielu dzierżawach, zdefiniuj sposób zbierania i raportowania metryk użycia dla każdej dzierżawy lub ograniczania liczby komunikatów, które każda dzierżawa może wysyłać lub odbierać.

• Gdy najemcy muszą przechodzić na inny typ usługi komunikacyjnej, inne wdrożenie lub inny region, określ, jak przeprowadzić migrację.

• Jeśli system obsługi komunikatów korzysta z oferty platformy jako usługi (PaaS), należy uwzględnić następujące kwestie:

  • Dostosuj poziom cenowy dla każdego lokatora na podstawie cech oraz poziomu izolacji - współdzielonego lub dedykowanego - który wybiera lokator.

  • Utwórz tożsamości zarządzane specyficzne dla dzierżawy i przypisania ról platformy Azure, aby przypisać odpowiednie uprawnienia tylko do jednostek obsługi komunikatów, do których dzierżawa powinna uzyskiwać dostęp. Aby uzyskać dostęp do zasobów usługi Service Bus, zobacz Uwierzytelnianie tożsamości zarządzanej za pomocą identyfikatora Entra firmy Microsoft.

• Jeśli zdecydujesz się hostować system obsługi komunikatów używany przez aplikację w dedykowanym zestawie maszyn wirtualnych lub kontenerów (jeden dla każdej dzierżawy), zdefiniuj sposób wdrażania, aktualizacji, monitorowania i skalowania tych systemów.

Koszt

Ogólnie rzecz biorąc, im większa gęstość najemców w infrastrukturze wdrożeniowej, tym niższy koszt aprowizacji tej infrastruktury. Jednak współdzielona infrastruktura zwiększa prawdopodobieństwo problemów, takich jak głośny problem sąsiada. Uważnie zastanów się nad kompromisami.

Podejścia i wzorce do rozważenia

Podczas planowania wielodzierżawowego rozwiązania obejmującego system obsługi komunikatów należy wziąć pod uwagę poziom izolacji między dzierżawcami. Zapoznaj się z następującymi zagadnieniami i obserwacjami:

• Klucze szyfrowania: Jeśli dzierżawcy potrzebują własnego klucza do szyfrowania i odszyfrowywania komunikatów, potwierdź, jak usługa obsługi komunikatów obsługuje izolację kluczy. Jeśli na przykład używasz usługi Service Bus, może być konieczne utworzenie oddzielnej przestrzeni nazw usługi Service Bus Premium dla każdego najemcy, który wymaga własnych kluczy. Ta separacja umożliwia korzystanie z kluczy zarządzanych przez klienta (CMKs).

• Ciągłość działania: Zidentyfikuj najemców, którzy wymagają wysokiego poziomu zdolności do odzyskiwania i ciągłości działania. Rozważ nadmiarowość strefy, nadmiarowość geograficzną i możliwości odzyskiwania po awarii geograficznej dla tych dzierżaw tam, gdzie są dostępne.

• Przetwarzanie procesów roboczych: W przypadku korzystania z oddzielnych zasobów kolejki lub dedykowanego systemu obsługi komunikatów dla każdej dzierżawy można wdrożyć oddzielną pulę procesów roboczych dla każdej dzierżawy. Takie podejście zwiększa poziom izolacji danych i zmniejsza złożoność zarządzania wieloma jednostkami obsługi komunikatów.

  Każde wystąpienie systemu przetwarzania może przyjąć różne poświadczenia, takie jak parametry połączenia, jednostka usługi lub tożsamość zarządzana, aby uzyskać dostęp do dedykowanego systemu obsługi komunikatów. Takie podejście poprawia bezpieczeństwo i izolację między dzierżawami, ale zwiększa złożoność zarządzania tożsamościami.

Wspólny system komunikacyjny

Możesz wdrożyć udostępniony system obsługi komunikatów, taki jak pojedyncza przestrzeń nazw usługi Service Bus, i udostępnić go we wszystkich dzierżawach.

Takie podejście zapewnia najwyższą gęstość najemców w infrastrukturze i zmniejsza ogólny całkowity koszt posiadania (TCO). Często zmniejsza obciążenie związane z zarządzaniem, ponieważ wystarczy zarządzać i zabezpieczać pojedynczy system obsługi komunikatów lub zasób.

Jednak w przypadku udostępniania zasobu lub całej infrastruktury w wielu dzierżawach należy wziąć pod uwagę następujące ograniczenia:

• Rozważ ograniczenia, możliwości skalowania, limity przydziału i limity zasobu. Na przykład maksymalna liczba Event Hubs w pojedynczej przestrzeni nazw lub maksymalnych limitów przepustowości może ostatecznie stać się przeszkodą, kiedy architektura rośnie, aby obsługiwać więcej dzierżawców.

• Problem z hałaśliwym sąsiadem może stanowić problem, gdy dzielisz zasób wśród wielu najemców, zwłaszcza jeśli masz aktywnych najemców lub najemców, którzy generują większy ruch niż pozostałe. Aby ograniczyć te efekty, rozważ wzorzec ograniczania przepustowości lub wzorzec ograniczania szybkości. Można na przykład ograniczyć maksymalną liczbę wiadomości, które może wysyłać lub odbierać pojedynczy użytkownik w danym okresie.

• Możesz mieć trudności z monitorowaniem aktywności i mierzeniem zużycia zasobów dla pojedynczej dzierżawy. Niektóre usługi, takie jak określone poziomy usługi Service Bus, pobierają opłaty za operacje związane z wiadomościami. Gdy przestrzeń nazw jest współdzielona między wieloma dzierżawami, aplikacja powinna śledzić liczbę operacji obsługi komunikatów generowanych przez każdą dzierżawę oraz związane z tym koszty obciążenia zwrotnego. Inne usługi nie zapewniają tego samego poziomu szczegółowości.

Dzierżawcy mogą mieć różne wymagania dotyczące zabezpieczeń, odporności wewnątrz regionu, odzyskiwania po awarii lub lokalizacji. Jeśli te wymagania nie są zgodne z konfiguracją systemu obsługi komunikatów, możesz nie uwzględnić ich tylko w jednym zasobie.

Użyj wzorca fragmentowania

Wzorzec fragmentowania obejmuje wdrażanie wielu systemów obsługi komunikatów, nazywanych również fragmentami. Każdy fragment zawiera co najmniej jedną jednostkę obsługi komunikatów dzierżawy, taką jak kolejki i tematy. W przeciwieństwie do sygnatur wdrażania fragmenty nie oznaczają duplikowania całej infrastruktury. Możesz podzielić na fragmenty systemy obsługi komunikacji, nie duplikując ani nie dzieląc na fragmenty innej części infrastruktury w twoim rozwiązaniu.

Każdy system komunikacyjny lub shard mogą mieć różne cechy pod względem niezawodności, jednostki SKU i lokalizacji. Można na przykład fragmentować swoich najemców w wielu systemach wiadomości na podstawie ich lokalizacji lub wymagań dotyczących wydajności, niezawodności, bezpieczeństwa danych lub ciągłości działania.

W przypadku korzystania z wzorca fragmentowania, należy zastosować strategię sharding, aby przypisać danego dzierżawcę do systemu wiadomości zawierającego jego kolejki. Strategia wyszukiwania używa mapy do identyfikowania docelowego systemu wiadomości na podstawie nazwy najemcy lub identyfikatora. Wielu najemców może współdzielić ten sam shard, ale jednostki wiadomości używane przez pojedynczego najemcę pozostają w obrębie jednego shardu.

Możesz zaimplementować mapę jako słownik, który łączy każdą nazwę najemcy z nazwą lub odniesieniem do docelowego systemu wiadomości. Mapę można przechowywać w rozproszonej pamięci podręcznej, do której mogą uzyskiwać dostęp wszystkie wystąpienia aplikacji wielodostępnej lub przechowywać ją w magazynie trwałym, takim jak tabela w relacyjnej bazie danych lub koncie magazynu.

Wzorzec shardingu może być skalowany w celu obsługi kilku najemców. W zależności od obciążenia można osiągnąć wysoką gęstość dzierżaw do fragmentów, co może obniżyć koszty. Możesz również użyć wzorca fragmentowania, aby rozwiązać problem z limitami przydziału, limitami i ograniczeniami subskrypcji i usług platformy Azure.

Używaj aplikacji wielodostępnej z dedykowanym systemem komunikacyjnym dla każdego najemcy

Można również wdrożyć jedną wielodostępną aplikację, która używa dedykowanych systemów komunikacyjnych dla każdego najmcy. Ten model dzierżawy obejmuje niektóre składniki udostępnione, takie jak zasoby obliczeniowe. Aprowizujesz inne usługi i zarządzasz nimi przy użyciu podejścia do wdrażania z jedną dzierżawą. Można na przykład utworzyć pojedynczą warstwę aplikacji, a następnie wdrożyć systemy komunikacyjne dla każdego najemcy, jak pokazano na poniższej ilustracji.

Jeśli określone składniki generują większość obciążenia systemu i można wdrożyć te składniki oddzielnie dla każdej dzierżawy, użyj wdrożenia partycjonowanego w poziomie, aby zmniejszyć problemy z hałaśliwymi sąsiadami. Na przykład należy użyć oddzielnego systemu komunikacyjnego lub systemu strumienia zdarzeń dla każdego najemcy, jeśli pojedyncze wystąpienie nie może nadążyć za ruchem generowanym przez wielu najemców. W przypadku korzystania z dedykowanego systemu obsługi komunikatów dla każdej dzierżawy duża liczba komunikatów lub zdarzeń z jednej dzierżawy może mieć wpływ na składniki udostępnione, ale nie na systemy obsługi komunikatów innych dzierżaw.

Ponieważ przydzielasz dedykowane zasoby dla każdego klienta, takie podejście często kosztuje więcej niż współdzielony model hostingu. Jednak zapewnia również prosty sposób naliczania opłat za zasoby, z których korzysta każdy najemca. Takie podejście umożliwia osiągnięcie wysokiej gęstości dla innych usług, takich jak zasoby obliczeniowe, i zmniejszenie kosztów tych składników.

W przypadku wdrożenia partycjonowanego w poziomie potrzebny jest zautomatyzowany proces wdrażania i zarządzania usługami aplikacji wielodzierżawczej, zwłaszcza usługami używanymi przez jednego dzierżawcę.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główny autor:

• Paolo Salvatori | Główny inżynier klienta, fasttrack dla platformy Azure

Inni współautorzy:

• Daphne Choong | Starszy architekt rozwiązań partnerskich
• John Downs | Główny inżynier oprogramowania, wzorce i praktyki platformy Azure
• Clemens Vasters | Główny architekt, usługi i standardy obsługi komunikatów
• Arsen Vladimirskiy | Główny inżynier klienta, fasttrack dla platformy Azure

Powiązane zasoby

Aby uzyskać więcej informacji na temat wzorców projektowych obsługi komunikatów, zobacz następujące zasoby:

• Wzorzec sprawdzania oświadczeń
• Wzorzec konkurujących odbiorców
• Wzorzec określania źródła zdarzeń
• Wzorzec potoków i filtrów
• Wzorzec wydawcy-subskrybenta
• Sekwencyjny wzorzec konwoju