Delen via

Multitenancy en Azure-app-configuratie

  • Artikel

Azure-app Configuration stelt u in staat om configuratie-instellingen voor uw toepassing op te slaan. Met behulp van Azure-app-configuratie kunt u eenvoudig het patroon Extern configuratiearchief implementeren. In dit artikel beschrijven we enkele van de functies van Azure-app Configuratie die nuttig zijn bij het werken met systemen met meerdere tenants, en we koppelen een koppeling naar richtlijnen en voorbeelden voor het gebruik van Azure-app Configuratie in een multitenant-oplossing.

Isolatiemodellen

Een archief verwijst naar één exemplaar van de Azure-app Configuration-service.

In een multitenant-oplossing is het gebruikelijk om twee typen instellingen te hebben:

  • Gedeelde instellingen zijn instellingen die van toepassing zijn op meerdere tenants, zoals globale instellingen of instellingen die van toepassing zijn op alle tenants binnen een implementatiestempel. Globale instellingen worden vaak het beste opgeslagen in een gedeeld App Configuration-archief. Door deze methode te volgen, minimaliseert u het aantal plaatsen dat u moet bijwerken wanneer de waarde van een instelling wordt gewijzigd. Deze aanpak minimaliseert ook het risico dat instellingen mogelijk niet meer worden gesynchroniseerd.

  • Tenantspecifieke instellingen, zoals de databasenaam of interne id's van elke tenant. U kunt ook verschillende logboekniveaus opgeven voor elke tenant, bijvoorbeeld wanneer u een probleem diagnosticeert dat door een specifieke tenant wordt gerapporteerd en u diagnostische logboeken van die ene tenant moet verzamelen. U kunt kiezen of u de tenantspecifieke instellingen voor meerdere tenants wilt combineren in één winkel of dat u een winkel voor elke tenant wilt implementeren. Deze beslissing moet zijn gebaseerd op uw vereisten. Als uw oplossing gebruikmaakt van één gedeelde toepassingslaag voor meerdere tenants, is er waarschijnlijk een minimaal voordeel bij het gebruik van tenantspecifieke winkels. Maar als u tenantspecifieke toepassingsexemplaren implementeert, kunt u ervoor kiezen om dezelfde benadering te spiegelen door tenantspecifieke configuratiearchieven te implementeren.

De volgende tabel bevat een overzicht van de verschillen tussen de belangrijkste tenancy-isolatiemodellen voor Azure-app Configuratie:

Overweging Gedeelde opslag Opslaan per tenant
Gegevensisolatie Laag. Sleutelvoorvoegsels of labels gebruiken om de gegevens van elke tenant te identificeren Hoog
Isolatie van prestaties Laag Hoog
Implementatiecomplexiteit Beperkt Gemiddeld hoog
Operationele complexiteit Beperkt Gemiddeld hoog
Resourcekosten Beperkt Gemiddeld hoog
Voorbeeldscenario Grote multitenant-oplossing met een gedeelde toepassingslaag Tenants van de Premium-laag met volledig geïsoleerde implementaties

Gedeelde winkels

U kunt een gedeeld Azure-app Configuratiearchief implementeren voor uw hele oplossing of één voor elke zegel. U kunt vervolgens hetzelfde archief gebruiken voor alle instellingen van uw tenants en u kunt belangrijke voorvoegsels of labels gebruiken om deze te onderscheiden.

Als u een grote hoeveelheid gegevens per tenant moet opslaan of als u naar een groot aantal tenants moet schalen, loopt u mogelijk het risico dat u een van de resourcelimieten voor één archief overschrijdt. In dit scenario kunt u overwegen of u uw tenants in een set gedeelde winkels kunt sharden om de implementatie- en beheerkosten te minimaliseren.

Als u deze aanpak volgt, moet u ervoor zorgen dat u de resourcequota en limieten begrijpt die van toepassing zijn. Houd met name rekening met de totale opslaglimiet voor de servicelaag die u gebruikt en zorg ervoor dat u de maximumaanvragen per uur niet overschrijdt.

Winkels per tenant

U kunt er in plaats daarvan voor kiezen om een Azure-app configuratiearchief voor elke tenant te implementeren. Met de Azure-app Standard-laag kunt u een onbeperkt aantal winkels in uw abonnement implementeren. Deze benadering is echter vaak complexer om te beheren, omdat u meer resources moet implementeren en configureren. Er worden ook kosten in rekening gebracht voor elke winkelresource die u implementeert.

Overweeg tenantspecifieke winkels als u een van de volgende situaties hebt:

  • U moet door de klant beheerde versleutelingssleutels gebruiken, waarbij de sleutels voor elke tenant gescheiden zijn.
  • Uw tenants vereisen dat hun configuratiegegevens volledig worden geïsoleerd van de gegevens van andere tenants. Toegangsmachtiging voor Azure-app Configuratie wordt beheerd op archiefniveau, dus door afzonderlijke winkels te implementeren, kunt u afzonderlijke toegangsmachtigingen configureren.

Functies van Azure-app-configuratie die ondersteuning bieden voor multitenancy

Wanneer u Azure-app Configuratie in een multitenant-toepassing gebruikt, zijn er verschillende functies die u kunt gebruiken om tenantspecifieke instellingen op te slaan en op te halen.

Sleutelvoorvoegsels

In Azure-app Configuratie werkt u met sleutel-waardeparen die toepassingsinstellingen vertegenwoordigen. De sleutel vertegenwoordigt de naam van de configuratie-instelling. U kunt een hiërarchische naamgevingsstructuur gebruiken voor uw sleutels. In een multitenant-oplossing kunt u een tenant-id gebruiken als voorvoegsel voor uw sleutels.

Stel dat u een instelling moet opslaan om het logboekregistratieniveau voor uw toepassing aan te geven. In een oplossing met één tenant kunt u deze instelling LogLeveleen naam opgeven. In een multitenant-oplossing kunt u ervoor kiezen om een hiërarchische sleutelnaam te gebruiken, zoals tenant1/LogLevel voor tenant 1, tenant2/LogLevel voor tenant 2, enzovoort.

Azure-app Configuratie kunt u lange sleutelnamen opgeven om meerdere niveaus in een hiërarchie te ondersteunen. Als u lange sleutelnamen wilt gebruiken, moet u ervoor zorgen dat u de groottelimieten voor sleutels en waarden begrijpt.

Wanneer u de configuratie van één tenant in uw toepassing laadt, kunt u een sleutelvoorvoegselfilter opgeven om alleen de sleutels van die tenant te laden. U kunt de providerbibliotheek ook configureren voor Azure-app Configuratie om het sleutelvoorvoegsel van de sleutels te knippen voordat deze beschikbaar worden gemaakt voor uw toepassing. Wanneer u het sleutelvoorvoegsel bijwerkt, ziet uw toepassing een consistente sleutelnaam, waarbij de waarden van die tenant in de toepassing worden geladen.

Etiketten

Azure-app Configuration ondersteunt ook labels, waarmee u afzonderlijke waarden met dezelfde sleutel kunt hebben.

Labels worden vaak gebruikt voor versiebeheer, werken met meerdere implementatieomgevingen of voor andere doeleinden in uw oplossing. Hoewel u tenant-id's als labels kunt gebruiken, kunt u geen labels voor iets anders gebruiken. Voor multitenant-oplossingen is het daarom meestal een goede gewoonte om belangrijke voorvoegsels te gebruiken voor het beheren van tenantspecifieke instellingen en labels te gebruiken voor andere doeleinden.

Als u besluit om labels voor elke tenant te gebruiken, kan uw toepassing alleen de instellingen voor een specifieke tenant laden met behulp van een labelfilter. Deze aanpak kan handig zijn als u afzonderlijke toepassingsimplementaties voor elke tenant hebt.

Caching aan de toepassingszijde

Wanneer u met Azure-app Configuratie werkt, is het belangrijk om de instellingen in uw toepassing in de cache op te slaan in plaats van ze telkens te laden wanneer u ze gebruikt. De Azure-app Configuratieproviderbibliotheken cache-instellingen en vernieuwen deze automatisch.

U moet ook bepalen of uw toepassing de instellingen voor één tenant of voor alle tenants laadt.

Naarmate uw tenantbasis groeit, neemt de hoeveelheid tijd en het geheugen dat nodig is voor het laden van instellingen voor alle tenants samen waarschijnlijk toe. In de meeste gevallen is het dus een goede gewoonte om de instellingen voor elke tenant afzonderlijk te laden wanneer uw toepassing deze nodig heeft.

Als u de configuratie-instellingen van elke tenant afzonderlijk laadt, moet uw toepassing elke set instellingen afzonderlijk in de cache opslaan voor andere tenants. In .NET-toepassingen kunt u overwegen een cache in het geheugen te gebruiken om het object van IConfiguration de tenant in de cache op te cachen en vervolgens de tenant-id te gebruiken als de cachesleutel. Als u een in-memory cache gebruikt, hoeft u bij elke aanvraag geen configuratie opnieuw te laden, maar kan de cache ongebruikte exemplaren verwijderen als uw toepassing onder geheugendruk staat. U kunt ook verlooptijden configureren voor de configuratie-instellingen van elke tenant.

Medewerkers

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

Hoofdauteur:

Andere Inzenders:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Bekijk de implementatie- en configuratiemethoden voor multitenancy.