Arkitekturmetoder för distribution och konfiguration av lösningar för flera klientorganisationer

Oavsett arkitektur och de komponenter som du använder för att implementera den måste du distribuera och konfigurera lösningens komponenter. I en miljö med flera klienter bör du överväga hur du distribuerar dina Azure-resurser, särskilt när du distribuerar dedikerade resurser för varje klientorganisation eller konfigurerar om resurser dynamiskt baserat på antalet klienter i systemet. Den här artikeln ger lösningsarkitekter vägledning om hur du distribuerar lösningar för flera klientorganisationer. Den visar metoder att tänka på när du planerar distributionsstrategin.

Viktiga överväganden och krav

Definiera dina krav tydligt innan du planerar distributionsstrategin. Överväg följande faktorer:

• Förväntad skala: Avgör om du förväntar dig att endast stödja ett fåtal klienter, till exempel fem eller färre, eller om du vill växa till ett stort antal klienter. I takt med att antalet klienter växer blir automatisering allt viktigare.

• Automatiserad registrering eller registrering som stöds: Ange om klientorganisationer ska slutföra registreringen via en automatiserad procedur eller initiera en begäran som kräver manuell registrering. Definiera eventuella manuella godkännandesteg från ditt team, till exempel för att förhindra missbruk av tjänsten.

• Etableringstid: Fastställa hur snabbt registreringsprocessen måste slutföras. Om du inte har ett tydligt svar definierar du om det här steget ska mätas i sekunder, minuter, timmar eller dagar.

• Azure Marketplace: Bekräfta om du planerar att använda Azure Marketplace för att initiera distributionen. Om du gör det uppfyller du de krav som krävs för att lägga till nya klienter.

Överväg även att registrera och etablera steg, automatisering och ansvar för resurshantering.

Registrerings- och etableringssteg

Definiera och dokumentera varje uppgift som krävs för att registrera en klientorganisation, även om processen är manuell. Arbetsflödet för registrering innehåller vanligtvis följande steg:

1. Acceptera kommersiella avtal.
2. Slutför manuella godkännandesteg, till exempel för att förhindra bedrägeri eller missbruk av din tjänst.
3. Etablera resurser i Azure.
4. Skapa eller konfigurera domännamn.
5. Utför konfigurationsuppgifter efter distributionen, till exempel att skapa det första användarkontot för klientorganisationen och på ett säkert sätt överföra autentiseringsuppgifterna till klientorganisationen.
6. Tillämpa manuella konfigurationsändringar, till exempel DNS-poständringar (Domain Name System).

Dokumentera tydligt arbetsflödet som krävs för att registrera en ny klientorganisation.

Överväg de specifika Azure-resurser som du behöver etablera för en klientorganisation. Även om du inte etablerar dedikerade resurser för varje klientorganisation kan du överväga om du ibland behöver distribuera resurser när en ny klientorganisation registreras. Det här scenariot kan inträffa när en klientorganisation kräver datalagring i en viss region. Det kan också inträffa när du använder en metod för lagerplatsförpackning. När du närmar dig gränserna för en stämpel eller komponent i din lösning i lagerplatsförpackningen skapar du en annan instans för nästa batch med klienter.

Överväg om registreringsprocessen kan störa andra klienter, särskilt klienter som delar samma infrastruktur. Om du till exempel behöver ändra delade databaser kan du avgöra om den här processen kan orsaka en prestandapåverkan som andra klienter kan märka. Överväg om du kan undvika dessa effekter eller minimera dem genom att utföra registreringsprocessen utanför normal driftstid.

Automatisering

Du bör använda automatiserade distributioner för molnbaserade lösningar. I lösningar med flera klientorganisationer blir automatisering ännu viktigare av följande skäl:

• Skala: I takt med att klientorganisationens befolkning ökar blir processerna för manuell distribution alltmer komplexa och tidskrävande. En automatiserad distributionsmetod är enklare att skala när antalet klienter växer.

• Repeterbar: I en miljö med flera klienter använder du en konsekvent process för distributioner i alla klienter. Manuella processer medför risk för fel eller inkonsekventa steg mellan klienter. Din miljö kan sedan lämnas i ett inkonsekvent tillstånd, vilket gör det svårare för ditt team att hantera lösningen.

• Påverkan av avbrott: Manuella distributioner är mer riskfyllda och kan drabbas av avbrott än automatiserade distributioner. I en miljö med flera klienter kan ett distributionsfel orsaka ett systemomfattande avbrott som påverkar varje klientorganisation, vilket ökar den totala effekten.

När du distribuerar till en miljö med flera klientorganisationer följer du dessa metoder:

• Använd distributionspipelines för att distribuera vanliga resurser.

• Använd infrastruktur som kodtekniker (IaC), till exempel Bicep, JSON Azure Resource Manager-mallar (ARM-mallar) eller Terraform.

• Använd kod för att anropa Azure SDK:er om det är lämpligt.

Om du planerar att erbjuda din lösning via Azure Marketplace bör du tillhandahålla en helt automatiserad registreringsprocess för nya klienter.

Maximal resurskapacitet

När du programmatiskt distribuerar klientresurser till delade resurser bör du överväga kapacitetsgränsen för varje resurs. När du närmar dig den gränsen kan du behöva skapa en annan instans av resursen för att stödja ytterligare skalning. Överväg gränserna för varje resurs som du distribuerar och de villkor som utlöser dig för att distribuera en annan instans.

Anta till exempel att din lösning innehåller en logisk Azure SQL-server och etablerar en dedikerad databas på servern för varje klientorganisation. En enskild logisk server har gränser, som innehåller ett maximalt antal databaser som den stöder. När du närmar dig dessa gränser kan du behöva etablera nya servrar så att du kan fortsätta att registrera klienter. Överväg om du vill automatisera den här processen eller övervaka tillväxten manuellt.

Ansvar för resurshantering

I vissa lösningar för flera klientorganisationer distribuerar du resurser med hjälp av en av flera modeller. Distribuera dedikerade Azure-resurser för varje klientorganisation, till exempel en databas för varje klientorganisation. Eller så kan du definiera ett visst antal klienter som ska inhysas på en enda instans av en resurs, så antalet klienter som du har dikterar den uppsättning resurser som du distribuerar till Azure. I andra lösningar distribuerar du en enda uppsättning delade resurser och konfigurerar om dem när du registrerar nya klienter.

Var och en av dessa modeller kräver att du distribuerar och hanterar resurser på olika sätt, och du måste överväga hur du distribuerar och hanterar livscykeln för de resurser som du etablerar. Överväg två vanliga metoder:

• Behandla klienter som konfiguration av distribuerade resurser och använd dina distributionspipelines för att distribuera och konfigurera dessa resurser.

• Behandla klienter som data och ha en kontrollplansetablering och konfigurera infrastrukturen för dina klienter.

I följande avsnitt beskrivs dessa metoder ytterligare.

Testa

Testa lösningen noggrant under och efter varje distribution. Du kan använda automatiserad testning för att verifiera lösningens funktionella och icke-funktionella beteende. Kontrollera att du testar din klientisoleringsmodell. Överväg att använda verktyg som Azure Chaos Studio för att avsiktligt införa fel som simulerar verkliga avbrott och kontrollera att lösningen fungerar även när en komponent blir otillgänglig eller fungerar dåligt.

Metoder och mönster att tänka på

Flera designmönster från Azure Architecture Center och den bredare communityn stöder distribution och konfiguration av lösningar för flera klientorganisationer.

Mönster för distributionsstämplar

Använd mönstret Distributionsstämplar för att distribuera dedikerad infrastruktur för en klientorganisation eller grupp med klienter. En enskild stämpel kan innehålla flera klienter, eller så kan den vara dedikerad till en enda klientorganisation. Du kan distribuera en enskild stämpel eller samordna en distribution över flera stämplar. Om du distribuerar dedikerade stämplar för varje klientorganisation bör du överväga att distribuera hela stämplar programmatiskt.

Utrullningsringar

Använd distributionsringar för att distribuera uppdateringar till olika grupper av infrastruktur vid olika tidpunkter. Den här metoden kompletterar ofta mönstret Distributionsstämplar. Tilldela grupper av stämplar till distinkta ringar baserat på klientinställningar, arbetsbelastningstyper och andra överväganden. Mer information finns i Distributionsringar.

Funktionsflaggor (Feature flags)

