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 är det viktigt att tänka på hur du distribuerar dina Azure-resurser, särskilt när du distribuerar dedikerade resurser för varje klientorganisation eller när du konfigurerar om resurser baserat på antalet klienter i systemet. På den här sidan ger vi lösningsarkitekter vägledning om hur du distribuerar lösningar för flera klientorganisationer, och vi visar några metoder att tänka på när du planerar distributionsstrategin.

Viktiga överväganden och krav

Det är viktigt att ha en tydlig uppfattning om dina krav innan du planerar distributionsstrategin. Vissa överväganden omfattar följande:

• Förväntad skalning: Förväntar du dig att stödja ett litet antal klienter (till exempel fem eller mindre) eller kommer du att växa till ett stort antal klienter?
• Automatiserad eller stöds registrering: Kommer de att kunna slutföra processen själva genom att följa en automatiserad procedur när en klientorganisation är redo att registreras? Eller initierar nya klienter en begäran och du registrerar dem manuellt när du har fått begäran? Krävs det manuella godkännandesteg från ditt team, till exempel för att förhindra missbruk av tjänsten?
• Etableringstid: Hur snabbt behöver registreringsprocessen slutföras när en klientorganisation är redo att registreras? Om du inte har ett tydligt svar bör du överväga om detta ska mätas i sekunder, minuter, timmar eller dagar.
• Azure Marketplace: Planerar du att använda Azure Marketplace för att initiera distributionen? Om du gör det finns det krav som du måste uppfylla för att lägga till nya klienter.

Du bör också överväga att registrera och etablera steg, automatisering och ansvar för resurshantering.

Registrerings- och etableringssteg

Tänk på allt du behöver göra när du registrerar en klientorganisation och dokumentera den här listan och arbetsflödet, även om den utförs manuellt. Arbetsflödet för registrering innehåller vanligtvis följande:

• Godkännande av kommersiella avtal.
• Insamling av den information som du behöver för att konfigurera systemet för den nya klientorganisationen.
• Manuella godkännandesteg, till exempel för att förhindra bedrägeri eller missbruk av din tjänst.
• Etablering av resurser i Azure.
• Skapa eller konfigurera domännamn.
• 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.
• Manuella konfigurationsändringar, till exempel ändringar i DNS-poster.

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

Tänk också på 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. Detta kan inträffa när en klientorganisation kräver att deras data lagras i en viss region, eller när du närmar dig gränserna för en stämpel eller komponent i din lösning och behöver skapa en annan instans för nästa batch med klienter.

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

Automation

Automatiserade distributioner rekommenderas alltid för molnbaserade lösningar. När du arbetar med lösningar för flera klientorganisationer blir distributionsautomation ännu viktigare av följande skäl:

• Skala: Manuella distributionsprocesser blir allt mer komplexa och tidskrävande när klientorganisationens befolkning ökar. 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 steg som utförs för vissa klienter och inte andra. De här manuella processerna lämnar din miljö 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 betydligt mer riskfyllda och utsatta för avbrott än automatiserade distributioner. I en miljö med flera klienter kan effekten av ett systemomfattande avbrott (på grund av ett distributionsfel) vara hög, eftersom varje klientorganisation kan påverkas.

När du distribuerar till en miljö med flera klientorganisationer bör du använda distributionspipelines och använda IaC-tekniker (infrastruktur som kod), till exempel Bicep, JSON ARM-mallar, Terraform eller Azure SDK:er.

Om du planerar att erbjuda din lösning via Azure Marketplace bör du tillhandahålla en helt automatiserad registreringsprocess för nya klienter. Den här processen beskrivs i dokumentationen om Api:er för SaaS-uppfyllande.

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 att lösningen etablerar en dedikerad databas på servern för varje klientorganisation. En enda logisk server har gränser, som omfattar ett maximalt antal databaser som en logisk server 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 automatiserar den här processen eller övervakar tillväxten manuellt.

Ansvar för resurshantering

I vissa lösningar för flera klienter distribuerar du dedikerade Azure-resurser för varje klientorganisation, till exempel en databas för varje klientorganisation. Eller så kan du bestämma dig för 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 sedan om resurserna 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 ska distribuera och hantera livscykeln för de resurser som du etablerar. Två vanliga metoder är följande:

• För att behandla klienter som konfiguration av de resurser som du distribuerar och använda dina distributionspipelines för att distribuera och konfigurera dessa resurser.
• För att behandla klienter som data och ha en kontrollplansetablering och konfigurera infrastrukturen för dina klienter.

Mer information om dessa metoder finns nedan.

Testning

Planera att noggrant testa lösningen under och efter varje distribution. Du kan använda automatiserad testning för att verifiera lösningens funktionella och icke-funktionella beteende. Se till att du testar din modell för klientisolering och ö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 inte är tillgänglig eller inte fungerar.

Metoder och mönster att tänka på

Flera designmönster från Azure Architecture Center och communityn i stort är relevanta för distribution och konfiguration av lösningar för flera klientorganisationer.

Mönster för distributionsstämplar

Mönstret Distributionsstämplar omfattar distribution av 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 välja att distribuera en enskild stämpel, eller så kan du samordna en distribution över flera stämplar. Om du distribuerar dedikerade stämplar för varje klientorganisation kan du även distribuera hela stämplar programmatiskt.

Distributionsringar

Med distributionsringar kan du distribuera uppdateringar till olika grupper av infrastruktur vid olika tidpunkter. Den här metoden används ofta med mönstret Distributionsstämplar, och grupper av stämplar kan tilldelas till distinkta ringar baserat på klientinställningar, arbetsbelastningstyper och andra överväganden. Mer information finns i Distributionsringar.

Funktionsflaggor

Med funktionsflaggor kan du progressivt exponera nya funktioner eller versioner av din lösning för olika klienter, samtidigt som du har en enda kodbas. Överväg att använda Azure App Configuration för att hantera dina funktionsflaggor. Mer information finns i Funktionsflaggor.

Ibland behöver du selektivt aktivera specifika funktioner för vissa 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 är det viktigt att undvika situationer som hämmar din förmåga att skala. Dessa omfattar följande:

• Manuell distribution och testning. Enligt beskrivningen ovan ökar manuella distributionsprocesser risker och gör att du kan distribuera långsammare. Ö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 klienter. 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 och 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

Du kan överväga följande två metoder 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. För resurser som distribueras för varje klientorganisation skapar du dem i ditt program.

När du överväger de två metoderna bör du skilja mellan att behandla klientlistan som en konfiguration eller som data. Den här skillnaden är också viktig när du tänker på 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, vilket visas i följande diagram.

Processen för att registrera en ny klientorganisation kan likna följande:

1. Uppdatera klientlistan. Detta sker vanligtvis manuellt genom att konfigurera själva pipelinen eller genom att ä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 tenderar att fungera bra för ett litet antal klienter och för arkitekturer där alla resurser delas. Det är en enkel metod eftersom alla dina Azure-resurser kan distribueras och konfigureras med hjälp av en enda process.

Men när du närmar dig ett större antal klienter, till exempel 5 till 10 eller mer, 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å avsevärt. 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 för att initiera distributionen av en parameteriserad mall.

Processen för att registrera en ny klientorganisation kan likna följande och skulle ske asynkront:

1. Begär att en klientorganisation registreras, till exempel genom 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. Detta kan uppnås genom att använda en imperativ programmeringsmodell, till exempel genom att använda Azure SDK:er, eller genom att absolut utlösa distributionen av en Bicep- 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.

Genom att göra detta kan du etablera resurser för nya klienter utan att distribuera om hela lösningen. Tiden för etablering av nya resurser för varje klientorganisation kommer sannolikt att bli kortare, eftersom endast dessa resurser behöver distribueras.

Den här metoden är dock ofta mycket mer tidskrävande att bygga, och den ansträngning du lägger på måste motiveras av antalet klienter eller de tidsramar för etablering som du behöver uppfylla.

Mer information om den här metoden 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. För närvarande har de sex klienter, och de förväntar sig att växa till 300 klienter inom de närmaste 18 månaderna. Contoso följer appen Multitenant med dedikerade databaser för varje klientmetod . De har distribuerat en enda uppsättning App Service-resurser och en logisk Azure SQL-server som delas mellan alla sina klienter, och de distribuerar 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ända distributionspipelines för allt

Contoso kan överväga att 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 och 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 uppdatera sin parameterfil som en del av registreringen av en ny klientorganisation. Sedan måste de köra sin pipeline igen. Dessutom måste de manuellt hålla reda på om de ligger nära några gränser, 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å överväga att separera ansvaret för Azure-distributionerna.

Contoso använder en Bicep-fil som definierar de delade resurser som ska distribueras. De delade resurserna stöder alla sina klienter och inkluderar en klientmappningsdatabas, enligt följande diagram.

Contoso-teamet skapar sedan ett kontrollplan som innehåller ett API för registrering av klientorganisation. När säljteamet har slutfört 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 kan använda och som även utlöser API:et.

API:et startar asynkront ett arbetsflöde som registrerar sina nya klienter. Arbetsflödet initierar distributionen av en ny Azure SQL-databas, vilket kan göras med 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 imperativt 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.

Pågående uppdateringar av databasscheman initieras av deras programnivå.

Deltagare

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

Huvudförfattare:

• John Downs | Huvudprogramtekniker

Övriga medarbetare:

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

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

• Granska övervägandena för att uppdatera en lösning med flera klienter.
• Överväg arkitekturmetoder för lagring och data.
• Överväg att använda Azure Resource Manager i en lösning med flera klientorganisationer.