Den här exempelarkitekturen bygger på den grundläggande företagsintegreringsarkitekturen. Den utökar arkitekturen för att visa hur du integrerar företagets serverdelssystem genom att använda meddelandeköer och händelser för att frikoppla tjänster för bättre skalbarhet och tillförlitlighet. Se till att du är bekant med den designen och de komponenter som används i den grundläggande integreringsarkitekturen. Den innehåller grundläggande information om kärnkomponenterna i den här arkitekturen, som inte återges här.
Arkitektur
Serverdelssystemen som refereras i den här designen kan innehålla SaaS-system (programvara som en tjänst), Azure-tjänster och befintliga webbtjänster i företaget.
Ladda ned en Visio-fil med den här arkitekturen.
Arbetsflöde
Arkitekturen som visas här bygger på en enklare arkitektur som visas i Basic Enterprise-integrering. Den arkitekturen använder Logic Apps för att samordna arbetsflöden direkt med serverdelssystem och API Management för att skapa kataloger med API:er.
Den här versionen av arkitekturen lägger till två komponenter som gör systemet mer tillförlitligt och skalbart:
Azure Service Bus. Service Bus är en säker och tillförlitlig meddelandekö.
Azure Event Grid. Event Grid är en tjänst för händelseroutning. Den använder en händelsemodell för publicering/prenumeration (pub/sub).
Asynkron kommunikation med hjälp av en meddelandekö ger följande fördelar jämfört med att göra direkta, synkrona anrop till serverdelstjänster:
- Tillhandahåller belastningsutjämning för att hantera bursts i arbetsbelastningar med hjälp av mönstret För köbaserad belastningsutjämning.
- Tillhandahåller sändning av meddelanden till flera konsumenter med hjälp av mönstret Publisher-Subscriber.
- Spårar på ett tillförlitligt sätt förloppet för långvariga arbetsflöden som omfattar flera steg eller flera program.
- Hjälper till att frikoppla program.
- Integrerar med befintliga meddelandebaserade system.
- Gör att arbete kan placeras i kö när ett serverdelssystem inte är tillgängligt.
Med Event Grid kan de olika komponenterna i systemet reagera på händelser när de inträffar, i stället för att förlita sig på avsökningar eller schemalagda aktiviteter. Precis som med en meddelandekö och ämnen hjälper det till att frikoppla program och tjänster. Ett program eller en tjänst kan publicera händelser och alla intresserade prenumeranter meddelas. Nya prenumeranter kan läggas till utan att avsändaren uppdateras.
Många Azure-tjänster stöder sändning av händelser till Event Grid. En logikapp kan till exempel lyssna efter en händelse när nya filer läggs till i ett bloblager. Det här mönstret möjliggör reaktiva arbetsflöden, där uppladdning av en fil eller att placera ett meddelande i en kö startar en serie processer. Processerna kan köras parallellt eller i en viss sekvens.
Rekommendationer
Rekommendationerna som beskrivs i Grundläggande företagsintegrering gäller för den här arkitekturen.
Service Bus
Service Bus har två leveranslägen, pull eller proxied push. I pull-modellen söker mottagaren kontinuerligt efter nya meddelanden. Avsökningen kan vara ineffektiv, särskilt om du har många köer som var och en tar emot några meddelanden, eller om det finns mycket tid mellan meddelanden. I den proxierade push-modellen skickar Service Bus en händelse via Event Grid när det finns nya meddelanden. Mottagaren prenumererar på händelsen. När händelsen utlöses hämtar mottagaren nästa batch med meddelanden från Service Bus.
När du skapar en logikapp för att använda Service Bus-meddelanden rekommenderar vi att du använder den proxierade push-modellen med Event Grid-integrering. Det är ofta mer kostnadseffektivt eftersom logikappen inte behöver avsöka Service Bus. Mer information finns i Översikt över Integrering av Azure Service Bus till Event Grid. För närvarande krävs Service Bus Premium-nivån för Event Grid-meddelanden.
Använd PeekLock för att komma åt en grupp med meddelanden. När du använder PeekLock kan logikappen utföra steg för att verifiera varje meddelande innan du slutför eller avger meddelandet. Den här metoden skyddar mot oavsiktlig meddelandeförlust.
Event Grid
När en Event Grid-utlösare utlöses innebär det att minst en händelse har inträffat. När en logikapp till exempel hämtar en Event Grid-utlösare för ett Service Bus-meddelande bör det förutsättas att flera meddelanden kan vara tillgängliga att bearbeta.
Att tänka på
Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.
Tillförlitlighet
Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i Översikt över tillförlitlighetspelare.
- Microsoft Entra ID: Microsoft Entra ID är en globalt distribuerad SaaS-plattform med hög tillgänglighet. Information om garanterad tillgänglighet finns i serviceavtalet .
- API Management: API Management kan distribueras i flera konfigurationer med hög tillgänglighet, enligt affärskrav och kostnadstolerans. En fullständig genomgång av alternativen finns i Se till att API Management är tillgängligt och tillförlitligt . Se även serviceavtalet för garanterad tillgänglighetsinformation.
- Logic Apps: Geo-redundant lagring är tillgängligt för Logic Apps på förbrukningsplannivån. Information om hur du utformar en lösning för affärskontinuitet och haveriberedskap finns i vägledningen. Se även serviceavtalet för garanterad tillgänglighetsinformation.
- Event Grid: Event Grid-resursdefinitioner för ämnen, systemämnen, domäner och händelseprenumerationer och händelsedata replikeras automatiskt mellan tre tillgänglighetszoner (när de är tillgängliga) i regionen. När det uppstår ett fel i någon av tillgänglighetszonerna redundansväxlar Event Grid-resurser automatiskt till en annan tillgänglighetszon utan mänsklig inblandning. Se Geo-haveriberedskap mellan regioner för vägledning om hur du utformar en haveriberedskapslösning för redundansväxling till en annan region. Se även serviceavtalet för garanterad tillgänglighetsinformation.
- Service Bus: Service Bus Premium har stöd för geo-haveriberedskap och tillgänglighetszoner. Replikering är tillgänglig för Service Bus Standard. Se även serviceavtalet för garanterad tillgänglighetsinformation.
Säkerhet
Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.
För att skydda Service Bus använder du Microsoft Entra-autentisering i kombination med hanterade identiteter. Microsoft Entra-integreringen för Service Bus-resurser innehåller Azures rollbaserade åtkomstkontroll (RBAC) för mer fullständig kontroll av en klients åtkomst till resurser. Du kan använda Azure RBAC för att bevilja behörigheter till ett säkerhetsobjekt, som kan vara en användare, en grupp eller ett huvudnamn för programtjänsten (en hanterad identitet i det här fallet).
Om Microsoft Entra-ID inte är tillgängligt kan du använda signatur för delad åtkomst (SAS). Du kan ge en användare åtkomst till Service Bus-resurser med specifika rättigheter med hjälp av SAS-autentisering.
Om du behöver exponera en Service Bus-kö eller ett ämne som en HTTP-slutpunkt, till exempel för att publicera nya meddelanden, använder du API Management för att skydda kön genom att fronta slutpunkten. Du kan sedan skydda slutpunkten med certifikat eller OAuth-autentisering efter behov. Det enklaste sättet att skydda en slutpunkt är att använda en logikapp med en HTTP-begäran/svarsutlösare som mellanhand.
Event Grid-tjänsten skyddar händelseleveransen via en valideringskod. Om du använder Logic Apps för att använda händelsen utförs verifieringen automatiskt. Mer information finns i Säkerhet och autentisering för Event Grid.
Nätverkssäkerhet
Nätverkssäkerhet bör beaktas under hela designen.
- Service Bus Premium kan bindas till en tjänstslutpunkt för virtuellt nätverk (VNet), vilket skyddar namnområdet för att endast acceptera trafik från auktoriserade virtuella nätverk. Använd dessutom privata slutpunkter för att låsa din VNet-trafik till privat trafik via Private Link.
- Logic Apps Standard och Premium Logic Apps kan konfigureras för att acceptera inkommande trafik via privata slutpunkter och för att skicka utgående trafik via VNet-integrering.
- API Management innehåller flera alternativ för att skydda åtkomsten till din API Management-instans och API:er med hjälp av ett virtuellt Azure-nätverk. Mer information om alternativen finns i dokumentationen Använd ett virtuellt nätverk med Azure API Management . Privata slutpunkter stöds också.
Kostnadsoptimering
Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.
Normalt beräknar du kostnader med hjälp av Azures priskalkylator. Här följer några andra överväganden.
API Management
Du debiteras för alla API Management-instanser när de körs. Om du har skalat upp och inte behöver den prestandanivån hela tiden skalar du ned eller konfigurerar autoskalning manuellt.
För lätta användningsarbetsbelastningar bör du överväga förbrukningsnivån, vilket är ett billigt, serverlöst alternativ. Förbrukningsnivån faktureras per API-anrop, medan de andra nivåerna faktureras per timme.
Logic Apps
Logic Apps använder en serverlös modell. Fakturering beräknas baserat på åtgärds- och anslutningskörning. Mer information finns i avsnittet med priser för Logic Apps.
Service Bus-köer, ämnen och prenumerationer
Service Bus-köer och -prenumerationer stöder både proxierade push- och pull-modeller för att leverera meddelanden. I pull-modellen mäts varje avsökningsbegäran som en åtgärd. Även med lång avsökning på 30 sekunder (standard) kan kostnaden vara hög. Om du inte behöver leverans av meddelanden i realtid bör du överväga att använda den proxierade push-modellen.
Service Bus-köer ingår i alla nivåer (basic-, standard- och premiumnivåer). Service Bus-ämnen och -prenumerationer är tillgängliga på standard- och premiumnivåer. Mer information finns i Priser för Azure Service Bus.
Event Grid
Event Grid använder en serverlös modell. Fakturering beräknas baserat på antalet åtgärder (händelsekörningar). Åtgärderna innefattar kommande händelser i domäner eller ämnen, avancerade matchningar, leveransförsök och hanteringsanrop. Användningen av upp till 100 000 åtgärder är kostnadsfri.
Mer information finns i Priser för Event Grid.
Mer information finns i kostnadsavsnittet i Microsoft Azures välstrukturerade ramverk.
Driftseffektivitet
Referensarkitekturen för Basic Enterprise-integrering ger vägledning om DevOps-mönster, som överensstämmer med det väldefinierade ramverkets operational excellence-pelare.
Att automatisera återställningsåtgärder så mycket som möjligt är en integrerad del av operational excellence. Med automatisering i åtanke kan du kombinera Azure Log Monitoring med Azure Automation för att automatisera redundansväxlingen av dina Service Bus-resurser. Se diagrammet i dokumentationen för redundansflöde för ett exempel på automatiseringslogik för att initiera en redundansväxling.
Prestandaeffektivitet
Prestandaeffektivitet handlar om att effektivt skala arbetsbelastningen baserat på användarnas behov. Mer information finns i Översikt över grundpelare för prestandaeffektivitet.
För att uppnå högre skalbarhet kan Service Bus Premium-nivån skala ut antalet meddelandeenheter. I dokumentationen för Service Bus Premium- och Standard-meddelandenivåer finns en genomgång av Premium-nivåförmånerna. Mer information om hur du konfigurerar automatisk skalning av meddelandeenheter finns i funktionsdokumentationen för automatisk skalning.
Fler rekommendationer för Service Bus finns i Metodtips för prestandaförbättringar med hjälp av Service Bus Messaging.
Nästa steg
Mer information finns i Service Bus-dokumentationen:
- Översikt över Integrering av Azure Service Bus till Event Grid
- Service Bus Premium- och Standard-meddelandenivåer
- Autoskalningsfunktion för Service Bus
- Metodtips för prestandaförbättringar med hjälp av Service Bus-meddelanden