Delen via

Architectuurbenaderingen voor berichten in multitenant-oplossingen

  • Artikel

Asynchrone berichten en gebeurtenisgestuurde communicatie zijn essentiële assets bij het bouwen van een gedistribueerde toepassing die bestaat uit verschillende interne en externe services. Wanneer u een multitenant-oplossing ontwerpt, is het van cruciaal belang om een voorlopige analyse uit te voeren om te definiëren hoe berichten moeten worden gedeeld of gepartitioneert die betrekking hebben op verschillende tenants.

Het delen van hetzelfde berichtensysteem of gebeurtenisstreamingservice kan de operationele kosten en beheercomplexiteit aanzienlijk verminderen. Het gebruik van een speciaal berichtensysteem voor elke tenant biedt echter een betere gegevensisolatie, vermindert het risico op gegevenslekken, elimineert het probleem Noisy Neighbor en maakt het mogelijk om uw Azure-kosten eenvoudig terug te brengen naar uw tenants.

In dit artikel vindt u een onderscheid tussen berichten en gebeurtenissen en vindt u richtlijnen die oplossingsarchitecten kunnen volgen bij het bepalen welke benadering moet worden gebruikt voor een berichten- of gebeurtenisinfrastructuur in een multitenant-oplossing.

Berichten, gegevenspunten en discrete gebeurtenissen

Alle berichtensystemen hebben vergelijkbare functies, transportprotocollen en gebruiksscenario's. De meeste moderne berichtensystemen ondersteunen bijvoorbeeld asynchrone communicatie die gebruikmaakt van vluchtige of permanente wachtrijen, AMQP- en HTTPS-transportprotocollen, ten minste eenmaal levering, enzovoort. Door echter nauwkeuriger te kijken naar het type gepubliceerde informatie en hoe gegevens worden gebruikt en verwerkt door clienttoepassingen, kunnen we onderscheid maken tussen verschillende soorten berichten en gebeurtenissen. Er is een essentieel onderscheid tussen services die een gebeurtenis en systemen leveren die een bericht verzenden. Voor meer informatie raadpleegt u de volgende bronnen:

gebeurtenis

Een gebeurtenis is een lichtgewicht melding van een voorwaarde of een statuswijziging. Gebeurtenissen kunnen afzonderlijke eenheden zijn of deel uitmaken van een reeks. Gebeurtenissen zijn berichten die over het algemeen niet de intentie van een uitgever overbrengen dan om ze te informeren. Een gebeurtenis legt een feit vast en communiceert deze met andere services of onderdelen. Een consument van de gebeurtenis kan de gebeurtenis verwerken zoals deze behadigt en voldoet niet aan specifieke verwachtingen van de uitgever. We kunnen gebeurtenissen classificeren in twee hoofdcategorieën:

  • Discrete gebeurtenissen bevatten informatie over specifieke acties die door de publicatietoepassing zijn uitgevoerd. Wanneer u asynchrone gebeurtenisgestuurde communicatie gebruikt, publiceert een toepassing een meldingsgebeurtenis wanneer er iets binnen het domein gebeurt. Een of meer verbruikende toepassingen moeten op de hoogte zijn van deze statuswijziging, zoals een prijswijziging in een productcatalogustoepassing. Consumenten abonneren zich op de gebeurtenissen om ze asynchroon te ontvangen. Wanneer een bepaalde gebeurtenis plaatsvindt, kunnen de verbruikende toepassingen hun domeinentiteiten bijwerken, waardoor er meer integratie-gebeurtenissen worden gepubliceerd.
  • Reeksgebeurtenissen bevatten informatieve gegevenspunten, zoals temperatuurmetingen van apparaten voor analyse of gebruikersacties in een oplossing voor klikanalyse, als elementen in een doorlopende, continue stroom. Een gebeurtenisstroom is gerelateerd aan een specifieke context, zoals de temperatuur of vochtigheid die door een veldapparaat wordt gerapporteerd. Alle gebeurtenissen met betrekking tot dezelfde context hebben een strikte tijdelijke volgorde die van belang is bij het verwerken van deze gebeurtenissen met een gebeurtenisstroomverwerkingsengine. Voor het analyseren van stromen van gebeurtenissen die gegevenspunten bevatten, moeten deze gebeurtenissen in een buffer worden verzameld die een gewenst tijdvenster beslaat. Of het kan zich in een geselecteerd aantal items bevinden en deze gebeurtenissen vervolgens verwerken met behulp van een bijna realtime oplossing of een door machines getraind algoritme. De analyse van een reeks gebeurtenissen kan signalen opleveren, zoals het gemiddelde van een waarde die wordt gemeten in een tijdvenster dat een drempelwaarde overschrijdt. Deze signalen kunnen vervolgens worden gegenereerd als discrete, bruikbare gebeurtenissen.

