Udostępnij za pośrednictwem

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

  • Artykuł

Asynchroniczne komunikaty i komunikacja sterowana zdarzeniami są kluczowymi elementami zawartości podczas tworzenia aplikacji rozproszonej składającej się z kilku usług wewnętrznych i zewnętrznych. Podczas projektowania rozwiązania wielodostępnego kluczowe jest przeprowadzenie wstępnej analizy w celu zdefiniowania sposobu udostępniania lub partycjonowania komunikatów odnoszących się do różnych dzierżaw.

Udostępnianie tego samego systemu obsługi komunikatów lub usługi przesyłania strumieniowego zdarzeń może znacznie zmniejszyć koszt operacyjny i złożoność zarządzania. Jednak użycie dedykowanego systemu obsługi komunikatów dla każdej dzierżawy zapewnia lepszą izolację danych, zmniejsza ryzyko wycieku danych, eliminuje problem z hałaśliwym sąsiadem i umożliwia łatwe naliczanie kosztów platformy Azure z powrotem do dzierżaw.

W tym artykule można znaleźć rozróżnienie między komunikatami i zdarzeniami. Podczas podejmowania decyzji o podejściu do infrastruktury obsługi komunikatów lub zdarzeń w rozwiązaniu wielodostępnym znajdują się wskazówki, które mogą stosować architekci rozwiązań.

Komunikaty, punkty danych i zdarzenia dyskretne

Wszystkie systemy obsługi komunikatów mają podobne funkcje, protokoły transportu i scenariusze użycia. Na przykład większość nowoczesnych systemów obsługi komunikatów obsługuje asynchroniczną komunikację, która korzysta z nietrwałych lub trwałych kolejek, protokołów transportu AMQP i HTTPS, co najmniej raz dostarczania itd. Jednak przyglądając się bliżej typowi opublikowanych informacji i sposobom korzystania z danych i przetwarzania ich przez aplikacje klienckie, możemy odróżnić różne rodzaje komunikatów i zdarzeń. Istnieje istotne rozróżnienie między usługami, które dostarczają zdarzenia i systemy wysyłające komunikat. Aby uzyskać więcej informacji, zobacz następujące zasoby:

Zdarzenia

Zdarzenie to lekkie powiadomienie z informacją o zmianie stanu lub warunku. Zdarzenia mogą być odrębnymi jednostkami lub częścią serii. Zdarzenia to komunikaty, które zazwyczaj nie przekazują intencji wydawcy innej niż informowanie. Zdarzenie przechwytuje fakt i komunikuje go innym usługom lub składnikom. Odbiorca wydarzenia może przetworzyć wydarzenie, ponieważ jest ono spełnione i nie spełnia żadnych konkretnych oczekiwań, które posiada wydawca. Zdarzenia można sklasyfikować w dwóch głównych kategoriach:

  • Zdarzenia dyskretne przechowują informacje o określonych akcjach, które przeprowadziła aplikacja publikując. W przypadku korzystania z asynchronicznej komunikacji sterowanej zdarzeniami aplikacja publikuje zdarzenie powiadomienia, gdy coś się stanie w swojej domenie. Co najmniej jedna aplikacja zużywana musi być świadoma tej zmiany stanu, takiej jak zmiana ceny w aplikacji katalogu produktów. Konsumenci subskrybują zdarzenia, aby otrzymywać je asynchronicznie. W przypadku wystąpienia danego zdarzenia zużywające aplikacje mogą aktualizować jednostki domeny, co może spowodować opublikowanie większej liczby zdarzeń integracji.
  • Zdarzenia serii przenoszą informacyjne punkty danych, takie jak odczyty temperatury z urządzeń do analizy lub akcji użytkownika w rozwiązaniu analizy kliknięć, jako elementy w ciągłym strumieniu. Strumień zdarzeń jest powiązany z określonym kontekstem, na przykład temperaturą lub wilgotnością zgłoszoną przez urządzenie pola. Wszystkie zdarzenia związane z tym samym kontekstem mają ścisłą kolejność czasową, która ma znaczenie podczas przetwarzania tych zdarzeń za pomocą aparatu przetwarzania strumienia zdarzeń. Analizowanie strumieni zdarzeń, które przenoszą punkty danych, wymaga zebrania tych zdarzeń w buforze obejmującym żądane przedziały czasu. Może też znajdować się w wybranej liczbie elementów, a następnie przetwarzać te zdarzenia przy użyciu rozwiązania niemal w czasie rzeczywistym lub algorytmu wytrenowanego maszynowo. Analiza serii zdarzeń może przynieść sygnały, takie jak średnia wartości mierzona w przedziale czasu, który przekracza próg. Te sygnały można następnie podnieść jako dyskretne, możliwe do działania zdarzenia.

Zdarzenia dyskretne zgłaszają zmiany stanu i są możliwe do działania. Ładunek zdarzenia zawiera informacje o tym, co się stało, ale ogólnie rzecz biorąc, nie ma pełnych danych, które wyzwoliły zdarzenie. Na przykład zdarzenie powiadamia użytkowników, że aplikacja raportowania utworzyła nowy plik na koncie magazynu. Ładunek zdarzenia może zawierać ogólne informacje o pliku, ale nie ma samego pliku. Zdarzenia odrębne doskonale sprawdzają się w rozwiązaniach bez serwera wymagających skalowania.

Zdarzenia w serii zgłaszają warunek i nadają się do analizy. Zdarzenia dyskretne są uporządkowane i powiązane w czasie. W niektórych kontekstach konsument musi otrzymać pełną sekwencję zdarzeń, aby przeanalizować, co się stało i podjąć niezbędne działania.

Wiadomości

Komunikaty zawierają nieprzetworzone dane utworzone przez usługę, które mają być używane lub przechowywane w innym miejscu. Komunikaty często zawierają informacje niezbędne do wykonania kroków w przepływie pracy lub łańcuchu przetwarzania. Przykładem takiej komunikacji jest wzorzec polecenia. Wydawca może również oczekiwać, że odbiorcy komunikatu będą wykonywać serię akcji i zgłaszać wynik ich przetwarzania za pomocą komunikatu asynchronicznego. Istnieje kontrakt między wydawcą komunikatów a odbiornikami komunikatów. Na przykład wydawca wysyła komunikat z niektórymi nieprzetworzonymi danymi i oczekuje, że użytkownik utworzy plik z tych danych i wyśle z powrotem komunikat odpowiedzi po zakończeniu. W innych sytuacjach proces nadawcy może wysłać asynchroniczny, jednokierunkowy komunikat, aby poprosić inną usługę o wykonanie danej operacji, ale bez oczekiwania na powrót potwierdzenia lub komunikatu odpowiedzi z niego.

Tego rodzaju obsługa komunikatów umownych różni się zupełnie od wydawcy, który publikuje odrębne zdarzenia dla odbiorców agentów konsumenckich, bez żadnego konkretnego oczekiwania na sposób obsługi tych powiadomień.

Przykładowe scenariusze

Oto lista przykładowych scenariuszy wielodostępnych dla komunikatów, punktów danych i zdarzeń dyskretnych:

  • Zdarzenia dyskretne:
    • Platforma do udostępniania muzyki śledzi fakt, że konkretny użytkownik w określonej dzierżawie słuchał określonego utworu muzycznego.
    • W aplikacji internetowej ze sklepu online aplikacja wykazu wysyła zdarzenie przy użyciu wzorca Publisher-Subscriber do innych aplikacji w celu powiadomienia ich o zmianie ceny elementu.
    • Firma produkcyjna wypycha informacje w czasie rzeczywistym do klientów i innych firm na temat konserwacji sprzętu, kondycji systemów i aktualizacji kontraktów.
  • Punkty danych:
    • System sterowania budynkiem odbiera zdarzenia telemetryczne, takie jak odczyty temperatury lub wilgotności z czujników należących do wielu klientów.
    • System monitorowania sterowany zdarzeniami odbiera i przetwarza dzienniki diagnostyczne niemal w czasie rzeczywistym z wielu usług, takich jak serwery internetowe.
    • Skrypt po stronie klienta na stronie internetowej zbiera akcje użytkownika i wysyła je do rozwiązania analizy kliknięć.
  • Wiadomości:
    • Aplikacja finansowa B2B otrzymuje komunikat o rozpoczęciu przetwarzania rekordów bankowych dzierżawy.
    • Długotrwały przepływ pracy odbiera komunikat, który wyzwala wykonanie następnego kroku.
    • Aplikacja koszyka aplikacji sklepu online wysyła polecenie CreateOrder przy użyciu asynchronicznego, trwałego komunikatu do aplikacji zamawiania.

Kluczowe zagadnienia i wymagania

Wybrany model wdrażania i dzierżawy ma głęboki wpływ na zabezpieczenia, wydajność, izolację danych, zarządzanie i możliwość naliczania kosztów zasobów między opłatami dla dzierżaw. Ta analiza obejmuje model wybrany dla infrastruktury obsługi komunikatów i zdarzeń. W tej sekcji zapoznamy się z niektórymi kluczowymi decyzjami, które należy podjąć podczas planowania systemu obsługi komunikatów w rozwiązaniu wielodostępnym.

Skaluj

Liczba dzierżaw, złożoność przepływów komunikatów i strumieni zdarzeń, liczba komunikatów, oczekiwany profil ruchu i poziom izolacji powinien kierować decyzje podczas planowania infrastruktury obsługi komunikatów lub zdarzeń.

Pierwszy krok polega na przeprowadzeniu wyczerpującego planowania pojemności i ustanowieniu niezbędnej maksymalnej pojemności systemu obsługi komunikatów pod względem przepływności w celu prawidłowego obsługi oczekiwanej liczby komunikatów w ramach regularnego lub szczytowego ruchu.

Niektóre oferty usług, takie jak warstwa Premium usługi Azure Service Bus, zapewniają izolację zasobów na poziomie procesora CPU i pamięci, dzięki czemu każde obciążenie klienta działa w izolacji. Ten kontener zasobów jest nazywany jednostką obsługi komunikatów. Każda przestrzeń nazw w warstwie Premium ma przydzieloną co najmniej jedną jednostkę obsługi komunikatów. Możesz kupić 1, 2, 4, 8 lub 16 jednostek obsługi komunikatów dla każdej przestrzeni nazw usługi Service Bus Premium. Pojedyncze obciążenie lub jednostka może obejmować wiele jednostek obsługi komunikatów i w razie potrzeby można zmienić liczbę jednostek obsługi komunikatów. Wynikiem jest przewidywalna i powtarzalna wydajność rozwiązania opartego na usłudze Service Bus. Aby uzyskać więcej informacji, zobacz Warstwy obsługi komunikatów w warstwie Premium i Standardowa usługi Service Bus. Podobnie warstwy cenowe usługi Azure Event Hubs umożliwiają rozmiar przestrzeni nazw na podstawie oczekiwanej liczby zdarzeń przychodzących i wychodzących. Na przykład oferta Premium jest rozliczana według jednostek przetwarzania (PU), które odpowiadają udziałowi izolowanych zasobów (procesora CPU, pamięci i magazynu) w infrastrukturze bazowej. Efektywna przepływność pozyskiwania i przesyłania strumieniowego na jednostkę pu zależy od następujących czynników:

  • Liczba producentów i konsumentów
  • Rozmiar ładunku
  • Liczba partycji
  • Szybkość żądań ruchu wychodzącego
  • Użycie funkcji przechwytywania, rejestru schematów i innych zaawansowanych funkcji usługi Event Hubs

Aby uzyskać więcej informacji, zobacz Omówienie usługi Event Hubs Premium.

Gdy rozwiązanie obsługuje znaczną liczbę dzierżaw i decydujesz się na wdrożenie oddzielnego systemu obsługi komunikatów dla każdej dzierżawy, musisz mieć spójną strategię automatyzacji wdrażania, monitorowania, alertów i skalowania każdej infrastruktury, niezależnie od siebie.

Na przykład system obsługi komunikatów dla danej dzierżawy można wdrożyć podczas procesu aprowizacji przy użyciu narzędzia infrastruktury jako kodu (IaC), takiego jak Terraform, Bicep lub Szablony JSON usługi Azure Resource Manager (ARM) i system DevOps, taki jak Azure DevOps lub GitHub Actions. Aby uzyskać więcej informacji, zobacz Metody architektury wdrażania i konfiguracji rozwiązań wielodostępnych.

System obsługi komunikatów może mieć rozmiar z maksymalną przepływnością w komunikatach na jednostkę czasu. Jeśli system obsługuje dynamiczne skalowanie automatyczne, jego pojemność może zostać zwiększona lub zmniejszona automatycznie na podstawie warunków ruchu i metryk spełniających oczekiwaną umowę dotyczącą poziomu usług.

Przewidywalność wydajności i niezawodność

Podczas projektowania i tworzenia systemu obsługi komunikatów dla ograniczonej liczby dzierżawców użycie jednego systemu obsługi komunikatów może być doskonałym rozwiązaniem spełniającym wymagania funkcjonalne, pod względem przepływności i może zmniejszyć całkowity koszt posiadania. Aplikacja wielodostępna może współdzielić te same jednostki obsługi komunikatów, takie jak kolejki i tematy dla wielu klientów. Mogą też używać dedykowanego zestawu składników dla każdego z nich, aby zwiększyć izolację dzierżawy. Z drugiej strony udostępnianie tej samej infrastruktury obsługi komunikatów w wielu dzierżawach może spowodować uwidocznienie całego rozwiązania problemu z hałaśliwym sąsiadem. Aktywność jednej dzierżawy może zaszkodzić innym dzierżawcom, pod względem wydajności i możliwości działania.

W takim przypadku system obsługi komunikatów powinien mieć prawidłowy rozmiar, aby utrzymać oczekiwane obciążenie ruchu w czasie szczytu. Najlepiej jest obsługiwać skalowanie automatyczne. System obsługi komunikatów powinien dynamicznie skalować się w poziomie, gdy ruch wzrasta i skaluje się, gdy ruch spada. Dedykowany system obsługi komunikatów dla każdej dzierżawy może również ograniczyć ryzyko hałaśliwego sąsiada, ale zarządzanie dużą liczbą systemów obsługi komunikatów może zwiększyć złożoność rozwiązania.

Aplikacja wielodostępna może ostatecznie przyjąć podejście hybrydowe, w którym podstawowe usługi korzystają z 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 w celu ograniczenia problemu z głośnym sąsiadem i zagwarantowania izolacji danych.

