Dela via

Arkitekturmetoder för klientintegrering och dataåtkomst

  • Artikel

Det är vanligt att system integreras tillsammans, även över organisationens gränser. När du skapar en lösning för flera klienter kan du ha krav på att skicka tillbaka data till klientorganisationens system eller att ta emot data från dessa system. I den här artikeln beskriver vi de viktigaste övervägandena och metoderna för att utforma och utveckla integreringar för en lösning med flera klienter.

Kommentar

Om du tillhandahåller flera integreringspunkter är det bäst att tänka på var och en oberoende av varandra. Ofta har olika integreringspunkter olika krav och är utformade på olika sätt, även om de ansluter samma system på flera olika sätt.

Viktiga överväganden och krav

Riktning för dataflöde

Det är viktigt att förstå i vilken riktning dina data flödar. Dataflödesriktningen påverkar flera aspekter av arkitekturen, till exempel hur du hanterar identiteter och lösningens nätverkstopologi. Det finns två vanliga dataflöden:

  • Exportera, vilket innebär att data flödar från multitenantsystemet till dina enskilda klientorganisationers system.
  • Importera, vilket innebär att data kommer från klientorganisationens system till multitenantsystemet.

Det är också viktigt att tänka på riktningen för nätverksdataflödet, vilket inte nödvändigtvis motsvarar riktningen för det logiska dataflödet. Du kan till exempel initiera en utgående anslutning till en klientorganisation så att du kan importera data från klientorganisationens system.

Fullständig eller användardelegering

I många system är åtkomsten till vissa data begränsad till specifika användare. Data som en användare kan komma åt kanske inte är samma som de data som en annan användare kan komma åt. Det är viktigt att tänka på om du förväntar dig att arbeta med fullständiga datauppsättningar eller om de datauppsättningar som du importerar eller exporterar baseras på vad en specifik användare har behörighet att komma åt.

Tänk dig till exempel Microsoft Power BI, som är en tjänst med flera klientorganisationer som tillhandahåller rapportering och business intelligence ovanpå kundägda datalager. När du konfigurerar Power BI konfigurerar du datakällor för att hämta data från databaser, API:er och andra datalager. Du kan konfigurera datalager på två olika sätt:

  • Importera alla data från det underliggande datalagret. Den här metoden kräver att Power BI har autentiseringsuppgifter för en identitet som kan komma åt hela datalagret. Sedan kan Power BI-administratörer separat konfigurera behörigheter för importerade data när de har importerats till Power BI. Power BI tillämpar behörigheterna.
  • Importera en delmängd data från det underliggande datalagret baserat på en användares behörigheter. När en användare skapar datakällan använder de sina autentiseringsuppgifter och tillhörande behörigheter. Den exakta delmängden av data som Power BI importerar beror på åtkomstnivån för den användare som skapade datakällan.

Båda metoderna har giltiga användningsfall, så det är viktigt att du tydligt förstår dina klientorganisationers krav.

Om du arbetar med fullständiga datauppsättningar behandlar källsystemet effektivt målsystemet som ett betrott undersystem. För den här typen av integrering bör du också överväga att använda en arbetsbelastningsidentitet i stället för en användaridentitet. En arbetsbelastningsidentitet är en systemidentitet som inte motsvarar en enskild användare. Arbetsbelastningsidentiteten beviljas hög behörighet till data i källsystemet.

Om du arbetar med användaromfattande data kan du också behöva använda en metod som delegering för att få åtkomst till rätt delmängd av data från datauppsättningen. Sedan får målsystemet i praktiken samma behörighet som en specifik användare. Mer information om användardelegering finns i metoden delegerad användaråtkomst nedan. Om du använder delegering bör du överväga hur du ska hantera scenarier där en användare avetableras eller deras behörigheter ändras.

Realtid eller batch

Överväg om du ska arbeta med realtidsdata eller om data skickas i batchar.