Discrete gebeurtenissen rapporteren statuswijzigingen en kunnen worden uitgevoerd. De nettolading van de gebeurtenis bevat informatie over wat er is gebeurd, maar over het algemeen beschikt deze niet over de volledige gegevens die de gebeurtenis hebben geactiveerd. Een gebeurtenis meldt bijvoorbeeld gebruikers dat een rapportagetoepassing een nieuw bestand in een opslagaccount heeft gemaakt. De nettolading van de gebeurtenis bevat mogelijk algemene informatie over het bestand, maar heeft het bestand zelf niet. Afzonderlijke gebeurtenissen zijn ideaal voor serverloze oplossingen die moeten worden geschaald.

Reeksgebeurtenissen rapporteren een voorwaarde en zijn analyseerbaar. Discrete gebeurtenissen zijn tijdgeordend en onderling verbonden. In sommige contexten moet de consument de volledige reeks gebeurtenissen ontvangen om te analyseren wat er is gebeurd en om de benodigde actie te ondernemen.

Berichten

Berichten bevatten onbewerkte gegevens die door een service worden geproduceerd om ergens anders te worden gebruikt of opgeslagen. Berichten bevatten vaak informatie die nodig is voor een ontvangende service om stappen uit te voeren in een werkstroom of een verwerkingsketen. Een voorbeeld van dit soort communicatie is het opdrachtpatroon. De uitgever kan ook verwachten dat de ontvanger(s) van een bericht een reeks acties uitvoert en het resultaat van de verwerking ervan rapporteert met een asynchroon bericht. Er bestaat een contract tussen de uitgever van het bericht en de ontvanger(s) van het bericht. De uitgever verzendt bijvoorbeeld een bericht met enkele onbewerkte gegevens en verwacht dat de consument een bestand maakt op basis van die gegevens en een antwoordbericht terugstuurt wanneer u klaar bent. In andere situaties kan een afzenderproces een asynchroon bericht in één richting verzenden om een andere service te vragen een bepaalde bewerking uit te voeren, maar zonder dat er een bevestigings- of antwoordbericht van wordt verwacht.

Dit soort contractuele berichtafhandeling verschilt van een uitgever die discrete gebeurtenissen publiceert voor een publiek van consumentenagenten, zonder dat er een specifieke verwachting is over hoe deze meldingen worden verwerkt.

Voorbeeldscenario's

Hier volgt een lijst met enkele voorbeeldscenario's met meerdere tenants voor berichten, gegevenspunten en discrete gebeurtenissen:

  • Discrete gebeurtenissen:
    • Een platform voor het delen van muziek houdt het feit bij dat een specifieke gebruiker in een specifieke tenant naar een bepaald muziekspoor heeft geluisterd.
    • In een online winkelwebtoepassing verzendt de catalogustoepassing een gebeurtenis met behulp van het patroon Publisher-Subscriber naar andere toepassingen om hen op de hoogte te stellen dat een itemprijs is gewijzigd.
    • Een productiebedrijf pusht realtime informatie naar klanten en derden over apparatuuronderhoud, systeemstatus en contractupdates.
  • Gegevenspunten:
    • Een gebouwbesturingssysteem ontvangt telemetrie-gebeurtenissen, zoals temperatuur- of vochtigheidsmetingen van sensoren die bij meerdere klanten horen.
    • Een gebeurtenisgestuurd bewakingssysteem ontvangt en verwerkt diagnostische logboeken in bijna realtime van meerdere services, zoals webservers.
    • Een script aan de clientzijde op een webpagina verzamelt gebruikersacties en verzendt deze naar een oplossing voor klikanalyse.
  • Berichten:
    • Een B2B-financieringstoepassing ontvangt een bericht om te beginnen met het verwerken van de bankgegevens van een tenant.
    • Een langlopende werkstroom ontvangt een bericht dat de uitvoering van de volgende stap activeert.
    • De winkelwagentoepassing van een online winkeltoepassing verzendt een opdracht CreateOrder met behulp van een asynchroon, permanent bericht naar de besteltoepassing.

Belangrijke overwegingen en vereisten

Het implementatie- en tenancymodel dat u voor uw oplossing kiest, heeft een grote invloed op beveiliging, prestaties, gegevensisolatie, beheer en de mogelijkheid om resourcekosten kruislings in rekening te brengen voor tenants. Deze analyse omvat het model dat u selecteert voor uw berichten- en gebeurtenisinfrastructuur. In deze sectie bekijken we enkele belangrijke beslissingen die u moet nemen wanneer u een berichtensysteem in uw multitenant-oplossing plant.

Schaal wijzigen

Het aantal tenants, de complexiteit van berichtstromen en gebeurtenisstromen, het volume berichten, het verwachte verkeersprofiel en het isolatieniveau moeten de beslissingen bepalen bij het plannen van een berichten- of gebeurtenisinfrastructuur.

De eerste stap bestaat uit het uitvoeren van een volledige capaciteitsplanning en het vaststellen van de benodigde maximale capaciteit voor een berichtensysteem in termen van doorvoer om het verwachte volume van berichten onder normaal of piekverkeer goed te verwerken.