Podczas wdrażania systemu obsługi komunikatów na maszynach wirtualnych należy współlokować te maszyny wirtualne z zasobami obliczeniowymi, aby zmniejszyć opóźnienie sieci. Te maszyny wirtualne nie powinny być udostępniane innym usługom lub aplikacjom, aby uniknąć infrastruktury obsługi komunikatów w celu konkurowania o zasoby systemowe, takie jak procesor CPU, pamięć i przepustowość sieci z innymi systemami. Maszyny wirtualne mogą również rozprzestrzeniać się w różnych strefach dostępności, aby zwiększyć odporność wewnątrz regionu i niezawodność obciążeń krytycznych dla działania firmy, w tym systemów obsługi komunikatów. Załóżmy, że decydujesz się na hostowanie systemu obsługi komunikatów, takiego jak RabbitMQ lub Apache ActiveMQ, na maszynach wirtualnych. W takim przypadku zalecamy wdrożenie go w zestawie skalowania maszyn wirtualnych i skonfigurowanie go na potrzeby skalowania automatycznego na podstawie metryk, takich jak procesor CPU lub pamięć. W ten sposób liczba węzłów agenta hostujących system obsługi komunikatów będzie prawidłowo skalować w poziomie i skalować w poziomie na podstawie warunków ruchu. Aby uzyskać więcej informacji, zobacz Omówienie skalowania automatycznego za pomocą zestawów skalowania maszyn wirtualnych platformy Azure.

Podobnie podczas hostowania systemu obsługi komunikatów w klastrze Kubernetes należy rozważyć użycie selektorów węzłów i defektów, aby zaplanować wykonywanie jego zasobników w dedykowanej puli węzłów, a nie współużytkowane z innymi obciążeniami, aby uniknąć problemu z hałaśliwym sąsiadem. Podczas wdrażania systemu obsługi komunikatów w klastrze AKS strefowo nadmiarowym należy użyć ograniczeń rozprzestrzeniania się topologii zasobników, aby kontrolować sposób dystrybucji zasobników w klastrze usługi AKS między domenami awarii, takimi jak regiony, strefy dostępności i węzły. W przypadku hostowania systemu obsługi komunikatów innych firm w usłudze AKS użyj skalowania automatycznego kubernetes, aby dynamicznie skalować liczbę węzłów roboczych, gdy ruch wzrasta. Dzięki narzędziu Horizontal Pod Autoscaler i AKS cluster autoscaler, node and pod woluminy są dynamicznie dostosowywane w czasie rzeczywistym, aby dopasować się do stanu ruchu i uniknąć przestojów spowodowanych problemami z pojemnością. Aby uzyskać więcej informacji, zobacz Automatyczne skalowanie klastra w celu spełnienia wymagań aplikacji w usłudze Azure Kubernetes Service (AKS). Rozważ użycie skalowania automatycznego opartego na platformie Kubernetes (KEDA), jeśli chcesz skalować w poziomie liczbę zasobników systemu obsługi komunikatów hostowanego przez platformę Kubernetes, takiego jak RabbitMQ lub Apache ActiveMQ, na podstawie długości danej kolejki. Za pomocą usługi KEDA można zwiększyć skalowanie dowolnego kontenera na platformie Kubernetes na podstawie liczby zdarzeń, które należy przetworzyć. Na przykład można użyć KEDA do skalowania aplikacji na podstawie długości kolejki usługi Azure Service Bus, kolejki RabbitMQ lub kolejki ActiveMQ. Aby uzyskać więcej informacji na temat KEDA, zobacz Kubernetes Event-driven Autoscaling (Skalowanie automatyczne oparte na zdarzeniach platformy Kubernetes).

Izolacja

Podczas projektowania systemu obsługi komunikatów dla rozwiązania wielodostępnego należy wziąć pod uwagę, że różne typy aplikacji wymagają innego rodzaju izolacji, która jest oparta na wymaganiach dotyczących wydajności, prywatności i inspekcji dzierżawców.

  • Wiele dzierżaw może współdzielić te same jednostki obsługi komunikatów, takie jak kolejki, tematy i subskrypcje, w tym samym systemie obsługi komunikatów. Na przykład aplikacja wielodostępna może odbierać komunikaty przenoszące dane dla wielu dzierżaw z jednej kolejki usługi Azure Service Bus . To rozwiązanie może prowadzić do problemów z wydajnością i skalowalnością. Jeśli niektóre dzierżawy generują większą liczbę zamówień niż inne, może to spowodować zaległości komunikatów. Ten problem, znany również jako problem z hałaśliwym sąsiadem, może obniżyć umowę dotyczącą poziomu usług pod względem opóźnienia dla niektórych dzierżaw. Problem jest bardziej oczywisty, jeśli aplikacja konsumenta odczytuje i przetwarza komunikaty z kolejki, pojedynczo, w ścisłej kolejności chronologicznej, a czas niezbędny do przetworzenia komunikatu zależy od liczby elementów w ładunku. W przypadku udostępniania co najmniej jednego zasobu kolejki w wielu dzierżawach infrastruktura obsługi komunikatów i systemy przetwarzania powinny być w stanie obsłużyć oczekiwany ruch oparty na wymaganiach dotyczących skalowania i przepływności. Takie podejście architektoniczne jest odpowiednie w tych scenariuszach, w których wielodostępne rozwiązanie przyjmuje jedną pulę procesów roboczych, aby odbierać, przetwarzać i wysyłać komunikaty dla wszystkich dzierżaw.
  • Wiele dzierżaw współużytkuje ten sam system obsługi komunikatów, ale korzysta z różnych zasobów tematu lub kolejki. Takie podejście zapewnia lepszą izolację i ochronę danych przy wyższych kosztach, zwiększoną złożoność operacyjną i niższą elastyczność, ponieważ administratorzy systemu muszą aprowizować, monitorować i utrzymywać większą liczbę zasobów kolejki. To rozwiązanie zapewnia spójne i przewidywalne środowisko dla wszystkich dzierżaw pod względem wydajności i umów dotyczących poziomu usług, ponieważ uniemożliwia każdej dzierżawie tworzenie wąskiego gardła, które może mieć wpływ na inne dzierżawy.
  • Oddzielny, dedykowany system obsługi komunikatów jest używany dla każdej dzierżawy. Na przykład wielodostępne rozwiązanie może używać odrębnej przestrzeni nazw usługi Azure Service Bus dla każdej dzierżawy. To rozwiązanie zapewnia maksymalny stopień izolacji przy wyższym stopniu złożoności i kosztach operacyjnych. Takie podejście gwarantuje spójną wydajność i umożliwia dostrajanie systemu obsługi komunikatów w oparciu o określone potrzeby dzierżawy. Po dołączeniu nowej dzierżawy oprócz w pełni dedykowanego systemu obsługi komunikatów aplikacja aprowizacji może również wymagać utworzenia oddzielnej tożsamości zarządzanej lub jednostki usługi z odpowiednimi uprawnieniami RBAC w celu uzyskania dostępu do nowo utworzonej przestrzeni nazw. Na przykład gdy klaster Kubernetes jest współużytkowany przez wiele wystąpień tej samej aplikacji SaaS, po jednym dla każdej dzierżawy, a każdy uruchomiony w oddzielnej przestrzeni nazw, każde wystąpienie aplikacji może używać innej jednostki usługi lub tożsamości zarządzanej w celu uzyskania dostępu do dedykowanego systemu obsługi komunikatów. W tym kontekście system obsługi komunikatów może być w pełni zarządzaną usługą PaaS, taką jak przestrzeń nazw usługi Azure Service Bus lub system obsługi komunikatów hostowany przez platformę Kubernetes, taki jak RabbitMQ. Podczas usuwania dzierżawy z systemu aplikacja powinna usunąć system obsługi komunikatów i dowolny dedykowany zasób utworzony wcześniej dla dzierżawy. Główną wadą tego podejścia jest to, że zwiększa złożoność operacyjną i zmniejsza elastyczność, zwłaszcza gdy liczba dzierżaw rośnie wraz z upływem czasu.

Zapoznaj się z następującymi dodatkowymi zagadnieniami i obserwacjami:

  • Jeśli dzierżawcy muszą używać własnego klucza do szyfrowania i odszyfrowywania komunikatów, rozwiązanie wielodostępne powinno zapewnić opcję wdrożenia oddzielnej przestrzeni nazw usługi Azure Service Bus Premium dla każdej dzierżawy. Aby uzyskać więcej informacji, zobacz Konfigurowanie kluczy zarządzanych przez klienta na potrzeby szyfrowania danych usługi Azure Service Bus magazynowanych.
  • Jeśli dzierżawcy potrzebują wysokiego poziomu odporności i ciągłości działania, wielodostępne rozwiązanie powinno zapewnić możliwość aprowizowania przestrzeni nazw usługi Service Bus Premium z włączonymi strefami odzyskiwania po awarii geograficznej i dostępności. Aby uzyskać więcej informacji, zobacz Geo-disaster recovery usługi Azure Service Bus.
  • W przypadku korzystania z oddzielnych zasobów kolejki lub dedykowanego systemu obsługi komunikatów dla każdej dzierżawy warto przyjąć oddzielną pulę procesów roboczych, dla każdego z nich zwiększyć poziom izolacji danych i zmniejszyć złożoność obsługi wielu jednostek 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 zapewnia lepszy poziom zabezpieczeń i izolację między dzierżawami, ale wymaga zwiększenia złożoności zarządzania tożsamościami.

Podobnie aplikacja sterowana zdarzeniami może zapewnić różne poziomy izolacji:

  • Aplikacja sterowana zdarzeniami odbiera zdarzenia z wielu dzierżaw za pośrednictwem jednego udostępnionego wystąpienia usługi Azure Event Hubs . To rozwiązanie zapewnia wysoki poziom elastyczności, ponieważ dołączanie nowej dzierżawy nie wymaga utworzenia dedykowanego zasobu pozyskiwania zdarzeń, ale zapewnia niski poziom ochrony danych, ponieważ przełącza komunikaty z wielu dzierżaw w tej samej strukturze danych.
  • Dzierżawcy mogą zdecydować się na dedykowane centrum zdarzeń lub temat platformy Kafka, aby uniknąć problemu Noisy Neighbor i spełnić wymagania dotyczące izolacji danych, gdy zdarzenia nie mogą być współmierne z innymi dzierżawami w celu zabezpieczenia i ochrony danych.
  • Jeśli dzierżawcy potrzebują wysokiego poziomu odporności i ciągłości działania, wielodostępny powinien zapewnić możliwość aprowizacji przestrzeni nazw usługi Event Hubs Premium z włączonymi strefami odzyskiwania po awarii geograficznej i dostępności. Aby uzyskać więcej informacji, zobacz Azure Event Hubs — odzyskiwanie po awarii geograficznej.
  • Usługa Event Hubs z włączoną funkcją przechwytywania usługi Event Hubs powinna zostać utworzona dla tych klientów, którzy muszą archiwizować zdarzenia na koncie usługi Azure Storage ze względów zgodności z przepisami i zobowiązań. Aby uzyskać więcej informacji, zobacz Przechwytywanie zdarzeń za pośrednictwem usługi Azure Event Hubs w usłudze Azure Blob Storage lub Azure Data Lake Storage.
  • Pojedyncza aplikacja wielodostępna może wysyłać powiadomienia do wielu systemów wewnętrznych i zewnętrznych przy użyciu usługi Azure Event Grid. W takim przypadku należy utworzyć oddzielną subskrypcję usługi Event Grid dla każdej aplikacji konsumenckiej. Jeśli aplikacja korzysta z wielu wystąpień usługi Event Grid do wysyłania powiadomień do dużej liczby organizacji zewnętrznych, rozważ użycie domen zdarzeń, które umożliwiają aplikacji publikowanie zdarzeń w tysiącach tematów, takich jak jeden dla każdej dzierżawy. Aby uzyskać więcej informacji, zobacz Omówienie domen zdarzeń do zarządzania tematami usługi Event Grid.

Złożoność implementacji

Podczas projektowania rozwiązania wielodostępnego należy wziąć pod uwagę, jak system będzie ewoluował w perspektywie średnio-długoterminowej, aby zapobiec rosnącej złożoności w miarę upływu czasu, dopóki nie będzie konieczne przeprojektowanie części lub całego rozwiązania. Ten przeprojektowanie pomoże Ci sprostać rosnącej liczbie dzierżaw. Podczas projektowania systemu obsługi komunikatów należy wziąć pod uwagę oczekiwany wzrost liczby komunikatów i dzierżaw w ciągu najbliższych kilku lat, a następnie utworzyć system, który może skalować w poziomie, aby nadążyć za przewidywanym ruchem i zmniejszyć złożoność operacji, takich jak aprowizowanie, monitorowanie i konserwacja.

Rozwiązanie powinno automatycznie tworzyć lub usuwać niezbędne jednostki obsługi komunikatów za każdym razem, gdy aplikacja dzierżawy jest aprowizowana lub nieprowizowana, bez konieczności ręcznego wykonywania operacji.

Szczególnym problemem dla wielodostępnych rozwiązań danych jest poziom dostosowywania, który obsługujesz. Każde dostosowanie powinno być konfigurowane automatycznie i stosowane przez system aprowizacji aplikacji (na przykład system DevOps), który jest oparty na zestawie parametrów początkowych, za każdym razem, gdy wdrażana jest aplikacja z jedną dzierżawą lub aplikacją wielodostępną.

Złożoność zarządzania i operacji

Zaplanuj od początku 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 możliwości:

  • Możesz zaplanować hostowanie systemu obsługi komunikatów używanego przez aplikację w dedykowanym zestawie maszyn wirtualnych, po jednym dla każdej dzierżawy. Jeśli tak, jak planujesz wdrożyć, uaktualnić, monitorować i skalować te systemy w poziomie?
  • Podobnie, jeśli konteneryzujesz i hostujesz system obsługi komunikatów w udostępnionym klastrze Kubernetes, jak planujesz wdrożyć, uaktualnić, monitorować i skalować poszczególne systemy obsługi komunikatów?
  • Załóżmy, że udostępniasz system obsługi komunikatów w wielu dzierżawach. Jak rozwiązanie może zbierać i zgłaszać metryki użycia poszczególnych dzierżaw lub ograniczać liczbę komunikatów, które każda dzierżawa może wysyłać lub odbierać?
  • Jeśli system obsługi komunikatów korzysta z usługi PaaS, takiej jak Azure Service Bus, należy zadać następujące pytanie:
  • Jak przeprowadzić migrację dzierżaw, jeśli będą musieli przejść do innego typu usługi obsługi komunikatów, innego wdrożenia lub innego regionu?

Koszt

Ogólnie rzecz biorąc, im większa gęstość dzierżaw w infrastrukturze wdrażania, tym niższy koszt aprowizacji tej infrastruktury. Jednak współdzielona infrastruktura zwiększa prawdopodobieństwo problemów, takich jak problem Noisy Neighbor, więc należy dokładnie rozważyć kompromisy.

Podejścia i wzorce do rozważenia

Kilka wzorców projektowych chmury z Centrum architektury platformy Azure można zastosować do wielodostępnego systemu obsługi komunikatów. Możesz zdecydować się na spójne obserwowanie co najmniej jednego wzorca lub rozważ mieszanie i dopasowywanie wzorców w zależności od potrzeb. Możesz na przykład użyć wielodostępnej przestrzeni nazw usługi Service Bus dla większości dzierżaw, ale możesz wdrożyć dedykowaną przestrzeń nazw usługi Service Bus z jedną dzierżawą dla tych dzierżaw, którzy płacą więcej lub którzy mają wyższe wymagania, pod względem izolacji i wydajności. Podobnie często dobrym rozwiązaniem jest skalowanie przy użyciu sygnatur wdrożenia, nawet jeśli używasz wielodostępnej przestrzeni nazw usługi Service Bus lub dedykowanych przestrzeni nazw w ramach sygnatury.

Wzorzec sygnatur wdrażania

Aby uzyskać więcej informacji na temat wzorca sygnatur wdrażania i wielodostępności, zobacz sekcję Wzorzec sygnatur wdrażania w temacie Metody architektury dla wielodostępności. Aby uzyskać więcej informacji na temat modeli dzierżawy, zobacz Modele dzierżawy, które należy wziąć pod uwagę w przypadku rozwiązania wielodostępnego.

System obsługi komunikatów udostępnionych

Możesz rozważyć wdrożenie udostępnionego systemu obsługi komunikatów, takiego jak usługa Azure Service Bus, i udostępnienie go we wszystkich dzierżawach.

Diagram przedstawiający jeden udostępniony wielodostępny system obsługi komunikatów dla wszystkich dzierżaw.

Takie podejście zapewnia najwyższą gęstość dzierżaw w infrastrukturze, dzięki czemu zmniejsza całkowity koszt posiadania. Często zmniejsza to również obciążenie związane z zarządzaniem, ponieważ istnieje jeden system obsługi komunikatów lub zasób do zarządzania i zabezpieczania.

Jeśli jednak współużytkujesz zasób lub całą infrastrukturę w wielu dzierżawach, rozważ następujące zastrzeżenia:

  • Należy pamiętać o ograniczeniach, możliwościach skalowania, limitach przydziału i limitach danego zasobu. Na przykład maksymalna liczba przestrzeni nazw usługi Service Bus w subskrypcji platformy Azure, maksymalna liczba usługi Event Hubs w jednej przestrzeni nazw lub maksymalne limity przepływności może ostatecznie stać się twardą blokadą, jeśli i kiedy architektura wzrośnie do obsługi większej liczby dzierżaw. Starannie rozważ maksymalną skalę, którą należy osiągnąć pod względem liczby przestrzeni nazw na pojedynczą subskrypcję platformy Azure lub kolejki na jedną przestrzeń nazw. Następnie porównaj bieżące i przyszłe oszacowania z istniejącymi limitami przydziałów i limitami wybranego systemu obsługi komunikatów, zanim wybierzesz ten wzorzec.
  • Jak wspomniano w powyższych sekcjach, problem z hałaśliwym sąsiadem może stać się czynnikiem, gdy współużytkujesz zasób w wielu dzierżawach, zwłaszcza jeśli niektóre są szczególnie zajęte lub generują większy ruch niż inne. W takim przypadku rozważ zastosowanie wzorca ograniczania przepustowości lub wzorca ograniczania szybkości w celu ograniczenia tych skutków. Można na przykład ograniczyć maksymalną liczbę komunikatów, które pojedyncza dzierżawa może wysyłać lub odbierać w jednostce czasu.
  • Być może masz trudności z monitorowaniem działania i pomiarem zużycia zasobów dla jednej dzierżawy. Niektóre usługi, takie jak Azure Service Bus, pobierają opłaty za operacje obsługi komunikatów. W związku z tym po udostępnieniu przestrzeni nazw w wielu dzierżawach aplikacja powinna mieć możliwość śledzenia liczby operacji obsługi komunikatów wykonywanych w imieniu każdej dzierżawy oraz kosztów obciążeń zwrotnych. 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 ustawienia nie są zgodne z konfiguracją systemu obsługi komunikatów, być może nie będzie można uwzględnić ich tylko przy użyciu jednego zasobu.

Sharding pattern (Wzorzec fragmentowania)

Wzorzec fragmentowania obejmuje wdrażanie wielu systemów obsługi komunikatów, nazywanych fragmentami, które zawierają 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ą, że cała infrastruktura jest duplikowana. Systemy obsługi komunikatów fragmentów mogą również nie duplikować ani fragmentować inną infrastrukturę w rozwiązaniu.

Diagram przedstawiający system obsługi komunikatów podzielonych na fragmenty. Jeden system obsługi komunikatów zawiera kolejki dla dzierżaw A i B, a drugi zawiera kolejki dla dzierżawy C.

Każdy system obsługi komunikatów lub fragment mogą mieć różne cechy pod względem niezawodności, jednostki SKU i lokalizacji. Można na przykład fragmentować dzierżawy w wielu systemach obsługi komunikatów o różnych cechach, na podstawie ich lokalizacji lub potrzeb w zakresie wydajności, niezawodności, ochrony danych lub ciągłości działania.

W przypadku korzystania ze wzorca fragmentowania należy użyć strategii fragmentowania, aby zamapować daną dzierżawę na system obsługi komunikatów zawierający jego kolejki. Strategia wyszukiwania używa mapy do inicjowania docelowego systemu obsługi komunikatów na podstawie nazwy dzierżawy lub identyfikatora. Wiele dzierżaw może współdzielić ten sam fragment, ale jednostki obsługi komunikatów używane przez jedną dzierżawę nie będą rozłożone na wiele fragmentów. Mapę można zaimplementować za pomocą pojedynczego słownika, który mapuje nazwę dzierżawy na nazwę lub odwołanie do docelowego systemu obsługi komunikatów. Mapa może być przechowywana w rozproszonej pamięci podręcznej dostępnej dla wszystkich wystąpień aplikacji wielodostępnej lub w magazynie trwałym, takim jak tabela w relacyjnej bazie danych lub tabeli na koncie magazynu.

Wzorzec fragmentowania może być skalowany do bardzo dużej liczby dzierżaw. Ponadto w zależności od obciążenia może być możliwe osiągnięcie wysokiej gęstości dzierżaw do fragmentów, dzięki czemu koszt może być atrakcyjny. Wzorzec fragmentowania może również służyć do obsługi limitów przydziałów, limitów i ograniczeń subskrypcji i usług platformy Azure.

Wielodostępna aplikacja z dedykowanym systemem obsługi komunikatów dla każdej dzierżawy

Innym typowym podejściem jest wdrożenie pojedynczej wielodostępnej aplikacji z dedykowanymi systemami obsługi komunikatów dla każdej dzierżawy. W tym modelu dzierżawy masz niektóre składniki udostępnione, takie jak zasoby obliczeniowe, podczas gdy inne usługi są aprowidowane i zarządzane 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ć poszczególne systemy obsługi komunikatów dla każdej dzierżawy, jak pokazano na poniższej ilustracji.

Diagram przedstawiający różne systemy obsługi komunikatów dla każdej dzierżawy.

Wdrożenia partycjonowane w poziomie mogą pomóc w rozwiązaniu problemu hałaśliwego sąsiada, jeśli zidentyfikowano, że większość obciążenia systemu jest spowodowana konkretnymi składnikami, które można wdrożyć oddzielnie dla każdej dzierżawy. Na przykład może być konieczne użycie oddzielnego systemu przesyłania komunikatów lub przesyłania strumieniowego zdarzeń dla każdej dzierżawy, ponieważ pojedyncze wystąpienie nie wystarczy, aby nadążyć za ruchem generowanym przez wiele dzierżaw. W przypadku korzystania z dedykowanego systemu obsługi komunikatów dla każdej dzierżawy, jeśli jedna dzierżawa powoduje dużą liczbę komunikatów lub zdarzeń, może to mieć wpływ na udostępnione składniki, ale nie systemy obsługi komunikatów innych dzierżawców.

Ponieważ aprowizujesz dedykowane zasoby dla każdej dzierżawy, koszt tej metody może być wyższy niż model hostingu współużytkowanego. Z drugiej strony łatwiej jest obciążać koszty zasobów dedykowanego systemu dla unikatowej dzierżawy, która korzysta z niego podczas wdrażania tego modelu dzierżawy. Takie podejście pozwala osiągnąć wysoką gęstość dla innych usług, takich jak zasoby obliczeniowe, i zmniejsza koszty tych składników.

W przypadku wdrożenia partycjonowanego w poziomie należy wdrożyć zautomatyzowany proces wdrażania usług aplikacji wielodostępnych i zarządzania nimi, zwłaszcza tych używanych przez jedną dzierżawę.

Wzorzec geody

Wzorzec geode obejmuje wdrożenie kolekcji usług zaplecza w zestawie węzłów geograficznych. Każdy może obsługiwać dowolne żądanie dla dowolnego klienta w dowolnym regionie. Ten wzorzec umożliwia obsługę żądań w stylu aktywny-aktywny, co zwiększa opóźnienie i zwiększa dostępność, dystrybuując przetwarzanie żądań na całym świecie.

Diagram przedstawiający wzorzec geode z systemami obsługi komunikatów wdrożonym w wielu regionach, które synchronizują się ze sobą.

Usługi Azure Service Bus i Azure Event Hubs obsługują odzyskiwanie po awarii metadanych w przestrzeniach nazw odzyskiwania po awarii podstawowej i pomocniczej oraz w oddzielnych regionach i strefach dostępności, aby zapewnić obsługę najlepszej odporności wewnątrz regionu. Ponadto usługi Azure Service Bus i Azure Event Hubs implementują zestaw wzorców federacyjnych, które aktywnie replikują ten sam logiczny temat, kolejkę lub centrum zdarzeń, aby być dostępne w wielu przestrzeniach nazw, ostatecznie zlokalizowanych w różnych regionach. Aby uzyskać więcej informacji, zobacz następujące zasoby:

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

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

Inni współautorzy:

Następne kroki

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