Bedrijfsintegratie met berichtenbroker en gebeurtenissen

Azure Event Grid
Azure Service Bus

Deze voorbeeldarchitectuur is gebaseerd op de basisarchitectuur voor bedrijfsintegratie . Het breidt die architectuur uit om te laten zien hoe u back-endsystemen van ondernemingen integreert door berichtenbrokers en gebeurtenissen te gebruiken om services los te koppelen voor grotere schaalbaarheid en betrouwbaarheid. Zorg ervoor dat u bekend bent met dat ontwerp en de onderdelen die worden gebruikt in de basisintegratiearchitectuur. Het biedt basisinformatie over de kernonderdelen van deze architectuur, die hier niet worden gereproduceerd.

Architectuur

De back-endsystemen waarnaar in dit ontwerp wordt verwezen, kunnen saaS-systemen (Software as a Service), Azure-services en bestaande webservices in uw onderneming bevatten.

Reference architecture for enterprise integration using queues and events

Een Visio-bestand van deze architectuur downloaden.

Workflow

De architectuur die hier wordt weergegeven, is gebaseerd op een eenvoudigere architectuur die wordt weergegeven in basic enterprise-integratie. Deze architectuur maakt gebruik van Logic Apps om werkstromen rechtstreeks te organiseren met back-endsystemen en API Management om catalogi van API's te maken.

Deze versie van de architectuur voegt twee onderdelen toe waarmee het systeem betrouwbaarder en schaalbaarder wordt:

Asynchrone communicatie met behulp van een berichtenbroker biedt de volgende voordelen ten opzichte van het maken van directe, synchrone aanroepen naar back-endservices:

  • Biedt load-leveling voor het verwerken van bursts in workloads, met behulp van het patroon Load Leveling op basis van wachtrij.
  • Biedt voor het uitzenden van berichten aan meerdere consumenten met het patroon Publisher-Subscriber.
  • Houdt op betrouwbare wijze de voortgang bij van langlopende werkstromen die meerdere stappen of meerdere toepassingen omvatten.
  • Helpt bij het loskoppelen van toepassingen.
  • Kan worden geïntegreerd met bestaande systemen op basis van berichten.
  • Hiermee kan werk in de wachtrij worden geplaatst wanneer er geen back-endsysteem beschikbaar is.

Met Event Grid kunnen de verschillende onderdelen in het systeem reageren op gebeurtenissen wanneer ze plaatsvinden, in plaats van te vertrouwen op polling- of geplande taken. Net als bij een berichtenwachtrij en onderwerpen kunnen toepassingen en services worden losgekoppeld. Een toepassing of service kan gebeurtenissen publiceren en alle geïnteresseerde abonnees worden op de hoogte gesteld. Nieuwe abonnees kunnen worden toegevoegd zonder de afzender bij te werken.

Veel Azure-services ondersteunen het verzenden van gebeurtenissen naar Event Grid. Een logische app kan bijvoorbeeld luisteren naar een gebeurtenis wanneer nieuwe bestanden worden toegevoegd aan een blobarchief. Dit patroon maakt reactieve werkstromen mogelijk, waarbij het uploaden van een bestand of het plaatsen van een bericht in een wachtrij een reeks processen start. De processen kunnen parallel of in een specifieke volgorde worden uitgevoerd.

Aanbevelingen

De aanbevelingen die worden beschreven in Basic Enterprise Integration zijn van toepassing op deze architectuur.

Service Bus

Service Bus heeft twee leveringsmodi, pull of geproxied push. In het pull-model peilt de ontvanger continu naar nieuwe berichten. Polling kan inefficiënt zijn, vooral als u veel wachtrijen hebt die elk een paar berichten ontvangen of als er veel tijd tussen berichten is. In het geproxied pushmodel verzendt Service Bus een gebeurtenis via Event Grid wanneer er nieuwe berichten zijn. De ontvanger abonneert zich op de gebeurtenis. Wanneer de gebeurtenis wordt geactiveerd, haalt de ontvanger de volgende batch berichten op uit Service Bus.

