Dela via

Arkitekturmetoder för meddelanden i lösningar med flera klientorganisationer

  • Artikel

Asynkrona meddelanden och händelsedriven kommunikation är viktiga tillgångar när du skapar ett distribuerat program som består av flera interna och externa tjänster. När du utformar en lösning för flera klienter är det viktigt att utföra en preliminär analys för att definiera hur du delar eller partitionar meddelanden som gäller för olika klienter.

Att dela samma meddelandesystem eller händelseströmningstjänst kan avsevärt minska driftkostnaden och hanteringskomplexiteten. Men om du använder ett dedikerat meddelandesystem för varje klientorganisation får du bättre dataisolering, minskar risken för dataläckage, eliminerar problemet Med noisy neighbor kan du enkelt debitera tillbaka Azure-kostnader till klientorganisationer.

I den här artikeln kan du hitta en skillnad mellan meddelanden och händelser, och du hittar riktlinjer som lösningsarkitekter kan följa när de bestämmer vilken metod som ska användas för en meddelande- eller händelseinfrastruktur i en lösning med flera klientorganisationer.

Meddelanden, datapunkter och diskreta händelser

Alla meddelandesystem har liknande funktioner, transportprotokoll och användningsscenarier. De flesta moderna meddelandesystem stöder till exempel asynkron kommunikation som använder flyktiga eller beständiga köer, AMQP- och HTTPS-transportprotokoll, leverans minst en gång och så vidare. Men genom att titta närmare på typen av publicerad information och hur data förbrukas och bearbetas av klientprogram kan vi skilja mellan olika typer av meddelanden och händelser. Det finns en viktig skillnad mellan tjänster som levererar en händelse och system som skickar ett meddelande. Mer information finns i följande resurser:

Händelser

En händelse är ett enkelt meddelande om ett villkor eller en statusändring. Händelser kan vara diskreta enheter eller ingå i en serie. Händelser är meddelanden som vanligtvis inte förmedlar en utgivares avsikt annat än att informera. En händelse samlar in ett faktum och kommunicerar det till andra tjänster eller komponenter. En konsument av händelsen kan bearbeta händelsen som den vill och uppfyller inte några specifika förväntningar som utgivaren har. Vi kan klassificera händelser i två huvudkategorier:

  • Diskreta händelser innehåller information om specifika åtgärder som publiceringsprogrammet har utfört. När du använder asynkron händelsedriven kommunikation publicerar ett program en meddelandehändelse när något händer inom domänen. Ett eller flera förbrukande program måste vara medvetna om den här tillståndsändringen, till exempel en prisändring i ett produktkatalogprogram. Konsumenter prenumererar på händelserna för att ta emot dem asynkront. När en viss händelse inträffar kan de förbrukande programmen uppdatera sina domänentiteter, vilket kan leda till att fler integrationshändelser publiceras.
  • Seriehändelser innehåller informationsdatapunkter, till exempel temperaturavläsningar från enheter för analys eller användaråtgärder i en klickanalyslösning, som element i en pågående, kontinuerlig ström. En händelseström är relaterad till en specifik kontext, till exempel den temperatur eller luftfuktighet som rapporteras av en fältenhet. Alla händelser som är relaterade till samma kontext har en strikt tidsordning som är viktig vid bearbetning av dessa händelser med en motor för bearbetning av händelseströmmen. Analys av strömmar av händelser som bär datapunkter kräver att dessa händelser ackumuleras i en buffert som sträcker sig över ett önskat tidsfönster. Eller så kan det finnas i ett valt antal objekt och sedan bearbeta dessa händelser med hjälp av en nästan realtidslösning eller maskintränad algoritm. Analysen av en serie händelser kan ge signaler, till exempel medelvärdet av ett värde som mäts över ett tidsfönster som överskrider ett tröskelvärde. Dessa signaler kan sedan höjas som diskreta, åtgärdsbara händelser.

Diskreta händelser rapporterar tillståndsändringar och kan användas. Händelsenyttolasten innehåller information om vad som hände, men i allmänhet har den inte de fullständiga data som utlöste händelsen. En händelse meddelar till exempel konsumenterna att ett rapportprogram har skapat en ny fil i ett lagringskonto. Händelsenyttolasten kan ha allmän information om filen, men den har inte själva filen. Diskreta händelser är idealiska för serverlösa lösningar som behöver vara skalbara.

