Den här exempelarkitekturen bygger på den grundläggande företagsintegreringsarkitekturen . Den utökar den 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 händelseroutningstjänst. Den använder en händelsemodell för publicering/prenumeration (pub/sub).
Asynkron kommunikation med 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 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 ett meddelande i en kö startar en serie processer. Processerna kan köras parallellt eller i en specifik 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 proxied 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 proxied push-modellen med Event Grid-integrering. Det är ofta mer kostnadseffektivt eftersom logikappen inte behöver avsöka Service Bus. Mer information finns i Azure Service Bus till Event Grid-integreringsöversikten. 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 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.
Överväganden
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 för dina kunder. Mer information finns i Översikt över grundpelare för tillförlitlighet.
- Azure AD: Azure AD ä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. Se se Se till att API Management tillgänglighet och tillförlitlighet för en fullständig genomgång av alternativen. Se även serviceavtalet för information om garanterad tillgänglighet.
- Logic Apps: Geo-redundant lagring är tillgängligt för Logic Apps på nivån Förbrukningsplan. Information om hur du utformar en lösning för affärskontinuitet och haveriberedskap finns i vägledningen. Se även serviceavtalet för information om garanterad tillgänglighet.
- 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. Om 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 information om garanterad tillgänglighet.
- Service Bus: Service Bus Premium stöder geo-haveriberedskap och Tillgänglighetszoner. Replikering är tillgänglig för Service Bus Standard. Se även serviceavtalet för information om garanterad tillgänglighet.
Säkerhet
Säkerhet ger garantier mot avsiktliga attacker och missbruk av värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.
Om du vill skydda Service Bus använder du Azure Active Directory-autentisering (Azure AD) i kombination med hanterade identiteter. Azure AD-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 programtjänsthuvudnamn (en hanterad identitet i det här fallet).
Om Azure AD 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 till exempel behöver exponera en Service Bus-kö eller ett ämne som en HTTP-slutpunkt 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 över 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. I dokumentationen om att använda ett virtuellt nätverk med Azure API Management finns en grundlig genomgång av alternativen. Privata slutpunkter stöds också.
Kostnadsoptimering
Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra driftseffektiviteten. Mer information finns i Översikt över grundpelare för kostnadsoptimering.
I allmänhet använder du Priskalkylatorn för Azure för att beräkna kostnader. 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, som är ett serverlöst alternativ till låg kostnad. 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 Prissättning 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 leverans av 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 (nivåerna Basic, Standard och Premium). Service Bus-ämnen och -prenumerationer är tillgängliga på standard- och premiumnivåer. Mer information finns i Azure Service Bus prissättning.
Event Grid
Event Grid använder en serverlös modell. Fakturering beräknas baserat på antalet åtgärder (händelsekörningar). Åtgärder omfattar ingress av händelser till 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 Well-Architected Frameworks grundpelare för driftseffektivitet.
Att automatisera återställningsåtgärder så mycket som möjligt är en integrerad del av driftseffektivitet. 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. Se dokumentationen för meddelandenivåerna Service Bus Premium och Standard för en genomgång av premium-nivåförmånerna. Mer information om hur du konfigurerar automatisk skalning av meddelandeenheter finns i dokumentationen för funktionen autoskalning .
Fler rekommendationer för Service Bus finns i Metodtips för prestandaförbättringar med hjälp av Service Bus-meddelanden.
Nästa steg
Mer information finns i Service Bus-dokumentationen:
- Översikt över integration av Azure Service Bus till Event Grid
- Service Bus Premium- och Standard-meddelandenivåer
- Autoskalningsfunktionen i Service Bus
- Metodtips för prestandaförbättringar med hjälp av Service Bus-meddelanden