Wanneer u een logische app maakt om Service Bus-berichten te gebruiken, wordt u aangeraden het geproxied pushmodel te gebruiken met Event Grid-integratie. Het is vaak rendabeler, omdat de logische app Service Bus niet hoeft te peilen. Zie het overzicht van integratie van Azure Service Bus naar Event Grid voor meer informatie. Momenteel is de Service Bus Premium-laag vereist voor Event Grid-meldingen.

Gebruik PeekLock voor toegang tot een groep berichten. Wanneer u PeekLock gebruikt, kan de logische app stappen uitvoeren om elk bericht te valideren voordat u het bericht voltooit of afgeeft. Deze aanpak beschermt tegen onbedoeld berichtverlies.

Event Grid

Wanneer een Event Grid-trigger wordt geactiveerd, betekent dit dat er ten minste één gebeurtenis is gebeurd. Wanneer een logische app bijvoorbeeld een Event Grid-trigger voor een Service Bus-bericht ophaalt, wordt ervan uitgegaan dat er verschillende berichten beschikbaar zijn om te verwerken.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Betrouwbaarheid

Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie Overzicht van de betrouwbaarheidspijler voor meer informatie.

  • Microsoft Entra ID: Microsoft Entra ID is een wereldwijd gedistribueerd saaS-platform met hoge beschikbaarheid. Raadpleeg de SLA voor gegarandeerde beschikbaarheidsdetails.
  • API Management: API Management kan worden geïmplementeerd in verschillende configuraties met hoge beschikbaarheid, op basis van bedrijfsvereisten en kostentolerantie. Raadpleeg de beschikbaarheid en betrouwbaarheid van API Management garanderen voor een volledig overzicht van de opties. Raadpleeg ook de SLA voor gegarandeerde beschikbaarheidsdetails.
  • Logic Apps: Geografisch redundante opslag is beschikbaar voor Logic Apps in de laag Verbruiksabonnement. Raadpleeg de richtlijnen voor meer informatie over het ontwerpen van een bedrijfscontinuïteits- en noodhersteloplossing. Raadpleeg ook de SLA voor gegarandeerde beschikbaarheidsdetails.
  • Event Grid: Resourcedefinities van Event Grid voor onderwerpen, systeemonderwerpen, domeinen en gebeurtenisabonnementen en gebeurtenisgegevens worden automatisch gerepliceerd in drie beschikbaarheidszones (indien beschikbaar) in de regio. Wanneer er een fout opgetreden is in een van de beschikbaarheidszones, voert Event Grid-resources automatisch een failover uit naar een andere beschikbaarheidszone zonder menselijke tussenkomst. Raadpleeg het geo-noodherstel tussen regio's voor hulp bij het ontwerpen van een noodhersteloplossing voor failover naar een andere regio. Raadpleeg ook de SLA voor gegarandeerde beschikbaarheidsdetails.
  • Service Bus: Service Bus Premium biedt ondersteuning voor geo-noodherstel en Beschikbaarheidszones. Replicatie is beschikbaar voor Service Bus Standard. Raadpleeg ook de SLA voor gegarandeerde beschikbaarheidsdetails.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.

Gebruik Microsoft Entra-verificatie die is gekoppeld aan beheerde identiteiten om Service Bus te beveiligen. Microsoft Entra-integratie voor Service Bus-resources biedt op rollen gebaseerd toegangsbeheer (RBAC) van Azure voor fijnmazige controle over de toegang van een client tot resources. U kunt Azure RBAC gebruiken om machtigingen te verlenen aan een beveiligingsprincipaal. Dit kan een gebruiker, een groep of een toepassingsservice-principal zijn (in dit geval een beheerde identiteit).

Als Microsoft Entra-id niet beschikbaar is, kunt u Shared Access Signature (SAS) gebruiken. U kunt een gebruiker toegang verlenen tot Service Bus-resources met specifieke rechten met behulp van SAS-verificatie.

Als u bijvoorbeeld een Service Bus-wachtrij of -onderwerp als EEN HTTP-eindpunt beschikbaar wilt maken om nieuwe berichten te posten, gebruikt u API Management om de wachtrij te beveiligen door het eindpunt te fronten. Vervolgens kunt u het eindpunt beveiligen met certificaten of OAuth-verificatie. De eenvoudigste manier om een eindpunt te beveiligen, is door een logische app te gebruiken met een HTTP-aanvraag-/antwoordtrigger als intermediair.

De Event Grid-service beveiligt de levering van gebeurtenissen via een validatiecode. Als u Logic Apps gebruikt om de gebeurtenis te gebruiken, wordt de validatie automatisch uitgevoerd. Zie Event Grid-beveiliging en -verificatie voor meer informatie.

Netwerkbeveiliging

Netwerkbeveiliging moet in het ontwerp worden overwogen.

Kostenoptimalisatie

Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.

Gebruik in ieder geval de prijscalculator om een schatting van de kosten te maken. Hier volgen enkele andere overwegingen.

API Management

Er worden kosten in rekening gebracht voor alle API Management-exemplaren wanneer ze worden uitgevoerd. Als u omhoog hebt geschaald en dit prestatieniveau niet altijd nodig hebt, schaalt u handmatig omlaag of configureert u automatisch schalen.

Voor lichte gebruiksworkloads moet u rekening houden met de verbruikslaag. Dit is een goedkope, serverloze optie. De verbruikslaag wordt gefactureerd per API-aanroep, terwijl de andere lagen per uur worden gefactureerd.

Logic-apps

Logic Apps maakt gebruik van een serverloos model. Facturering wordt berekend op basis van actie en connectoruitvoering. Zie Prijzen voor Logic Apps voor meer informatie.

Service Bus-wachtrijen, -onderwerpen en -abonnementen

Service Bus-wachtrijen en -abonnementen ondersteunen zowel geproxied push- als pull-modellen voor het leveren van berichten. In het pull-model wordt elke polling-aanvraag gemeten als een actie. Zelfs bij lange polling op 30 sec (standaard) kunnen de kosten hoog zijn. Tenzij u realtime bezorging van berichten nodig hebt, kunt u overwegen om het geproxied pushmodel te gebruiken.

Service Bus-wachtrijen zijn opgenomen in alle lagen (Basic, Standard en Premium). Service Bus-onderwerpen en -abonnementen zijn beschikbaar in standard- en Premium-lagen. Zie De prijzen van Azure Service Bus voor meer informatie.

Event Grid

Event Grid maakt gebruik van een serverloos model. Facturering wordt berekend op basis van het aantal bewerkingen (gebeurtenisuitvoeringen). Bewerkingen zijn onder meer de opname van gebeurtenissen in Domeinen of Onderwerpen, geavanceerde overeenkomsten, leveringspogingen en beheeraanroepen. Het gebruik van maximaal 100.000 bewerkingen is gratis.

Zie Prijzen voor Event Grid voor meer informatie.

Raadpleeg de kostensectie in Microsoft Azure Well-Architected Framework voor meer informatie.

Operationele topprestaties

De referentiearchitectuur basic Enterprise Integration biedt richtlijnen voor DevOps-patronen, die zijn afgestemd op de operationele uitmuntendheidpijler van het Well-Architected Framework.

Het zoveel mogelijk automatiseren van herstelbewerkingen is een integraal onderdeel van Operational Excellence. Met automatisering in het achterhoofd kunt u Azure-logboekbewaking combineren met Azure Automation om de failover van uw Service Bus-resources te automatiseren. Raadpleeg het diagram in de documentatie over failoverstromen voor een voorbeeld van automatiseringslogica om een failover te initiëren.

Prestatie-efficiëntie

Prestatie-efficiëntie is de mogelijkheid om op efficiënte wijze uw werkbelasting te schalen om te voldoen aan de vereisten die gebruikers eraan stellen. Zie overzicht van de pijler Prestatie-efficiëntie voor meer informatie.

Om een hogere schaalbaarheid te bereiken, kan de Service Bus Premium-laag het aantal berichteneenheden uitschalen. Raadpleeg de documentatie over service bus premium- en Standard-berichtenlagen voor een beoordeling van de voordelen van de Premium-laag. Raadpleeg ook de documentatie voor automatische schaalaanpassing voor meer informatie over het configureren van de automatische schaalaanpassing van berichteneenheden.

Meer aanbevelingen voor Service Bus vindt u in best practices voor prestatieverbeteringen met behulp van Service Bus Messaging.

Volgende stappen

Zie de Service Bus-documentatie voor meer informatie: