Bewerken

Delen via


Een berichtenbroker en gebeurtenissen gebruiken om bedrijfssystemen te integreren

Azure Event Grid
Azure Service Bus

Deze architectuur is gebaseerd op de basisarchitectuur voor bedrijfsintegratie , maar bevat hoe u back-endsystemen van ondernemingen kunt integreren. Deze architectuur maakt gebruik van berichtbrokers en gebeurtenissen om services los te koppelen voor grotere schaalbaarheid en betrouwbaarheid. Zorg ervoor dat u bekend bent met het ontwerp en de onderdelen in de basisintegratiearchitectuur. Deze elementen bieden basisinformatie over de kernonderdelen van deze architectuur.

Architectuur

De back-endsystemen waarnaar dit ontwerp verwijst, omvatten SaaS-systemen (Software as a Service), Azure-services, berichtenservices en bestaande webservices in uw onderneming.

Diagram met een referentiearchitectuur voor bedrijfsintegratie die gebruikmaakt van wachtrijen en gebeurtenissen.

Een Visio-bestand van deze architectuur downloaden.

Scenariodetails

De voorgaande architectuur bouwt voort op de eenvoudigere basisarchitectuur voor bedrijfsintegratie die gebruikmaakt van Azure Logic Apps om werkstromen rechtstreeks te organiseren met back-endsystemen en maakt gebruik van Azure 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:

Deze architectuur maakt gebruik van asynchrone communicatie via een berichtenbroker in plaats van directe, synchrone aanroepen naar back-endservices te maken. Asynchrone communicatie biedt de volgende voordelen:

  • Het patroon Load Leveling op basis van wachtrij gebruikt om bursts in workloads te verwerken via load leveling

  • Maakt gebruik van het patroon Publisher-Subscriber, zodat u berichten kunt uitzenden naar meerdere consumenten

  • Houdt de voortgang van langlopende werkstromen betrouwbaar bij, zelfs wanneer ze meerdere stappen of meerdere toepassingen omvatten

  • Helpt bij het loskoppelen van toepassingen

  • Integreert met bestaande systemen op basis van berichten

  • Biedt de mogelijkheid om berichten in de wachtrij te plaatsen wanneer een back-endsysteem niet beschikbaar is

Gebruik Event Grid zodat verschillende onderdelen in het systeem kunnen reageren op gebeurtenissen wanneer ze plaatsvinden, in plaats van te vertrouwen op polling- of geplande taken. Net als bij een berichtenwachtrij en onderwerpen helpt Event Grid bij het loskoppelen van toepassingen en services. Als een toepassing of service gebeurtenissen publiceert, worden geïnteresseerde abonnees hiervan op de hoogte gesteld. U kunt nieuwe abonnees toevoegen 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. Met dit patroon worden reactieve werkstromen gemaakt waarin 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

Houd rekening met de volgende aanbevelingen. Zie De basisarchitectuur voor bedrijfsintegratie voor meer aanbevelingen.

Service Bus

Service Bus heeft twee leveringsmodellen, het pull-model en het geproxied pushmodel :

  • Pull-model: De ontvanger peilt continu naar nieuwe berichten. Als u meerdere wachtrijen en pollingtijden wilt beheren, kan polling inefficiënt zijn. Maar dit model kan uw architectuur vereenvoudigen omdat er extra onderdelen en gegevenshops worden verwijderd.

  • Proxied push-model: de ontvanger abonneert zich in eerste instantie op een specifiek gebeurtenistype in een Event Grid-onderwerp. Wanneer er een nieuw bericht beschikbaar is, genereert Service Bus een gebeurtenis en verzendt deze via Event Grid. Met deze gebeurtenis wordt de ontvanger vervolgens geactiveerd om de volgende batch berichten uit Service Bus op te halen. Met dit model kunnen systemen bijna in realtime berichten ontvangen, maar zonder resources te gebruiken om continu naar nieuwe berichten te peilen. Deze architectuur maakt gebruik van extra onderdelen die u moet implementeren, beheren en beveiligen.

Wanneer u een Standaard Logic Apps-werkstroom maakt die Service Bus-berichten verbruikt, raden we u aan de ingebouwde Service Bus-connectortriggers te gebruiken. De ingebouwde connector activeert het grootste deel van de configuratie van het pull-model zonder extra kosten toe te voegen. Deze mogelijkheid biedt de juiste balans tussen kosten, surface area management en beveiliging, omdat de connector continu wordt lussen binnen de Logic Apps-runtime-engine. Zie Ingebouwde Service Bus-connectortriggers voor meer informatie.

Gebruik de PeekLock-modus om toegang te krijgen 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 methode voorkomt onbedoeld berichtverlies.