För realtidsintegreringar är dessa metoder vanliga:

  • Begäran/svar är där en klient initierar en begäran till en server och tar emot ett svar. Vanligtvis implementeras integreringar av begäran/svar med hjälp av API:er eller webhooks. Begäranden kan vara synkrona, där de väntar på bekräftelse och ett svar. Alternativt kan begäranden vara asynkrona, med något som liknar mönstret Asynkront begäran-svar för att vänta på ett svar.
  • Löst kopplad kommunikation aktiveras ofta via meddelandekomponenter som är utformade för löst kopplingssystem tillsammans. Azure Service Bus tillhandahåller till exempel funktioner för meddelandeköer och Azure Event Grid och Event Hubs tillhandahåller händelsefunktioner. Dessa komponenter används ofta som en del av integreringsarkitekturer.

Batchintegreringar hanteras däremot ofta via ett bakgrundsjobb, som kan utlösas vid vissa tidpunkter på dagen. Vanligtvis sker batchintegreringar via en mellanlagringsplats, till exempel en bloblagringscontainer, eftersom de datamängder som utbyts kan vara stora.

Datavolym

Det är viktigt att förstå mängden data som du utbyter via en integrering, eftersom den här informationen hjälper dig att planera för din övergripande systemkapacitet. När du planerar systemets kapacitet bör du komma ihåg att olika klientorganisationer kan ha olika datavolymer att utbyta.

För realtidsintegreringar kan du mäta volymen som antalet transaktioner under en angiven tidsperiod. För batchintegreringar kan du mäta volymen antingen som antalet poster som utbyts eller mängden data i byte.

Dataformat

När data utbyts mellan två parter är det viktigt att de båda har en tydlig förståelse för hur data formateras och struktureras. Överväg följande delar av dataformatet:

  • Filformatet, till exempel JSON, Parquet, CSV eller XML.
  • Schemat, till exempel listan över fält som ska inkluderas, datumformat och nullbarhet för fält.

När du arbetar med ett system med flera klienter är det om möjligt bäst att standardisera och använda samma dataformat för alla dina klienter. På så sätt undviker du att behöva anpassa och testa integreringskomponenterna på nytt för varje klientorganisations krav. I vissa situationer kan du dock behöva använda olika dataformat för kommunikation med olika klienter, och därför kan du behöva implementera flera integreringar. I avsnittet Composable integration components (Sammansättningsbara integreringskomponenter) finns en metod som kan hjälpa till att förenkla den här typen av situationer.

Åtkomst till klientorganisationens system

Vissa integreringar kräver att du ansluter till klientorganisationens system eller datalager. När du ansluter till klientorganisationens system måste du noga överväga både nätverks- och identitetskomponenterna i anslutningen.

Nätverksåtkomst

Överväg nätverkstopologin för åtkomst till klientorganisationens system, vilket kan innehålla följande alternativ:

  • Anslut över internet. Hur skyddas anslutningen om du ansluter över internet och hur krypteras data? Om dina klienter planerar att begränsa baserat på dina IP-adresser kontrollerar du att de Azure-tjänster som din lösning använder kan stödja statiska IP-adresser för utgående anslutningar. Överväg till exempel att använda NAT Gateway för att tillhandahålla statiska IP-adresser om det behövs. Om du behöver ett VPN bör du överväga hur du utbyter nycklar på ett säkert sätt med dina klienter.
  • Agenter, som distribueras till en klientorganisations miljö, kan tillhandahålla en flexibel metod och kan hjälpa dig att undvika behovet av att dina klienter tillåter inkommande anslutningar.
  • Reläer, till exempel Azure Relay, ger också en metod för att undvika inkommande anslutningar.

Mer information finns i vägledningen om nätverksmetoder för flera klientorganisationer.

Autentisering

Fundera på hur du autentiserar med varje klient när du initierar en anslutning. Överväg följande metoder:

  • Hemligheter, till exempel API-nycklar eller certifikat. Det är viktigt att planera hur du på ett säkert sätt ska hantera dina klientorganisationers autentiseringsuppgifter. Läckage av klientorganisationens hemligheter kan leda till en större säkerhetsincident som kan påverka många klienter.
  • Microsoft Entra-token, där du använder en token som utfärdats av klientorganisationens egen Microsoft Entra-katalog. Token kan utfärdas direkt till din arbetsbelastning med hjälp av en Microsoft Entra-programregistrering med flera klientorganisationer eller ett specifikt huvudnamn för tjänsten. Du kan också begära delegerad behörighet för att få åtkomst till resurser åt en viss användare i klientorganisationens katalog.

Oavsett vilken metod du väljer kontrollerar du att dina klienter följer principen om minsta behörighet och undviker att ge systemet onödiga behörigheter. Om ditt system till exempel bara behöver läsa data från en klientorganisations datalager bör den identitet som systemet använder inte ha skrivbehörighet.

Klientorganisationens åtkomst till dina system

Om klienter behöver ansluta till systemet kan du överväga att tillhandahålla dedikerade API:er eller andra integreringsplatser, som du sedan kan modellera som en del av ytan på din lösning.

I vissa situationer kan du välja att ge dina klienter direkt åtkomst till dina Azure-resurser. Överväg konsekvenserna noggrant och se till att du förstår hur du beviljar åtkomst till klienter på ett säkert sätt. Du kan till exempel använda någon av följande metoder:

  • Använd Valet Key-mönstret, som omfattar användning av säkerhetsåtgärder som signaturer för delad åtkomst för att bevilja begränsad åtkomst till vissa Azure-resurser.
  • Använd dedikerade resurser för integrationsplatser, till exempel ett dedikerat lagringskonto. Det är en bra idé att hålla integreringsresurser åtskilda från dina kärnsystemresurser. Den här metoden hjälper dig att minimera explosionsradien för en säkerhetsincident. Det säkerställer också att om en klientorganisation av misstag initierar ett stort antal anslutningar till resursen och uttömmer sin kapacitet fortsätter resten av systemet att köras.

Regelefterlevnad

När du börjar interagera direkt med klientorganisationens data eller överföra dessa data är det viktigt att du har en tydlig förståelse för dina klientorganisationers styrnings - och efterlevnadskrav.

Metoder och mönster att tänka på

Exponera API:er

Realtidsintegreringar innebär ofta att exponera API:er för dina klienter eller andra parter att använda. API:er kräver särskilda överväganden, särskilt när de används av externa parter. Överväg följande frågor:

  • Vem beviljas åtkomst till API:et?
  • Hur autentiserar du API:ets användare?
  • Finns det en gräns för antalet begäranden som en API-användare kan göra under en tidsperiod?
  • Hur ger du information om dina API:er och dokumentation för varje API? Behöver du till exempel implementera en utvecklarportal?

En bra idé är att använda en API-gateway, till exempel Azure API Management, för att hantera dessa problem och många andra. API-gatewayer ger dig en enda plats för att implementera principer som dina API:er följer, och de förenklar implementeringen av dina serverdels-API-system. Mer information om hur API Management stöder arkitektur med flera klientorganisationer finns i Använda Azure API Management i en lösning med flera klientorganisationer.

Valet-nyckelmönster

Ibland kan en klientorganisation behöva direkt åtkomst till en datakälla, till exempel Azure Storage. Överväg att följa Valet Key-mönstret för att dela data på ett säkert sätt och begränsa åtkomsten till datalagret.

Du kan till exempel använda den här metoden när batchexportering av en stor datafil. När du har genererat exportfilen kan du spara den i en blobcontainer i Azure Storage och sedan generera en tidsbunden, skrivskyddad signatur för delad åtkomst. Den här signaturen kan tillhandahållas till klientorganisationen, tillsammans med blob-URL:en. Klientorganisationen kan sedan ladda ned filen från Azure Storage tills signaturen har upphört att gälla.

På samma sätt kan du generera en signatur för delad åtkomst med behörighet att skriva till en specifik blob. När du anger en signatur för delad åtkomst till en klientorganisation kan de skriva sina data till bloben. Genom att använda Event Grid-integrering för Azure Storage kan ditt program sedan meddelas om att bearbeta och importera datafilen.

Webhook

Med webhooks kan du skicka händelser till dina klienter på en URL som de tillhandahåller till dig. När du har information att skicka initierar du en anslutning till klientorganisationens webhook och inkluderar dina data i HTTP-begärandenyttolasten.

Om du väljer att skapa ett eget webhook-händelsesystem kan du överväga att följa CloudEvents-standarden för att förenkla dina klientorganisationers integreringskrav.

Du kan också använda en tjänst som Azure Event Grid för att tillhandahålla webhook-funktioner. Event Grid fungerar internt med CloudEvents och stöder händelsedomäner, som är användbara för lösningar med flera klientorganisationer.

Kommentar

Kom ihåg att du ansluter till ett externt system när du upprättar utgående anslutningar till klientorganisationens system. Följ rekommenderade molnmetoder, inklusive att använda återförsöksmönstret, kretsbrytarmönstret och skottmönstret för att säkerställa att problem i klientorganisationens system inte sprids till systemet.

Delegerad användaråtkomst

När du kommer åt data från en klients datalager bör du överväga om du behöver använda en specifik användares identitet för att komma åt data. När du gör det omfattas integreringen av samma behörigheter som användaren har. Den här metoden kallas ofta för delegerad åtkomst.

Anta till exempel att multitenanttjänsten kör maskininlärningsmodeller över klientorganisationens data. Du måste komma åt varje klientorganisations instanser av tjänster, till exempel Azure Synapse Analytics, Azure Storage, Azure Cosmos DB och andra. Varje klientorganisation har en egen Microsoft Entra-katalog. Din lösning kan beviljas delegerad åtkomst till datalagret så att du kan hämta de data som en specifik användare kan komma åt.

Delegerad åtkomst är enklare om datalagret stöder Microsoft Entra-autentisering. Många Azure-tjänster stöder Microsoft Entra-identiteter.

Anta till exempel att dina webbprogram och bakgrundsprocesser för flera klienter måste komma åt Azure Storage med hjälp av klientorganisationens användaridentiteter från Microsoft Entra-ID. Du kan göra följande:

  1. Skapa en Microsoft Entra-programregistrering med flera klientorganisationer som representerar din lösning.
  2. Ge programmet delegerad behörighet att komma åt Azure Storage som den inloggade användaren.
  3. Konfigurera ditt program för att autentisera användare med hjälp av Microsoft Entra-ID.

När en användare har loggat in utfärdar Microsoft Entra-ID ett kortlivat åtkomsttoken för ditt program som kan användas för att få åtkomst till Azure Storage åt användaren och utfärdar en uppdateringstoken med längre livslängd. Systemet måste lagra uppdateringstoken på ett säkert sätt, så att dina bakgrundsprocesser kan hämta nya åtkomsttoken och kan fortsätta att komma åt Azure Storage åt användaren.

Meddelandetjänster

Meddelanden möjliggör asynkron, löst kopplad kommunikation mellan system eller komponenter. Meddelanden används ofta i integrationsscenarier för att frikoppla käll- och målsystemen. Mer information om meddelanden och flera klientorganisationer finns i Arkitekturmetoder för meddelanden i lösningar för flera klientorganisationer.

När du använder meddelanden som en del av en integrering med klientorganisationens system bör du överväga om du ska använda signaturer för delad åtkomst för Azure Service Bus eller Azure Event Hubs. Med signaturer för delad åtkomst kan du bevilja begränsad åtkomst till dina meddelanderesurser till tredje part, utan att ge dem åtkomst till resten av undersystemet för meddelanden.

I vissa scenarier kan du tillhandahålla olika serviceavtal (serviceavtal) eller tjänstkvalitetsgarantier (QoS) till olika klienter. En delmängd av dina klienter kan till exempel förvänta sig att deras dataexportbegäranden bearbetas snabbare än andra. Genom att använda mönstret Prioritetskö kan du skapa separata köer för olika prioritetsnivåer, med olika arbetsinstanser för att prioritera dem därefter.

Sammansättningsbara integreringskomponenter

Ibland kan du behöva integrera med många olika klienter, som var och en använder olika dataformat eller olika typer av nätverksanslutningar.

En vanlig metod för integrering är att skapa och testa enskilda steg som utför följande typer av åtgärder:

  • Hämta data från ett datalager.
  • Transformera data till ett visst format eller schema.
  • Överföra data med hjälp av en viss nätverkstransport eller till en känd måltyp.

Vanligtvis skapar du dessa enskilda element med hjälp av tjänster som Azure Functions och Azure Logic Apps. Sedan definierar du den övergripande integreringsprocessen med hjälp av ett verktyg som Logic Apps eller Azure Data Factory och anropar vart och ett av de fördefinierade stegen.

När du arbetar med komplexa integreringsscenarier för flera klientorganisationer kan det vara bra att definiera ett bibliotek med återanvändbara integreringssteg. Sedan kan du skapa arbetsflöden för varje klientorganisation för att skapa tillämpliga delar tillsammans, baserat på klientorganisationens krav. Alternativt kanske du kan exponera vissa datauppsättningar eller integreringskomponenter direkt för dina klienter, så att de kan skapa sina egna integreringsarbetsflöden från dem.

På samma sätt kan du behöva importera data från klienter som använder ett annat dataformat eller annan transport till andra. En bra metod för det här scenariot är att skapa klientspecifika anslutningsappar. Anslutningsappar är arbetsflöden som normaliserar och importerar data till ett standardiserat format och en plats, och sedan utlöser de din huvudsakliga delade importprocess.

Om du behöver skapa klientspecifik logik eller kod kan du överväga att följa mönstret Lager mot korruption. Mönstret hjälper dig att kapsla in klientspecifika komponenter, samtidigt som resten av lösningen inte känner till den extra komplexiteten.

Om du använder en nivåindelad prismodell kan du välja att kräva att klienter på en låg prisnivå följer en standardmetod med en begränsad uppsättning dataformat och transporter. Högre prisnivåer kan ge mer anpassning eller flexibilitet i de integreringskomponenter som du erbjuder.

Antimönster att undvika

  • Exponera dina primära datalager direkt för klientorganisationer. När klientorganisationer får åtkomst till dina primära datalager kan det bli svårare att skydda dessa datalager, och de kan oavsiktligt orsaka prestandaproblem som påverkar din lösning. Undvik att ange autentiseringsuppgifter för dina datalager till dina kunder och replikera inte direkt data från din primära databas till kundernas läsrepliker av samma databassystem. Skapa i stället dedikerade integrationsdatalager och använd mönstret Valet Key för att exponera data.
  • Exponera API:er utan en API-gateway. API:er har specifika problem med åtkomstkontroll, fakturering och mätning. Även om du inte planerar att använda API-principer från början är det en bra idé att ta med en API-gateway tidigt. Om du behöver anpassa dina API-principer i framtiden behöver du därför inte göra icke-bakåtkompatibla ändringar i url:erna som en tredje part är beroende av.
  • Onödig tät koppling. Lös koppling, till exempel genom att använda meddelandemetoder , kan ge en rad fördelar för säkerhet, prestandaisolering och återhämtning. När det är möjligt är det en bra idé att löst koppla ihop dina integreringar med tredje part. Om du behöver nära koppla till en tredje part kontrollerar du att du följer bra metoder som mönstret Försök igen, kretsbrytarmönstret och skottmönstret.
  • Anpassade integreringar för specifika klienter. Klientspecifika funktioner eller kod kan göra din lösning svårare att testa. Det gör det också svårare att ändra din lösning i framtiden, eftersom du måste förstå fler kodsökvägar. Försök i stället att skapa komposterbara komponenter som abstraherar kraven för en specifik klientorganisation och återanvänder dem över flera klienter med liknande krav.

Deltagare

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

Huvudsakliga författare:

Annan deltagare:

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

Nästa steg

Granska arkitekturmetoder för meddelanden i lösningar med flera klientorganisationer.