Använd funktionsflaggor för att progressivt exponera nya funktioner eller versioner av din lösning för olika klienter eller användare utan att distribuera om kod. Överväg att använda Azure App Configuration för att hantera dina funktionsflaggor. Mer information finns i Funktionsflaggor.

Ibland måste du selektivt aktivera specifika funktioner för specifika kunder. Du kan till exempel ha olika prisnivåer som tillåter åtkomst till vissa funktioner. Funktionsflaggor är vanligtvis inte rätt val för dessa scenarier. Överväg i stället att skapa en process för att spåra och framtvinga de licensrättigheter som varje kund har.

Antimönster att undvika

När du distribuerar och konfigurerar lösningar för flera klientorganisationer bör du undvika situationer som hämmar din förmåga att skala. Följande exempel belyser vanliga antimönster:

• Manuell distribution och testning: Manuella distributionsprocesser ökar risken och gör det långsamt att distribuera. Överväg att använda pipelines för automatiserade distributioner, programmatiskt skapa resurser från lösningens kod eller en kombination av båda.

• Specialiserade anpassningar för klientorganisationer: Undvik att distribuera funktioner eller en konfiguration som bara gäller för en enda klientorganisation. Den här metoden ökar komplexiteten i dina distributioner och testningsprocesser. Använd i stället samma resurstyper och kodbas för varje klientorganisation. Använd strategier som funktionsflaggor för tillfälliga ändringar eller för funktioner som distribueras progressivt. Eller använd olika prisnivåer med licensrättigheter för att selektivt aktivera funktioner för klienter som kräver dem. Använd en konsekvent och automatiserad distributionsprocess, även för klienter som har isolerade eller dedikerade resurser.

Klientlistor som konfiguration eller data

Tänk på följande när du distribuerar resurser i en lösning med flera klientorganisationer:

• Använd en automatiserad distributionspipeline för att distribuera varje resurs. När nya klienter läggs till konfigurerar du om pipelinen för att etablera resurserna för varje klientorganisation.

• Använd en automatiserad distributionspipeline för att distribuera delade resurser som inte är beroende av antalet klienter. Skapa klientspecifika resurser i ditt program.

När du tänker på de två metoderna kan du skilja mellan att behandla din klientlista som en konfiguration eller som data. Den här skillnaden påverkar också hur du skapar ett kontrollplan för systemet.

Klientorganisationslista som konfiguration

När du behandlar klientlistan som konfiguration distribuerar du alla resurser från en central distributionspipeline. När nya klienter registreras konfigurerar du om pipelinen eller dess parametrar. Normalt sker omkonfigurationen genom manuella ändringar, som du ser i följande diagram.

Registreringsprocessen för en ny klientorganisation innehåller vanligtvis följande steg:

1. Uppdatera klientlistan manuellt genom att konfigurera pipelinen eller ändra en parameterfil som ingår i pipelinens konfiguration.

2. Utlös pipelinen som ska köras.

3. Pipelinen distribuerar om din fullständiga uppsättning Azure-resurser, inklusive eventuella nya klientspecifika resurser.

Den här metoden fungerar bra för ett litet antal klienter och arkitekturer där alla resurser delas. En enda process distribuerar och konfigurerar alla dina Azure-resurser, vilket förenklar den övergripande metoden.

Men när antalet klienter ökar, ofta runt 10 eller fler, blir det besvärligt att konfigurera om pipelinen när du lägger till klienter. Den tid det tar att köra distributionspipelinen ökar ofta också. Den här metoden stöder inte heller enkelt skapande av självbetjäningsklienten, och ledtiden innan en klientorganisation registreras kan vara längre eftersom du måste utlösa pipelinen för att köras.

Klientorganisationslista som data

När du behandlar din klientlista som data distribuerar du fortfarande dina delade komponenter med hjälp av en pipeline. Men för resurser och konfigurationsinställningar som måste distribueras för varje klientorganisation distribuerar eller konfigurerar du dina resurser absolut. Kontrollplanet kan till exempel använda Azure SDK:er för att skapa en specifik resurs eller initiera distributionen av en parametriserad mall.

Registreringsprocessen innehåller vanligtvis följande asynkrona steg:

1. Begäran om att registrera en klientorganisation, till exempel att initiera en API-begäran till systemets kontrollplan.

2. En arbetsflödeskomponent tar emot begäran om att skapa och samordnar de återstående stegen.

3. Arbetsflödet initierar distributionen av klientspecifika resurser till Azure. Du kan använda en imperativ programmeringsmodell, till exempel Azure SDK:er, eller imperativt utlösa distributionen av en Bicep-fil eller Terraform-mall.

4. När distributionen är klar sparar arbetsflödet den nya klientorganisationens information i den centrala klientkatalogen. De data som lagras för varje klientorganisation kan innehålla klientorganisations-ID:t och resurs-ID:t för alla klientspecifika resurser som arbetsflödet skapade.

Den här metoden möjliggör resursetablering för nya klienter utan att distribuera om hela lösningen. Etableringstiden är vanligtvis kortare eftersom endast klientspecifika resurser distribueras.

Den här metoden är dock ofta mycket mer tidskrävande att bygga. Din insats måste motiveras av antalet klienter eller de tidsramar för etablering som du behöver uppfylla.

Mer information finns i Överväganden för kontrollplan för flera klienter.

Exempel

Contoso kör en lösning med flera klientorganisationer för sina kunder. De har sex klientorganisationer och räknar med att växa till 300 klienter inom de närmaste 18 månaderna. Contoso följer appen för flera klienter med dedikerade databaser för varje klientmetod . De distribuerar en enda uppsättning Azure App Service-resurser och en logisk Azure SQL-server som alla klienter delar. De distribuerar också en dedikerad Azure SQL-databas för varje klientorganisation, enligt följande diagram. Contoso använder Bicep för att distribuera sina Azure-resurser.

Alternativ 1: Använd distributionspipelines för allt

Contoso kan distribuera alla sina resurser med hjälp av en distributionspipeline. Deras pipeline distribuerar en Bicep-fil som innehåller alla deras Azure-resurser, inklusive Azure SQL-databaserna för varje klientorganisation. En parameterfil definierar listan över klienter. Bicep-filen använder en resursloop för att distribuera en databas för var och en av de listade klienterna, enligt följande diagram.

Om Contoso följer den här modellen måste de utföra följande steg:

1. Uppdatera parameterfilen som en del av registreringen av en ny klientorganisation.

2. Kör pipelinen igen.

3. Spåra resursgränser manuellt, till exempel om de växer med oväntat hög hastighet och närmar sig det maximala antalet databaser som stöds på en enda logisk Azure SQL-server.

Alternativ 2: Använd en kombination av distributionspipelines och imperativ resursskapande

Contoso kan också separera ansvaret för Azure-distributionerna.

Contoso använder en Bicep-fil som definierar delade resurser som ska distribueras. De delade resurserna stöder alla klienter och innehåller en klientkatalogdatabas, även kallad en klientlistedatabas, enligt följande diagram.

Contoso-teamet skapar ett kontrollplan som innehåller ett API för registrering av klientorganisation. När säljteamet slutför försäljningen till en ny kund utlöser Microsoft Dynamics API:et för att påbörja registreringsprocessen. Contoso tillhandahåller också ett självbetjäningswebbgränssnitt som kunder använder för att utlösa samma API.

API:et startar asynkront ett arbetsflöde som registrerar sina nya klienter. Arbetsflödet initierar distributionen av en ny Azure SQL-databas, som kan använda någon av följande metoder:

• Använd Azure SDK för att initiera distributionen av en andra Bicep-fil som definierar Azure SQL-databasen.

• Använd Azure SDK för att skapa en Azure SQL-databas med hjälp av hanteringsbiblioteket.

När databasen har distribuerats lägger arbetsflödet till klientorganisationen i klientlistans databas, enligt följande diagram. Programnivån initierar pågående uppdateringar av databasschemat.

Bidragsgivare

Microsoft ansvarar för den här artikeln. Följande deltagare skrev den här artikeln.

Huvudförfattare:

• John Downs | Principal Software Engineer, Azure Patterns &Practices

Övriga medarbetare:

• Bohdan Cherchyk | Senior kundtekniker, FastTrack för Azure
• Arsen Vladimirskiy | Huvudkundtekniker, FastTrack för Azure

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Relaterade resurser

• Överväganden för att uppdatera en lösning med flera klienter.
• Arkitekturmetoder för lagring och data.
• Använd Azure Resource Manager i en lösning med flera klientorganisationer.