Sommige serviceaanbiedingen, zoals de Azure Service Bus Premium-laag, bieden resource-isolatie op CPU- en geheugenniveau, zodat elke workload van de klant geïsoleerd wordt uitgevoerd. Deze resourcecontainer wordt een Messaging-eenheid genoemd. Aan elke Premium-naamruimte wordt ten minste één Messaging-eenheid toegewezen. U kunt 1, 2, 4, 8 of 16 berichteneenheden aanschaffen voor elke Service Bus Premium-naamruimte. Eén workload of entiteit kan meerdere berichteneenheden omvatten en u kunt het aantal berichteneenheden indien nodig wijzigen. Het resultaat is een voorspelbare en herhaalbare prestaties voor uw Service Bus-oplossing. Zie Service Bus Premium- en Standard-berichtenlagen voor meer informatie. Op dezelfde manier kunt u met azure Event Hubs-prijscategorieën de naamruimte aanpassen op basis van het verwachte volume van binnenkomende en uitgaande gebeurtenissen. De Premium-aanbieding wordt bijvoorbeeld gefactureerd door verwerkingseenheden (RU's), die overeenkomen met een share van geïsoleerde resources (CPU, geheugen en opslag) in de onderliggende infrastructuur. De effectieve opname- en stroomdoorvoer per PU is afhankelijk van de volgende factoren:

  • Aantal producenten en consumenten
  • Grootte van nettolading
  • Aantal partities
  • Aanvraagsnelheid voor uitgaand verkeer
  • Gebruik van Event Hubs Capture, Schema Registry en andere geavanceerde functies

Zie Overzicht van Event Hubs Premium voor meer informatie.

Wanneer uw oplossing een aanzienlijk aantal tenants afhandelt en u besluit een afzonderlijk berichtensysteem voor elke tenant te gebruiken, moet u een consistente strategie hebben om de implementatie, bewaking, waarschuwingen en schaalaanpassing van elke infrastructuur afzonderlijk van elkaar te automatiseren.

Een berichtensysteem voor een bepaalde tenant kan bijvoorbeeld worden geïmplementeerd tijdens het inrichtingsproces met behulp van een hulpprogramma voor infrastructuur als code (IaC), zoals een Terraform-, Bicep- of Azure Resource Manager-JSON-sjablonen (ARM) en een DevOps-systeem, zoals Azure DevOps of GitHub Actions. Zie Architectuurbenaderingen voor de implementatie en configuratie van multitenant-oplossingen voor meer informatie.

Het berichtensysteem kan een grootte hebben met een maximale doorvoer in berichten per tijdseenheid. Als het systeem dynamische automatische schaalaanpassing ondersteunt, kan de capaciteit ervan automatisch worden verhoogd of verlaagd, op basis van de verkeersvoorwaarden en metrische gegevens om te voldoen aan de verwachte service level agreement.

Voorspelbaarheid en betrouwbaarheid van prestaties

Bij het ontwerpen en bouwen van een berichtensysteem voor een beperkt aantal tenants kan het gebruik van één berichtensysteem een uitstekende oplossing zijn om te voldoen aan de functionele vereisten, qua doorvoer, en kan dit de totale eigendomskosten verlagen. Een toepassing met meerdere tenants kan dezelfde berichtenentiteiten delen, zoals wachtrijen en onderwerpen voor meerdere klanten. Of ze kunnen een toegewezen set onderdelen voor elk onderdeel gebruiken om tenantisolatie te vergroten. Aan de andere kant kan het delen van dezelfde berichteninfrastructuur voor meerdere tenants de hele oplossing blootstellen aan het probleem met Noisy Neighbor. De activiteit van één tenant kan schadelijk zijn voor andere tenants, wat betreft prestaties en operabiliteit.

In dit geval moet het berichtensysteem de juiste grootte hebben om de verwachte verkeersbelasting op piektijd te behouden. In het ideale geval moet deze ondersteuning bieden voor automatisch schalen. Het berichtensysteem moet dynamisch worden uitgeschaald wanneer het verkeer toeneemt en inschaalt wanneer het verkeer afneemt. Een speciaal berichtensysteem voor elke tenant kan ook het risico van ruis buurman beperken, maar het beheren van een groot aantal berichtensystemen kan de complexiteit van de oplossing verhogen.

Een multitenant-toepassing kan uiteindelijk een hybride benadering aannemen, waarbij de kernservices dezelfde set wachtrijen en onderwerpen gebruiken in één gedeeld berichtensysteem om interne, asynchrone communicatie te implementeren. Andere services kunnen daarentegen een toegewezen groep berichtenentiteiten of zelfs een speciaal berichtensysteem gebruiken om het probleem met Noisy Neighbor te beperken en gegevensisolatie te garanderen.

Wanneer u een berichtensysteem implementeert op virtuele machines, moet u deze virtuele machines samen met de rekenresources zoeken om de netwerklatentie te verminderen. Deze virtuele machines mogen niet worden gedeeld met andere services of toepassingen, om te voorkomen dat de berichteninfrastructuur om te concurreren met de systeemresources, zoals CPU, geheugen en netwerkbandbreedte met andere systemen. Virtuele machines kunnen zich ook verspreiden over de beschikbaarheidszones om de tolerantie en betrouwbaarheid van bedrijfskritieke workloads binnen de regio te vergroten, waaronder berichtensystemen. Stel dat u besluit een berichtensysteem te hosten, zoals RabbitMQ of Apache ActiveMQ, op virtuele machines. In dat geval raden we u aan deze te implementeren in een virtuele-machineschaalset en deze te configureren voor automatisch schalen, op basis van metrische gegevens, zoals CPU of geheugen. Op deze manier wordt het aantal agentknooppunten dat als host fungeert voor het berichtensysteem, correct uitgeschaald en ingeschaald op basis van verkeersomstandigheden. Zie Overzicht van automatische schaalaanpassing met virtuele-machineschaalsets van Azure voor meer informatie.

Overweeg ook bij het hosten van uw berichtensysteem op een Kubernetes-cluster knooppuntkiezers en taints te gebruiken om de uitvoering van de pods in een toegewezen knooppuntgroep te plannen, niet gedeeld met andere werkbelastingen, om het probleem met Noisy Neighbor te voorkomen. Wanneer u een berichtensysteem implementeert in een zoneredundant AKS-cluster, gebruikt u podtopologiebeperkingen om te bepalen hoe pods worden verdeeld over uw AKS-cluster tussen foutdomeinen, zoals regio's, beschikbaarheidszones en knooppunten. Wanneer u een berichtensysteem van derden host op AKS, gebruikt u Kubernetes automatisch schalen om het aantal werkknooppunten dynamisch uit te schalen wanneer het verkeer toeneemt. Met horizontale automatische schaalaanpassing van pods en AKS-clusters worden knooppunt- en podvolumes dynamisch aangepast in realtime, zodat deze overeenkomen met de verkeersvoorwaarde en om downtime te voorkomen die worden veroorzaakt door capaciteitsproblemen. Zie Automatisch een cluster schalen om te voldoen aan de toepassingsvereisten op Azure Kubernetes Service (AKS) voor meer informatie. Overweeg om Kubernetes Evengestuurde automatische schaalaanpassing (KEDA) te gebruiken als u het aantal pods van een Door Kubernetes gehost berichtensysteem, zoals RabbitMQ of Apache ActiveMQ, wilt uitschalen op basis van de lengte van een bepaalde wachtrij. Met KEDA kunt u het schalen van elke container in Kubernetes stimuleren op basis van het aantal gebeurtenissen dat moet worden verwerkt. U kunt keda bijvoorbeeld gebruiken om toepassingen te schalen op basis van de lengte van een Azure Service Bus-wachtrij, van een RabbitMQ-wachtrij of een ActiveMQ-wachtrij. Zie Voor meer informatie over KEDA Kubernetes Gebeurtenisgestuurde Automatische schaalaanpassing.

Isolatie

Bij het ontwerpen van het berichtensysteem voor een multitenant-oplossing moet u er rekening mee houden dat verschillende soorten toepassingen een ander soort isolatie vereisen, die is gebaseerd op de prestatie-, privacy- en controlevereisten van de tenants.

  • Meerdere tenants kunnen dezelfde berichtenentiteiten, zoals wachtrijen, onderwerpen en abonnementen, delen in hetzelfde berichtensysteem. Een toepassing met meerdere tenants kan bijvoorbeeld berichten ontvangen die gegevens voor meerdere tenants bevatten, vanuit één Azure Service Bus-wachtrij . Deze oplossing kan leiden tot prestatie- en schaalbaarheidsproblemen. Als sommige tenants een groter aantal orders genereren dan andere, kan dit leiden tot een achterstand van berichten. Dit probleem, ook wel bekend als het probleem met Noisy Neighbor, kan de service level agreement verminderen in termen van latentie voor sommige tenants. Het probleem is duidelijker als de consumententoepassing berichten uit de wachtrij leest en verwerkt, één voor één, in een strikte chronologische volgorde en als de tijd die nodig is om een bericht te verwerken, afhankelijk is van het aantal items in de nettolading. Wanneer u een of meer wachtrijresources deelt tussen meerdere tenants, moeten de berichteninfrastructuur en verwerkingssystemen geschikt zijn voor het verwachte verkeer op basis van schaal- en doorvoervereisten. Deze architectuurbenadering is geschikt voor deze scenario's waarbij een multitenant-oplossing één groep werkprocessen gebruikt om berichten voor alle tenants te ontvangen, te verwerken en te verzenden.
  • Meerdere tenants delen hetzelfde berichtensysteem, maar gebruiken verschillende onderwerp- of wachtrijresources. Deze aanpak biedt betere isolatie en gegevensbescherming tegen hogere kosten, een hogere operationele complexiteit en een lagere flexibiliteit, omdat systeembeheerders een hoger aantal wachtrijbronnen moeten inrichten, bewaken en onderhouden. Deze oplossing zorgt voor een consistente en voorspelbare ervaring voor alle tenants, wat betreft prestaties en serviceovereenkomsten, omdat elke tenant geen knelpunt kan maken dat van invloed kan zijn op de andere tenants.
  • Voor elke tenant wordt een afzonderlijk, toegewezen berichtensysteem gebruikt. Een multitenant-oplossing kan bijvoorbeeld een afzonderlijke Azure Service Bus-naamruimte voor elke tenant gebruiken. Deze oplossing biedt de maximale mate van isolatie, met een hogere complexiteit en operationele kosten. Deze aanpak garandeert consistente prestaties en maakt het mogelijk om het berichtensysteem af te stemmen op basis van specifieke tenantbehoeften. Wanneer een nieuwe tenant wordt toegevoegd, moet de inrichtingstoepassing naast een volledig toegewezen berichtensysteem mogelijk ook een afzonderlijke beheerde identiteit of een service-principal maken met de juiste RBAC-machtigingen voor toegang tot de zojuist gemaakte naamruimte. Wanneer een Kubernetes-cluster bijvoorbeeld wordt gedeeld door meerdere exemplaren van dezelfde SaaS-toepassing, één voor elke tenant en elk in een afzonderlijke naamruimte wordt uitgevoerd, kan elk toepassingsexemplaren een andere service-principal of beheerde identiteit gebruiken voor toegang tot een toegewezen berichtensysteem. In deze context kan het berichtensysteem een volledig beheerde PaaS-service zijn, zoals een Azure Service Bus-naamruimte of een Door Kubernetes gehost berichtensysteem, zoals RabbitMQ. Wanneer u een tenant uit het systeem verwijdert, moet de toepassing het berichtensysteem en alle toegewezen resources verwijderen die eerder voor de tenant zijn gemaakt. Het belangrijkste nadeel van deze aanpak is dat het operationele complexiteit verhoogt en flexibiliteit vermindert, vooral wanneer het aantal tenants na verloop van tijd groeit.

Bekijk de volgende aanvullende overwegingen en opmerkingen:

  • Als tenants hun eigen sleutel moeten gebruiken om berichten te versleutelen en ontsleutelen, moet een multitenant-oplossing de optie bieden om een afzonderlijke Azure Service Bus Premium-naamruimte voor elke tenant te gebruiken. Zie Door de klant beheerde sleutels configureren voor het versleutelen van Azure Service Bus-data-at-rest voor meer informatie.
  • Als tenants een hoog niveau van tolerantie en bedrijfscontinuïteit nodig hebben, moet een multitenant-oplossing de mogelijkheid bieden om een Service Bus Premium-naamruimte in te richten met geo-noodherstel en beschikbaarheidszones ingeschakeld. Zie Azure Service Bus Geo-disaster recovery (Geo-herstel na noodgeval in Azure Service Bus) voor meer informatie.
  • Wanneer u afzonderlijke wachtrijresources of een speciaal berichtensysteem voor elke tenant gebruikt, is het redelijk om een afzonderlijke groep werkprocessen te gebruiken, zodat elk van deze resources het niveau van gegevensisolatie verhoogt en de complexiteit van het omgaan met meerdere berichtenentiteiten vermindert. Elk exemplaar van het verwerkingssysteem kan verschillende referenties aannemen, zoals een verbindingsreeks, een service-principal of een beheerde identiteit, om toegang te krijgen tot het toegewezen berichtensysteem. Deze benadering biedt een beter beveiligingsniveau en isolatie tussen tenants, maar vereist een grotere complexiteit in identiteitsbeheer.

Op dezelfde manier kan een gebeurtenisgestuurde toepassing verschillende isolatieniveaus bieden:

  • Een gebeurtenisgestuurde toepassing ontvangt gebeurtenissen van meerdere tenants via één gedeeld Azure Event Hubs-exemplaar . Deze oplossing biedt een hoge mate van flexibiliteit, omdat het onboarden van een nieuwe tenant geen toegewezen resource voor gebeurtenisopname vereist, maar het biedt een laag gegevensbeveiligingsniveau, omdat het berichten van meerdere tenants in dezelfde gegevensstructuur tussen meerdere tenants in dezelfde gegevensstructuur plaatst.
  • Tenants kunnen kiezen voor een toegewezen Event Hub of Kafka-onderwerp om het probleem met Noisy Neighbor te voorkomen en te voldoen aan hun vereisten voor gegevensisolatie, wanneer gebeurtenissen niet mogen worden gecombineerd met die van andere tenants, voor beveiliging en gegevensbescherming.
  • Als tenants een hoog niveau van tolerantie en bedrijfscontinuïteit nodig hebben, moet een multitenant de mogelijkheid bieden om een Event Hubs Premium-naamruimte in te richten, waarbij geo-noodherstel en beschikbaarheidszones zijn ingeschakeld. Zie Azure Event Hubs - Herstel na geo-noodgeval voor meer informatie.
  • Toegewezen Event Hubs, waarvoor Event Hubs Capture is ingeschakeld, moeten worden gemaakt voor klanten die gebeurtenissen moeten archiveren in een Azure Storage-account, om redenen en verplichtingen op het gebied van naleving van regelgeving. Zie Capture events through Azure Event Hubs in Azure Blob Storage or Azure Data Lake Storage (gebeurtenissen opnemen via Azure Event Hubs in Azure Blob Storage of Azure Data Lake Storage) voor meer informatie.
  • Een enkele toepassing met meerdere tenants kan meldingen verzenden naar meerdere interne en externe systemen met behulp van Azure Event Grid. In dit geval moet er een afzonderlijk Event Grid-abonnement worden gemaakt voor elke consumententoepassing. Als uw toepassing gebruikmaakt van meerdere Event Grid-exemplaren om meldingen te verzenden naar een groot aantal externe organisaties, kunt u overwegen gebeurtenisdomeinen te gebruiken, zodat een toepassing gebeurtenissen naar duizenden onderwerpen kan publiceren, zoals één voor elke tenant. Zie Gebeurtenisdomeinen begrijpen voor het beheren van Event Grid-onderwerpen voor meer informatie.

Complexiteit van de implementatie

Bij het ontwerpen van een multitenant-oplossing is het essentieel om na te denken over de ontwikkeling van het systeem op de middellange tot lange termijn, om te voorkomen dat de complexiteit ervan in de loop van de tijd groeit, totdat het nodig is om een deel van of de hele oplossing opnieuw te ontwerpen. Dit nieuwe ontwerp helpt u om te gaan met een toenemend aantal tenants. Bij het ontwerpen van een berichtensysteem moet u rekening houden met de verwachte groei van berichtvolumes en tenants, in de komende jaren, en vervolgens een systeem maken dat kan worden uitgeschaald om het voorspelde verkeer bij te houden en de complexiteit van bewerkingen, zoals inrichting, bewaking en onderhoud, te verminderen.

De oplossing moet automatisch de benodigde berichtenentiteiten maken of verwijderen wanneer een tenanttoepassing is ingericht of niet wordt ingericht, zonder dat handmatige bewerkingen nodig zijn.

Een specifieke zorg voor multitenant-gegevensoplossingen is het aanpassingsniveau dat u ondersteunt. Elke aanpassing moet automatisch worden geconfigureerd en toegepast door het inrichtingssysteem van de toepassing (zoals een DevOps-systeem), dat is gebaseerd op een set initiële parameters, wanneer een toepassing met één tenant of meerdere tenants wordt geïmplementeerd.

Complexiteit van beheer en bewerkingen

Plan vanaf het begin hoe u uw infrastructuur voor berichten en gebeurtenissen wilt gebruiken, bewaken en onderhouden en hoe uw multitenancybenadering van invloed is op uw bewerkingen en processen. Denk bijvoorbeeld aan de volgende mogelijkheden:

  • Mogelijk wilt u het berichtensysteem hosten dat door uw toepassing wordt gebruikt in een toegewezen set virtuele machines, één voor elke tenant. Hoe wilt u deze systemen implementeren, upgraden, bewaken en uitschalen?
  • En als u uw berichtensysteem in een gedeeld Kubernetes-cluster containeriseert en host, hoe wilt u afzonderlijke berichtensystemen implementeren, upgraden, bewaken en uitschalen?
  • Stel dat u een berichtensysteem deelt over meerdere tenants. Hoe kan uw oplossing de metrische gegevens voor gebruik per tenant verzamelen en rapporteren of het aantal berichten beperken dat elke tenant kan verzenden of ontvangen?
  • Wanneer uw berichtensysteem gebruikmaakt van een PaaS-service, zoals Azure Service Bus, moet u de volgende vraag stellen:
    • Hoe kunt u de prijscategorie voor elke tenant aanpassen op basis van de functies en het isolatieniveau (gedeeld of toegewezen) die door de tenant worden aangevraagd?
    • Hoe kunt u een identiteit per tenant en azure-roltoewijzing maken om alleen de juiste machtigingen toe te wijzen aan de berichtenentiteiten, zoals wachtrijen, onderwerpen en abonnementen, waartoe de tenant toegang heeft? Zie Een beheerde identiteit verifiëren met Microsoft Entra ID voor toegang tot Azure Service Bus-resources voor meer informatie.
  • Hoe migreert u tenants als ze moeten overstappen op een ander type berichtenservice, een andere implementatie of een andere regio?

Kosten

Over het algemeen, hoe hoger de dichtheid van tenants voor uw implementatie-infrastructuur, hoe lager de kosten voor het inrichten van die infrastructuur. Gedeelde infrastructuur verhoogt echter de kans op problemen, zoals het probleem met lawaaierige buren, dus overweeg de afwegingen zorgvuldig.

Benaderingen en patronen om rekening mee te houden

Verschillende cloudontwerppatronen van het Azure Architecture Center kunnen worden toegepast op een berichtensysteem met meerdere tenants. U kunt ervoor kiezen om een of meer patronen consistent te volgen, of u kunt overwegen patronen te combineren en te vergelijken, op basis van uw behoeften. U kunt bijvoorbeeld een Service Bus-naamruimte met meerdere tenants gebruiken voor de meeste tenants, maar vervolgens kunt u een toegewezen Service Bus-naamruimte met één tenant implementeren voor tenants die meer of hogere vereisten betalen, wat betreft isolatie en prestaties. Op dezelfde manier is het vaak een goede gewoonte om te schalen met behulp van implementatiestempels, zelfs wanneer u een multitenant Service Bus-naamruimte of toegewezen naamruimten binnen een stempel gebruikt.

Patroon Implementatiestempels

Zie het patroon Implementatiestempels voor multitenancy voor meer informatie over het patroon Implementatiestempels voor multitenancy. Zie Tenancy-modellen die u kunt overwegen voor een multitenant-oplossing voor meer informatie over tenancymodellen.

Gedeeld berichtensysteem

U kunt overwegen om een gedeeld berichtensysteem te implementeren, zoals Azure Service Bus, en het te delen in al uw tenants.

Diagram met één gedeeld berichtensysteem met meerdere tenants voor alle tenants.

Deze benadering biedt de hoogste dichtheid van tenants voor de infrastructuur, waardoor de totale totale eigendomskosten worden verminderd. Het vermindert ook vaak de beheeroverhead, omdat er één berichtensysteem of resource is om te beheren en te beveiligen.

Wanneer u echter een resource of een volledige infrastructuur deelt tussen meerdere tenants, moet u rekening houden met de volgende opmerkingen:

  • Houd er altijd rekening mee en houd rekening met de beperkingen, schaalmogelijkheden, quota en limieten van de betreffende resource. Het maximum aantal Service Bus-naamruimten in een Azure-abonnement, het maximum aantal Event Hubs in één naamruimte of de maximale doorvoerlimieten kan uiteindelijk een harde blokkering worden, als en wanneer uw architectuur groeit om meer tenants te ondersteunen. Houd zorgvuldig rekening met de maximale schaal die u moet bereiken in termen van het aantal naamruimten per azure-abonnement of wachtrijen per enkele naamruimte. Vergelijk vervolgens uw huidige en toekomstige schattingen met de bestaande quota en limieten van het berichtensysteem van keuze voordat u dit patroon selecteert.
  • Zoals vermeld in de bovenstaande secties, kan het probleem met ruis buurman een factor worden wanneer u een resource deelt over meerdere tenants, met name als sommige bijzonder bezet zijn of als ze meer verkeer genereren dan andere. In dit geval kunt u overwegen het beperkingspatroon of het frequentiebeperkingspatroon toe te passen om deze effecten te beperken. U kunt bijvoorbeeld het maximum aantal berichten beperken dat één tenant in de tijdseenheid kan verzenden of ontvangen.
  • U kunt problemen ondervinden bij het bewaken van de activiteit en het meten van het resourceverbruik voor één tenant. Voor sommige services, zoals Azure Service Bus, worden kosten in rekening gebracht voor berichtenbewerkingen. Wanneer u daarom een naamruimte deelt tussen meerdere tenants, moet uw toepassing het aantal berichtenbewerkingen kunnen bijhouden dat namens elke tenant wordt uitgevoerd en de kosten voor terugstorting ervan. Andere services bieden niet hetzelfde detailniveau.

Tenants kunnen verschillende vereisten hebben voor beveiliging, tolerantie binnen regio's, herstel na noodgevallen of locatie. Als deze niet overeenkomen met de configuratie van uw berichtensysteem, is het mogelijk dat u deze niet kunt gebruiken met één resource.

Patroon Sharding

Het Sharding-patroon omvat het implementeren van meerdere berichtensystemen, zogenaamde shards, die een of meer berichtenentiteiten van tenants bevatten, zoals wachtrijen en onderwerpen. In tegenstelling tot implementatiestempels impliceren shards niet dat de volledige infrastructuur wordt gedupliceerd. U kunt shardberichtensystemen gebruiken zonder ook andere infrastructuur in uw oplossing te dupliceren of te sharden.

Diagram met een shard-berichtensysteem. Het ene berichtensysteem bevat de wachtrijen voor tenants A en B en het andere bevat de wachtrijen voor tenant C.

Elk berichtensysteem of shard kan verschillende kenmerken hebben in termen van betrouwbaarheid, SKU en locatie. U kunt bijvoorbeeld uw tenants sharden in meerdere berichtensystemen met verschillende kenmerken, op basis van hun locatie of behoeften in termen van prestaties, betrouwbaarheid, gegevensbescherming of bedrijfscontinuïteit.

Wanneer u het sharding-patroon gebruikt, moet u een shardingstrategie gebruiken om een bepaalde tenant toe te wijzen aan het berichtensysteem dat de wachtrijen bevat. De opzoekstrategie maakt gebruik van een kaart om het doelberichtensysteem te individueren op basis van de tenantnaam of -id. Meerdere tenants kunnen dezelfde shard delen, maar de berichtenentiteiten die door één tenant worden gebruikt, worden niet verspreid over meerdere shards. De kaart kan worden geïmplementeerd met één woordenlijst die de naam van de tenant toewijst aan de naam of verwijzing van het doelberichtensysteem. De kaart kan worden opgeslagen in een gedistribueerde cache die toegankelijk is, door alle exemplaren van een multitenant-toepassing of in een permanente opslag, zoals een tabel in een relationele database of een tabel in een opslagaccount.

Het Sharding-patroon kan worden geschaald naar zeer grote aantallen tenants. Afhankelijk van uw workload kunt u bovendien een hoge dichtheid van tenants tot shards bereiken, zodat de kosten aantrekkelijk kunnen zijn. Het Sharding-patroon kan ook worden gebruikt voor het aanpakken van Azure-abonnements- en servicequota, limieten en beperkingen.

Multitenant-app met toegewezen berichtensysteem voor elke tenant

Een andere veelvoorkomende aanpak is het implementeren van één multitenant-toepassing, met toegewezen berichtensystemen voor elke tenant. In dit tenancymodel hebt u een aantal gedeelde onderdelen, zoals rekenresources, terwijl andere services worden ingericht en beheerd met behulp van een specifieke implementatiebenadering met één tenant. U kunt bijvoorbeeld één toepassingslaag bouwen en vervolgens afzonderlijke berichtensystemen implementeren voor elke tenant, zoals wordt weergegeven in de volgende afbeelding.

Diagram met verschillende berichtensystemen voor elke tenant.

Horizontaal gepartitioneerde implementaties kunnen u helpen bij het beperken van een probleem met ruis, als u hebt vastgesteld dat de meeste belasting op uw systeem wordt veroorzaakt door specifieke onderdelen die u afzonderlijk voor elke tenant kunt implementeren. Mogelijk moet u voor elke tenant een afzonderlijk berichten- of gebeurtenisstreamingsysteem gebruiken, omdat één exemplaar niet voldoende is om het verkeer bij te houden dat door meerdere tenants wordt gegenereerd. Wanneer u voor elke tenant een speciaal berichtensysteem gebruikt, kan dit van invloed zijn op de gedeelde onderdelen, maar niet op berichtensystemen van andere tenants als één tenant een grote hoeveelheid berichten of gebeurtenissen veroorzaakt.

Omdat u toegewezen resources voor elke tenant inricht, kunnen de kosten voor deze benadering hoger zijn dan een gedeeld hostingmodel. Aan de andere kant is het eenvoudiger om resourcekosten van een toegewezen systeem terug te brengen naar de unieke tenant die er gebruik van maakt, bij het aannemen van dit tenancymodel. Met deze aanpak kunt u hoge dichtheid bereiken voor andere services, zoals rekenresources, en worden de kosten van deze onderdelen verlaagd.

Met een horizontaal gepartitioneerde implementatie moet u een geautomatiseerd proces gebruiken voor het implementeren en beheren van de services van een multitenant-toepassing, met name de services die door één tenant worden gebruikt.

Geodes-patroon

Het geode-patroon omvat het implementeren van een verzameling back-endservices in een set geografische knooppunten. Elke service kan elke aanvraag voor elke client in elke regio verwerken. Met dit patroon kunt u aanvragen verwerken in een actief-actief-stijl, waardoor de latentie wordt verbeterd en de beschikbaarheid wordt verhoogd, door de verwerking van aanvragen over de hele wereld te distribueren.

Diagram met het Geode-patroon, waarbij berichtensystemen zijn geïmplementeerd in meerdere regio's die met elkaar worden gesynchroniseerd.

Azure Service Bus en Azure Event Hubs ondersteunen herstel na noodgevallen van metagegevens, in primaire en secundaire naamruimten voor herstel na noodgevallen en in afzonderlijke regio's en beschikbaarheidszones, om ondersteuning te bieden voor de beste tolerantie binnen regio's. Azure Service Bus en Azure Event Hubs implementeren ook een set federatiepatronen die hetzelfde logische onderwerp, dezelfde wachtrij of Event Hub actief repliceren om beschikbaar te zijn in meerdere naamruimten, uiteindelijk in verschillende regio's. Voor meer informatie raadpleegt u de volgende bronnen:

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

Andere Inzenders:

Volgende stappen

Zie de volgende bronnen voor meer informatie over ontwerppatronen voor berichten: