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 klientorganisationer ä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 din distributionsstrategi.

Viktiga överväganden och krav

Det är viktigt att ha en tydlig uppfattning om dina krav innan du planerar distributionsstrategin. Här är några exempel på specifika överväganden:

• Förväntad skala: 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 registrering eller registrering som stöds: När en klientorganisation är redo att registreras, kommer de att kunna slutföra processen själva genom att följa en automatiserad procedur? Eller initierar nya klienter en begäran och du registrerar dem manuellt när du har fått begäran? Krävs manuella godkännandesteg från ditt team, till exempel för att förhindra missbruk av din tjänst?
• Etableringstid: Hur snabbt måste 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 registrerings- och etableringssteg, automatisering och ansvar för resurshantering.

Registrerings- och etableringssteg

Överväg 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. Onboarding-arbetsflödet 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 dess autentiseringsuppgifter 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.

Överväg även de specifika Azure-resurser som du behöver etablera för en klientorganisation. Även om du inte etablerar dedikerade resurser för varje klientorganisation bör 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.

Överväg om onboarding-processen sannolikt kommer att vara störande för 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 kan märka? Överväg om du kan undvika dessa effekter eller minimera dem genom att utföra onboarding-processen utanför normal driftstid.

Automation

Automatiserade distributioner är alltid tillrådligt 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 i takt med att klientorganisationens befolkning ökar. En automatiserad distributionsmetod är enklare att skala när antalet klienter växer.
• Repeterbara: I en miljö med flera klientorganisationer använder du en konsekvent process för distributioner över 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 klientorganisationer 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 för API:er för Uppfyllnad av SaaS.

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 att du distribuerar en annan instans.

Anta till exempel att din lösning innehåller en Azure SQL logisk server och att lösningen etablerar en dedikerad databas på den servern för varje klientorganisation. En enskild 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 klientorganisationer 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 finnas 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:

• 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 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. 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 infrastrukturgrupper 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 klientorganisationer, samtidigt som du har en enda kodbas. Överväg att använda Azure App Configuration för att hantera 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. Exempel på dessa är:

• Manuell distribution och testning. Enligt beskrivningen ovan ökar manuella distributionsprocesser risken och gör att du kan distribuera långsammare. Överväg att använda pipelines för automatiserade distributioner, programmässigt skapa resurser från din lösnings kod eller en kombination av båda.
• Specialiserade anpassningar för klienter. Undvik att distribuera funktioner eller en konfiguration som endast 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 för 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 pipeline för automatisk distribution 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 din klientorganisationslista som en konfiguration eller som data. Den här skillnaden är också viktig när du funderar 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 själva pipelinen konfigureras eller genom att en parameterfil som ingår i pipelinens konfiguration ändras.
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 brukar 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äningsklient, och tiden innan en klientorganisation registreras kan vara längre eftersom du måste utlösa din pipeline 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. Kontrollplanet kan till exempel använda Azure SDK:er för att skapa en specifik resurs eller initiera distributionen av en parametriserad mall.

Processen för att registrera en ny klientorganisation kan likna följande och skulle inträffa 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 med hjälp av 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 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 är förmodligen kortare, eftersom endast dessa resurser behöver distribueras.

Den här metoden är dock ofta mycket mer tidskrävande att skapa, och den ansträngning du lägger på måste motiveras av antalet klienter eller de etableringstider 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 för 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 kommande 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 Azure SQL logisk 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 databaser 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 är nära några gränser, till exempel om de växer i oväntat hög takt och närmar sig det maximala antalet databaser som stöds på en enda Azure SQL logisk 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 innehåller en klientmappningsdatabas, som du ser i 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 deras 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 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. Den skrevs ursprungligen av följande deltagare.

Huvudförfattare:

• John Downs | Huvudkundtekniker, FastTrack för Azure

Andra deltagare:

• Bohdan Cherchyk | Senior Customer Engineer, FastTrack for 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 hur du använder Azure Resource Manager i en lösning med flera klientorganisationer.