Event Grid

Wanneer een Event Grid-trigger wordt geactiveerd, betekent dit dat er ten minste één gebeurtenis is opgetreden. Wanneer een logische app bijvoorbeeld een Event Grid-trigger voor een Service Bus-bericht ontvangt, zijn er mogelijk verschillende berichten beschikbaar 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 de controlelijst ontwerpbeoordeling voor betrouwbaarheid voor meer informatie.

Zie SLA's voor onlineservices voor informatie over gegarandeerde beschikbaarheid van elke service.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie de controlelijst ontwerpbeoordeling voor beveiliging voor meer informatie.

Als u Service Bus wilt beveiligen, koppelt u Microsoft Entra-verificatie aan beheerde identiteiten. Microsoft Entra ID-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, zoals een gebruiker, een groep of een toepassingsservice-principal. De service-principal van de toepassing in dit scenario is een beheerde identiteit.

Als u Microsoft Entra ID niet kunt gebruiken, gebruikt u SAS-verificatie (Shared Access Signature) om gebruikers toegang en specifieke rechten te verlenen aan Service Bus-resources.

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. U kunt vervolgens certificaten of OAuth-verificatie gebruiken om het eindpunt te beveiligen. De eenvoudigste manier om een eindpunt te beveiligen, is door een logische app te gebruiken die als intermediair een HTTP-aanvraag- of antwoordtrigger heeft.

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

Netwerkbeveiliging

Overweeg netwerkbeveiliging in uw ontwerp.

Kostenoptimalisatie

Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie de controlelijst ontwerpbeoordeling voor Kostenoptimalisatie voor meer informatie.

Gebruik de Azure-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 schaalt en u dat prestatieniveau niet meer nodig hebt, schaalt u handmatig omlaag of configureert u automatisch schalen.

Voor lichte gebruiksworkloads kunt u de verbruikslaag overwegen. Dit is een goedkope, serverloze optie. De verbruikslaag wordt gefactureerd per API-aanroep. Andere lagen worden per uur gefactureerd.

Logic Apps

Logic Apps maakt gebruik van een serverloos model. Facturering wordt berekend op basis van het aantal acties en connector-aanroepen. Zie Prijzen voor Logic Apps voor meer informatie.

Service Bus-wachtrijen, -onderwerpen en -abonnementen

Service Bus-wachtrijen en -abonnementen ondersteunen zowel geproxiede push- als pull-modellen om berichten te leveren. In het pull-model wordt elke polling-aanvraag gemeten als een actie. Zelfs als u lange polling instelt op de standaardwaarde van 30 seconden, kunnen de kosten hoog zijn. Tenzij u realtime berichtbezorging nodig hebt, kunt u overwegen 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 Service Bus-prijzen voor meer informatie.

Event Grid

Event Grid maakt gebruik van een serverloos model. Facturering wordt berekend op basis van het aantal bewerkingen. Bewerkingen omvatten gebeurtenissen die naar domeinen of onderwerpen, geavanceerde overeenkomsten, bezorgingspogingen en beheeroproepen gaan. Het gebruik van maximaal 100.000 bewerkingen is gratis.

Zie Prijzen van Event Grid en Well-Architected Framework Cost Optimization voor meer informatie.

Operationele topprestaties

Operational Excellence behandelt de operationele processen die een toepassing implementeren en deze in productie houden. Zie de controlelijst ontwerpbeoordeling voor Operational Excellence voor meer informatie.

De basisarchitectuur voor bedrijfsintegratie biedt richtlijnen over DevOps-patronen, die zijn afgestemd op de pijler Well-Architected Framework Operational Excellence .

Automatiseer herstelbewerkingen zoveel mogelijk om operationele uitmuntendheid te verbeteren. Met automatisering in het achterhoofd kunt u Azure-logboekbewaking combineren met Azure Automation om de failover van uw Service Bus-resources te automatiseren. Zie Failover-stroom voor een voorbeeld van automatiseringslogica voor het initiëren van een failover.

Prestatie-efficiëntie

Prestatie-efficiëntie is de mogelijkheid van uw workload om te schalen om te voldoen aan de eisen die gebruikers op een efficiënte manier stellen. Zie de controlelijst ontwerpbeoordeling voor prestatie-efficiëntie voor meer informatie.

Om een hogere schaalbaarheid te bereiken, kan de Service Bus Premium-laag het aantal berichteneenheden uitschalen. Zie de Service Bus Premium- en Standard-berichtenlagen en de functie Voor automatisch schalen voor meer informatie.

Zie Best practices voor prestatieverbeteringen met behulp van Service Bus-berichten voor meer Aanbevelingen voor Service Bus.

Volgende stappen