Seriehändelser rapporterar ett tillstånd och går att analysera. Diskreta händelser är tidsbeställda och sammankopplade. I vissa sammanhang måste konsumenten ta emot hela sekvensen med händelser för att analysera vad som hände och vidta nödvändiga åtgärder.

Meddelanden

Meddelanden innehåller rådata som skapas av en tjänst som ska användas eller lagras någon annanstans. Meddelanden innehåller ofta information som krävs för att en mottagande tjänst ska kunna utföra steg i ett arbetsflöde eller en bearbetningskedja. Ett exempel på den här typen av kommunikation är kommandomönstret. Utgivaren kan också förvänta sig att mottagare av ett meddelande kör en serie åtgärder och rapporterar resultatet av bearbetningen med ett asynkront meddelande. Det finns ett kontrakt mellan meddelandeutgivaren och meddelandemottagaren. Utgivaren skickar till exempel ett meddelande med vissa rådata och förväntar sig att konsumenten skapar en fil från dessa data och skickar tillbaka ett svarsmeddelande när det är klart. I andra situationer kan en avsändarprocess skicka ett asynkront envägsmeddelande för att be en annan tjänst att utföra en viss åtgärd, men utan att förvänta sig att få tillbaka ett bekräftelse- eller svarsmeddelande från den.

Den här typen av avtalsenlig meddelandehantering skiljer sig helt från en utgivare som publicerar diskreta händelser till en publik av konsumentagenter, utan någon specifik förväntan på hur de ska hantera dessa meddelanden.

Exempelscenarier

Här är en lista över några exempelscenarier för flera klientorganisationer för meddelanden, datapunkter och diskreta händelser:

  • Diskreta händelser:
    • En plattform för musikdelning spårar det faktum att en specifik användare i en specifik klientorganisation har lyssnat på ett visst musikspår.
    • I en webbapp i en onlinebutik skickar katalogprogrammet en händelse med mönstret Publisher-Subscriber till andra program för att meddela dem att ett artikelpris har ändrats.
    • Ett tillverkningsföretag skickar information i realtid till kunder och tredje part om underhåll av utrustning, systemhälsa och kontraktsuppdateringar.
  • Datapunkter:
    • Ett byggkontrollsystem tar emot telemetrihändelser, till exempel temperatur- eller fuktighetsavläsningar från sensorer som tillhör flera kunder.
    • Ett händelsedrivet övervakningssystem tar emot och bearbetar diagnostikloggar nästan i realtid från flera tjänster, till exempel webbservrar.
    • Ett skript på klientsidan på en webbsida samlar in användaråtgärder och skickar dem till en klickanalyslösning.
  • Meddelanden:
    • Ett B2B-ekonomiprogram får ett meddelande om att börja bearbeta en klients bankposter.
    • Ett långvarigt arbetsflöde tar emot ett meddelande som utlöser körningen av nästa steg.
    • Korgprogrammet för ett onlinebutiksprogram skickar ett CreateOrder-kommando med hjälp av ett asynkront, beständigt meddelande till beställningsprogrammet.

Viktiga överväganden och krav

Den distributions- och innehavarmodell som du väljer för din lösning har stor inverkan på säkerhet, prestanda, dataisolering, hantering och möjligheten att korsdebitera resurskostnader till klientorganisationer. Den här analysen innehåller den modell som du väljer för din meddelande- och händelseinfrastruktur. I det här avsnittet går vi igenom några av de viktiga beslut som du måste fatta när du planerar för ett meddelandesystem i din lösning för flera klientorganisationer.

Skala

Antalet klienter, komplexiteten i meddelandeflöden och händelseströmmar, mängden meddelanden, den förväntade trafikprofilen och isoleringsnivån bör driva besluten när du planerar för en meddelande- eller händelseinfrastruktur.

Det första steget består i att genomföra fullständig kapacitetsplanering och upprätta den maximala kapacitet som krävs för ett meddelandesystem när det gäller dataflöde för att hantera den förväntade volymen meddelanden under regelbunden eller hög trafik.

Vissa tjänsterbjudanden, till exempel Azure Service Bus Premium-nivån, tillhandahåller resursisolering på cpu- och minnesnivå så att varje kundarbetsbelastning körs isolerat. Den här resurscontainern kallas för en meddelandefunktionsenhet. Varje Premium-namnområde allokeras minst en meddelandefunktionsenhet. Du kan köpa 1, 2, 4, 8 eller 16 meddelandeenheter för varje Service Bus Premium-namnområde. En enskild arbetsbelastning eller en entitet kan sträcka sig över flera meddelandeenheter och du kan ändra antalet meddelandeenheter efter behov. Resultatet är en förutsägbar och repeterbar prestanda för din Service Bus-baserade lösning. Mer information finns i Service Bus Premium- och Standard-meddelandenivåer. På samma sätt gör azure Event Hubs-prisnivåer att du kan storleksanpassa namnområdet baserat på den förväntade volymen av inkommande och utgående händelser. Premium-erbjudandet debiteras till exempel av bearbetningsenheter (PUs) som motsvarar en del av isolerade resurser (CPU, minne och lagring) i den underliggande infrastrukturen. Det effektiva inmatnings- och dataflödet per PU beror på följande faktorer:

  • Antal producenter och konsumenter
  • Nyttolaststorlek
  • Antal partitioner
  • Utgående begärandefrekvens
  • Användning av Event Hubs Capture, Schema Registry och andra avancerade funktioner

Mer information finns i Översikt över Event Hubs Premium.

När din lösning hanterar ett stort antal klienter och du bestämmer dig för att införa ett separat meddelandesystem för varje klientorganisation måste du ha en konsekvent strategi för att automatisera distributionen, övervakningen, aviseringen och skalningen av varje infrastruktur, separat från varandra.

Ett meddelandesystem för en viss klientorganisation kan till exempel distribueras under etableringsprocessen med hjälp av ett IaC-verktyg (infrastruktur som kod), till exempel Terraform-, Bicep- eller Azure Resource Manager-JSON-mallar (ARM) och ett DevOps-system som Azure DevOps eller GitHub Actions. Mer information finns i Arkitekturmetoder för distribution och konfiguration av lösningar för flera klientorganisationer.

Meddelandesystemet kan vara storleksanpassat med ett maximalt dataflöde i meddelanden per tidsenhet. Om systemet stöder dynamisk autoskalning kan dess kapacitet ökas eller minskas automatiskt, baserat på trafikvillkoren och måtten för att uppfylla det förväntade serviceavtalet.

Prestandaöversägbarhet och tillförlitlighet

När du utformar och skapar ett meddelandesystem för ett begränsat antal klienter kan det vara en utmärkt lösning att använda ett enda meddelandesystem för att uppfylla funktionskraven, när det gäller dataflöde, och det kan minska den totala ägandekostnaden. Ett program med flera klientorganisationer kan dela samma meddelandeentiteter, till exempel köer och ämnen mellan flera kunder. Eller så kan de använda en dedikerad uppsättning komponenter för var och en för att öka klientisoleringen. Å andra sidan kan delning av samma meddelandeinfrastruktur mellan flera klienter göra hela lösningen tillgänglig för problemet Med bullrig granne. En klientorganisations aktivitet kan skada andra klienter när det gäller prestanda och driftsbarhet.

I det här fallet bör meddelandesystemet vara korrekt storleksanpassat för att upprätthålla den förväntade trafikbelastningen vid hög belastning. Helst bör den ha stöd för automatisk skalning. Meddelandesystemet bör skalas ut dynamiskt när trafiken ökar och skalas in när trafiken minskar. Ett dedikerat meddelandesystem för varje klientorganisation kan också minska risken för bullriga grannar, men att hantera ett stort antal meddelandesystem kan öka lösningens komplexitet.

Ett program med flera klientorganisationer kan så småningom använda en hybridmetod, där kärntjänster använder samma uppsättning köer och ämnen i ett enda, delat meddelandesystem för att implementera intern, asynkron kommunikation. Andra tjänster kan däremot införa en dedikerad grupp meddelandeentiteter eller till och med ett dedikerat meddelandesystem för varje klientorganisation för att minska problemet med bullriga grannar och garantera dataisolering.

När du distribuerar ett meddelandesystem till virtuella datorer bör du samplacera dessa virtuella datorer med beräkningsresurserna för att minska nätverksfördröjningen. Dessa virtuella datorer bör inte delas med andra tjänster eller program för att undvika att meddelandeinfrastrukturen konkurrerar om systemresurserna, till exempel CPU, minne och nätverksbandbredd med andra system. Virtuella datorer kan också spridas över tillgänglighetszonerna för att öka återhämtning inom regionen och tillförlitligheten för affärskritiska arbetsbelastningar, inklusive meddelandesystem. Anta att du bestämmer dig för att vara värd för ett meddelandesystem, till exempel RabbitMQ eller Apache ActiveMQ, på virtuella datorer. I så fall rekommenderar vi att du distribuerar den till en VM-skalningsuppsättning och konfigurerar den för automatisk skalning, baserat på mått som CPU eller minne. På så sätt kommer antalet agentnoder som är värdar för meddelandesystemet att skalas ut och skalas in korrekt baserat på trafikförhållanden. Mer information finns i Översikt över autoskalning med Skalningsuppsättningar för virtuella Azure-datorer.

När du är värd för meddelandesystemet i ett Kubernetes-kluster bör du överväga att använda nodväljare och taints för att schemalägga körningen av dess poddar på en dedikerad nodpool, som inte delas med andra arbetsbelastningar, för att undvika problemet med den bullriga grannen. När du distribuerar ett meddelandesystem till ett zonredundant AKS-kluster använder du begränsningar för spridning av poddtopologi för att styra hur poddar distribueras i AKS-klustret mellan feldomäner, till exempel regioner, tillgänglighetszoner och noder. När du är värd för ett meddelandesystem från tredje part i AKS använder du Kubernetes autoskalning för att dynamiskt skala ut antalet arbetsnoder när trafiken ökar. Med horizontal pod autoscaler och AKS-kluster autoskalning justeras nod- och poddvolymer dynamiskt i realtid för att matcha trafiktillståndet och för att undvika driftstopp som orsakas av kapacitetsproblem. Mer information finns i Skala ett kluster automatiskt för att uppfylla programkraven på Azure Kubernetes Service (AKS). Överväg att använda Kubernetes Even-Driven Autoscaling (KEDA) om du vill skala ut antalet poddar i ett Kubernetes-värdbaserat meddelandesystem, till exempel RabbitMQ eller Apache ActiveMQ, baserat på längden på en viss kö. Med KEDA kan du öka skalningen av alla containrar i Kubernetes, baserat på antalet händelser som behöver bearbetas. Du kan till exempel använda KEDA för att skala program baserat på längden på en Azure Service Bus-kö, en RabbitMQ-kö eller en ActiveMQ-kö. Mer information om KEDA finns i Kubernetes Händelsedriven autoskalning.

Isolering

När du utformar meddelandesystemet för en lösning med flera klienter bör du tänka på att olika typer av program kräver en annan typ av isolering, som baseras på klientorganisationens krav på prestanda, sekretess och granskning.

  • Flera klienter kan dela samma meddelandeentiteter, till exempel köer, ämnen och prenumerationer, i samma meddelandesystem. Ett program med flera klienter kan till exempel ta emot meddelanden som innehåller data för flera klientorganisationer, från en enda Azure Service Bus-kö . Den här lösningen kan leda till prestanda- och skalbarhetsproblem. Om vissa klienter genererar en större volym beställningar än andra kan detta orsaka kvarvarande meddelanden. Det här problemet, även kallat problem med den bullriga grannen, kan försämra servicenivåavtalet när det gäller svarstid för vissa klienter. Problemet är tydligare om konsumentprogrammet läser och bearbetar meddelanden från kön, en i taget, i en strikt kronologisk ordning, och om den tid som krävs för att bearbeta ett meddelande beror på antalet objekt i nyttolasten. När du delar en eller flera köresurser mellan flera klienter bör meddelandeinfrastrukturen och bearbetningssystemen kunna hantera den skalnings- och dataflödeskravbaserade förväntade trafiken. Den här arkitekturmetoden passar bra i de scenarier där en lösning med flera klienter använder en enda pool med arbetsprocesser för att ta emot, bearbeta och skicka meddelanden för alla klienter.
  • Flera klienter delar samma meddelandesystem men använder olika ämnes- eller köresurser. Den här metoden ger bättre isolering och dataskydd till en högre kostnad, ökad driftskomplexitet och lägre flexibilitet eftersom systemadministratörer måste etablera, övervaka och underhålla ett högre antal köresurser. Den här lösningen säkerställer en konsekvent och förutsägbar upplevelse för alla klienter, när det gäller prestanda- och serviceavtal, eftersom den förhindrar alla klienter från att skapa en flaskhals som kan påverka de andra klienterna.
  • Ett separat, dedikerat meddelandesystem används för varje klientorganisation. En lösning med flera klienter kan till exempel använda ett distinkt Azure Service Bus-namnområde för varje klientorganisation. Den här lösningen ger maximal grad av isolering, till en högre komplexitet och driftskostnad. Den här metoden garanterar konsekventa prestanda och möjliggör finjustering av meddelandesystemet baserat på specifika klientbehov. När en ny klientorganisation registreras kan etableringsprogrammet, förutom ett fullständigt dedikerat meddelandesystem, också behöva skapa en separat hanterad identitet eller ett huvudnamn för tjänsten med rätt RBAC-behörigheter för att få åtkomst till det nyligen skapade namnområdet. När till exempel ett Kubernetes-kluster delas av flera instanser av samma SaaS-program, en för varje klientorganisation och var och en körs i ett separat namnområde, kan varje programinstans använda ett annat tjänsthuvudnamn eller en hanterad identitet för att få åtkomst till ett dedikerat meddelandesystem. I det här sammanhanget kan meddelandesystemet vara en fullständigt hanterad PaaS-tjänst, till exempel ett Azure Service Bus-namnområde eller ett Kubernetes-värdbaserat meddelandesystem, till exempel RabbitMQ. När du tar bort en klientorganisation från systemet bör programmet ta bort meddelandesystemet och alla dedikerade resurser som skapades tidigare för klientorganisationen. Den största nackdelen med den här metoden är att den ökar driftkomplexiteten och minskar flexibiliteten, särskilt när antalet klienter växer över tid.

Granska följande ytterligare överväganden och observationer:

  • Om klientorganisationer behöver använda sin egen nyckel för att kryptera och dekryptera meddelanden bör en lösning med flera klienter ge möjlighet att införa ett separat Azure Service Bus Premium-namnområde för varje klientorganisation. Mer information finns i Konfigurera kundhanterade nycklar för kryptering av Azure Service Bus-data i vila.
  • Om klientorganisationer behöver en hög återhämtningsnivå och affärskontinuitet bör en lösning med flera klienter ge möjlighet att etablera ett Service Bus Premium-namnområde med geo-haveriberedskap och tillgänglighetszoner aktiverade. Mer information finns i Geo-haveriberedskap för Azure Service Bus.
  • När du använder separata köresurser eller ett dedikerat meddelandesystem för varje klientorganisation är det rimligt att anta en separat pool med arbetsprocesser för var och en av dem för att öka dataisoleringsnivån och minska komplexiteten i att hantera flera meddelandeentiteter. Varje instans av bearbetningssystemet kan använda olika autentiseringsuppgifter, till exempel en anslutningssträng, ett huvudnamn för tjänsten eller en hanterad identitet, för att få åtkomst till det dedikerade meddelandesystemet. Den här metoden ger en bättre säkerhetsnivå och isolering mellan klienter, men det kräver en ökad komplexitet i identitetshantering.

På samma sätt kan ett händelsedrivet program tillhandahålla olika isoleringsnivåer:

  • Ett händelsedrivet program tar emot händelser från flera klientorganisationer via en enda, delad Azure Event Hubs-instans . Den här lösningen ger en hög grad av flexibilitet eftersom registrering av en ny klient inte kräver att du skapar en dedikerad resurs för händelseinmatning, men den ger en låg dataskyddsnivå eftersom den sammanflätar meddelanden från flera klienter i samma datastruktur.
  • Klienter kan välja ett dedikerat händelsehubb eller Kafka-ämne för att undvika problemet Med bullriga grannar och för att uppfylla sina krav på dataisolering, när händelser inte får kombineras med andra klienters, för säkerhet och dataskydd.
  • Om klientorganisationer behöver en hög återhämtningsnivå och affärskontinuitet bör en multitenant ge möjlighet att etablera ett Event Hubs Premium-namnområde med geo-haveriberedskap och tillgänglighetszoner aktiverade. Mer information finns i Azure Event Hubs – Geo-haveriberedskap.
  • Dedikerade händelsehubbar med Event Hubs Capture aktiverat bör skapas för de kunder som behöver arkivera händelser till ett Azure Storage-konto av regelefterlevnadsskäl och skyldigheter. Mer information finns i Avbilda händelser via Azure Event Hubs i Azure Blob Storage eller Azure Data Lake Storage.
  • Ett enda program med flera klientorganisationer kan skicka meddelanden till flera interna och externa system med hjälp av Azure Event Grid. I det här fallet ska en separat Event Grid-prenumeration skapas för varje konsumentprogram. Om ditt program använder flera Event Grid-instanser för att skicka meddelanden till ett stort antal externa organisationer bör du överväga att använda händelsedomäner, vilket gör att ett program kan publicera händelser till tusentals ämnen, till exempel ett för varje klientorganisation. Mer information finns i Förstå händelsedomäner för att hantera Event Grid-ämnen.

Komplexiteten i implementeringen

När du utformar en lösning med flera klientorganisationer är det viktigt att tänka på hur systemet kommer att utvecklas på medellång till lång sikt, för att förhindra att dess komplexitet växer över tid tills det är nödvändigt att designa om en del av eller hela lösningen. Den här omdesignen hjälper dig att hantera ett ökande antal klienter. När du utformar ett meddelandesystem bör du överväga den förväntade ökningen av meddelandevolymer och klientorganisationer under de närmaste åren och sedan skapa ett system som kan skalas ut för att hålla jämna steg med den förväntade trafiken och minska komplexiteten i åtgärder, till exempel etablering, övervakning och underhåll.

Lösningen bör automatiskt skapa eller ta bort nödvändiga meddelandeentiteter varje gång ett klientprogram etableras eller avetableras, utan att behöva utföra manuella åtgärder.

Ett särskilt problem för datalösningar med flera klientorganisationer är den anpassningsnivå som du stöder. Alla anpassningar bör konfigureras och tillämpas automatiskt av programetableringssystemet (till exempel ett DevOps-system), som baseras på en uppsättning initiala parametrar, när ett program med en klientorganisation eller flera klientorganisationer distribueras.

Komplexiteten i hantering och åtgärder

Planera från början hur du tänker använda, övervaka och underhålla din meddelande- och händelseinfrastruktur samt hur multitenancy-metoden påverkar dina åtgärder och processer. Tänk till exempel på följande möjligheter:

  • Du kan planera att vara värd för meddelandesystemet som används av ditt program i en dedikerad uppsättning virtuella datorer, en för varje klientorganisation. I så fall, hur planerar du att distribuera, uppgradera, övervaka och skala ut dessa system?
  • På samma sätt, om du containeriserar och är värd för meddelandesystemet i ett delat Kubernetes-kluster, hur planerar du att distribuera, uppgradera, övervaka och skala ut enskilda meddelandesystem?
  • Anta att du delar ett meddelandesystem mellan flera klienter. Hur kan din lösning samla in och rapportera användningsstatistik per klientorganisation eller begränsa antalet meddelanden som varje klientorganisation kan skicka eller ta emot?
  • När meddelandesystemet använder en PaaS-tjänst, till exempel Azure Service Bus, bör du ställa följande fråga:
  • Hur migrerar du klienter om de behöver flytta till en annan typ av meddelandetjänst, en annan distribution eller en annan region?

Kostnad

Ju högre densitet klientorganisationer har i distributionsinfrastrukturen, desto lägre blir kostnaden för att etablera infrastrukturen. Delad infrastruktur ökar dock sannolikheten för problem som problem med bullriga grannar, så tänk noga på kompromisserna.

Metoder och mönster att tänka på

Flera molndesignmönster från Azure Architecture Center kan tillämpas på ett meddelandesystem med flera klientorganisationer. Du kan välja att följa ett eller flera mönster konsekvent, eller så kan du överväga att blanda och matcha mönster baserat på dina behov. Du kan till exempel använda ett Service Bus-namnområde med flera klientorganisationer för de flesta av dina klienter, men sedan kan du distribuera ett dedikerat Service Bus-namnområde med en enda klientorganisation för de klienter som betalar mer eller som har högre krav, när det gäller isolering och prestanda. På samma sätt är det ofta en bra idé att skala med hjälp av distributionsstämplar, även när du använder ett Service Bus-namnområde med flera klientorganisationer eller dedikerade namnområden inom en stämpel.

Mönster för distributionsstämplar

Mer information om mönstret Distributionsstämplar och flera klientorganisationer finns i avsnittet Mönster för distributionsstämplar i Arkitekturmetoder för flera klientorganisationer. Mer information om innehavarmodeller finns i Innehavarmodeller att överväga för en lösning med flera klientorganisationer.

System för delade meddelanden

Du kan överväga att distribuera ett system för delade meddelanden, till exempel Azure Service Bus, och dela det mellan alla dina klienter.

Diagram som visar ett enda delat meddelandesystem för flera klienter för alla klienter.

Den här metoden ger den högsta tätheten av klienter till infrastrukturen, så det minskar den totala totala ägandekostnaden. Det minskar också ofta hanteringskostnaderna, eftersom det finns ett enda meddelandesystem eller en enda resurs att hantera och skydda.

Tänk dock på följande när du delar en resurs eller en hel infrastruktur mellan flera klienter:

  • Tänk alltid på begränsningar, skalningsfunktioner, kvoter och begränsningar för den aktuella resursen. Till exempel kan det maximala antalet Service Bus-namnområden i en Azure-prenumeration, det maximala antalet händelsehubbar i ett enda namnområde eller de maximala dataflödesgränserna så småningom bli en hård blockering, om och när arkitekturen växer för att stödja fler klienter. Överväg noggrant den maximala skala som du behöver uppnå när det gäller antalet namnområden per enskild Azure-prenumeration eller köer per enskilt namnområde. Jämför sedan dina nuvarande och framtida uppskattningar med de befintliga kvoterna och gränserna för det meddelandesystem du väljer innan du väljer det här mönstret.
  • Som nämnts i ovanstående avsnitt kan problemet Med bullriga grannar bli en faktor när du delar en resurs mellan flera klienter, särskilt om vissa är särskilt upptagna eller om de genererar högre trafik än andra. I det här fallet bör du överväga att använda begränsningsmönstret eller mönstret Hastighetsbegränsning för att minimera dessa effekter. Du kan till exempel begränsa det maximala antalet meddelanden som en enskild klientorganisation kan skicka eller ta emot i tidsenheten.
  • Du kan ha svårt att övervaka aktiviteten och mäta resursförbrukningen för en enda klientorganisation. Vissa tjänster, till exempel Azure Service Bus, debiterar för meddelandeåtgärder. När du delar ett namnområde mellan flera klienter bör ditt program därför kunna hålla reda på antalet meddelandeåtgärder som utförs för varje klientorganisations räkning och kostnaderna för återbetalning till dem. Andra tjänster ger inte samma detaljnivå.

Klienter kan ha olika krav för säkerhet, återhämtning inom regionen, haveriberedskap eller plats. Om dessa inte matchar konfigurationen av meddelandesystemet kanske du inte kan hantera dem bara med en enda resurs.

Mönster för horisontell partitionering

Sharding-mönstretomfattar distribution av flera meddelandesystem, så kallade shards, som innehåller en eller flera klientorganisationers meddelandeentiteter, till exempel köer och ämnen. Till skillnad från distributionsstämplar innebär shards inte att hela infrastrukturen dupliceras. Du kan fragmentera meddelandesystem utan att även duplicera eller partitionera annan infrastruktur i din lösning.

Diagram som visar ett fragmenterat meddelandesystem. Ett meddelandesystem innehåller köerna för klientorganisationer A och B, och det andra innehåller köerna för klientorganisation C.

Varje meddelandesystem eller shard kan ha olika egenskaper när det gäller tillförlitlighet, SKU och plats. Du kan till exempel fragmentera dina klienter i flera meddelandesystem med olika egenskaper, baserat på deras plats eller behov när det gäller prestanda, tillförlitlighet, dataskydd eller affärskontinuitet.

När du använder fragmenteringsmönstret måste du använda en strategi för horisontell partitionering för att kunna mappa en viss klientorganisation till meddelandesystemet som innehåller dess köer. Uppslagsstrategin använder en karta för att anpassa målmeddelandesystemet baserat på klientorganisationens namn eller ID. Flera klienter kan dela samma shard, men meddelandeentiteterna som används av en enda klientorganisation sprids inte över flera shards. Kartan kan implementeras med en enda ordlista som mappar klientorganisationens namn till namnet eller referensen för målmeddelandesystemet. Kartan kan lagras i en distribuerad cache som är tillgänglig, av alla instanser av ett program med flera klientorganisationer eller i ett beständigt arkiv, till exempel en tabell i en relationsdatabas eller en tabell i ett lagringskonto.

Horisontell partitioneringsmönstret kan skalas till ett mycket stort antal klienter. Beroende på din arbetsbelastning kan du dessutom uppnå en hög densitet av klienter till shards, så att kostnaden kan vara attraktiv. Horisontell partitioneringsmönstret kan också användas för att hantera Azure-prenumerations- och tjänstkvoter, gränser och begränsningar.

Multitenant-app med dedikerade meddelandesystem för varje klientorganisation

En annan vanlig metod är att distribuera ett enda program med flera klienter, med dedikerade meddelandesystem för varje klientorganisation. I den här innehavarmodellen har du vissa delade komponenter, till exempel beräkningsresurser, medan andra tjänster etableras och hanteras med en dedikerad distributionsmetod för en enda klientorganisation. Du kan till exempel skapa en enda programnivå och sedan distribuera enskilda meddelandesystem för varje klientorganisation, som du ser i följande bild.

Diagram som visar olika meddelandesystem för varje klientorganisation.

Horisontellt partitionerade distributioner kan hjälpa dig att undvika problem med bullriga grannar, om du har upptäckt att den största delen av belastningen på systemet beror på specifika komponenter som du kan distribuera separat för varje klientorganisation. Du kan till exempel behöva använda ett separat meddelande- eller händelseströmningssystem för varje klient eftersom en enda instans inte räcker för att hålla jämna steg med trafik som genereras av flera klientorganisationer. När du använder ett dedikerat meddelandesystem för varje klientorganisation, om en enskild klientorganisation orsakar en stor mängd meddelanden eller händelser, kan detta påverka de delade komponenterna men inte andra klientorganisationers meddelandesystem.

Eftersom du etablerar dedikerade resurser för varje klientorganisation kan kostnaden för den här metoden vara högre än en delad värdmodell. Å andra sidan är det enklare att debitera tillbaka resurskostnader för ett dedikerat system till den unika klientorganisation som använder det när du använder den här innehavarmodellen. Med den här metoden kan du uppnå hög densitet för andra tjänster, till exempel beräkningsresurser, och det minskar dessa komponenters kostnader.

Med en horisontellt partitionerad distribution måste du införa en automatiserad process för att distribuera och hantera ett program med flera klientorganisationer, särskilt de som används av en enda klientorganisation.

Geodes-mönster

Geode-mönstret omfattar distribution av en samling serverdelstjänster till en uppsättning geografiska noder. Var och en kan hantera alla begäranden för alla klienter i valfri region. Med det här mönstret kan du hantera begäranden i ett aktivt-aktivt format, vilket förbättrar svarstiden och ökar tillgängligheten genom att distribuera bearbetning av begäranden över hela världen.

Diagram som visar Geode-mönstret, med meddelandesystem som distribueras i flera regioner som synkroniseras tillsammans.

Azure Service Bus och Azure Event Hubs har stöd för haveriberedskap för metadata, i namnområden för primär och sekundär haveriberedskap och i separata regioner och tillgänglighetszoner, för att ge stöd för bästa återhämtning inom regionen. Dessutom implementerar Azure Service Bus och Azure Event Hubs en uppsättning federationsmönster som aktivt replikerar samma logiska ämne, kö eller händelsehubb för att vara tillgängliga i flera namnområden, så småningom i olika regioner. Mer information finns i följande resurser:

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Övriga medarbetare:

Nästa steg

Mer information om designmönster för meddelanden finns i följande resurser: