Bewerken

Patroon Berichtenbrug

Azure Service Bus

In dit artikel wordt het patroon Messaging Bridge beschreven. Dit is een techniek die u kunt gebruiken om verschillende systemen te integreren die zijn gebouwd op verschillende berichteninfrastructuren.

Context en probleem

Veel organisaties en workloads kunnen per ongeluk IT-systemen hebben die gebruikmaken van meerdere berichteninfrastructuren zoals MSMQ (Microsoft Message Queueing), RabbitMQ, Azure Service Bus en Amazon SQS. Dit probleem kan optreden als gevolg van fusies, overnames of door het uitbreiden van de huidige on-premises systemen naar in de cloud gehoste onderdelen voor kosteneffectiviteit en het gemak van onderhoud.

Ontwikkelaars kunnen deze uitdaging aanpakken door de systemen te wijzigen die worden geïntegreerd om te communiceren met behulp van op HTTP gebaseerde webservices. Deze aanpak heeft echter nadelen, waaronder:

  • De systemen moeten worden gewijzigd door een HTTP-client aan de ene kant en een HTTP-aanvraaghandler aan de andere kant toe te voegen. De systemen moeten vervolgens opnieuw worden getest en opnieuw worden geïmplementeerd.
  • HTTP-eindpunten moeten worden gehost, wat complexiteit toevoegt wanneer u webservices veilig en maximaal beschikbaar maakt.
  • Veelvoorkomende problemen met de netwerkverbinding waarvoor aangepaste mechanismen voor opnieuw proberen zijn vereist.

Oplossing

Als de systemen die worden geïntegreerd, bestaan uit onderdelen die communiceren door berichten uit te wisselen, verbetert het berichtenbrugpatroon de integratie en vermindert het nadelen.

In dit scenario maakt elk systeem verbinding met één berichteninfrastructuur. Als u wilt integreren in verschillende berichteninfrastructuren, introduceert u een brugonderdeel dat tegelijkertijd verbinding maakt met twee of meer berichteninfrastructuren. De brug haalt berichten van de ene en pusht ze naar de andere zonder de nettolading te wijzigen.

De systemen die worden geïntegreerd hoeven de anderen of de brug niet te herkennen. Het afzendersysteem is geconfigureerd voor het verzenden van specifieke berichten naar een aangewezen wachtrij in de systeemeigen berichteninfrastructuur. De brug haalt deze berichten op en stuurt ze door naar een andere wachtrij in een andere berichteninfrastructuur waar het ontvangersysteem ze ophaalt.

Vergoedingen

  • De systemen die worden geïntegreerd via de Messaging Bridge hoeven niet te worden gewijzigd. Idealiter zijn de eindpunten niet op de hoogte dat de berichten worden overbrugd.
  • De integratie is betrouwbaarder vergeleken met het HTTP-alternatief vanwege de garantie van ten minste één keer berichtbezorging.
  • Migratiescenario's kunnen flexibeler zijn. Eindpunten kunnen bijvoorbeeld worden gemigreerd van de ene berichteninfrastructuur naar de andere, omdat de planning toestaat in plaats van allemaal tegelijk.

Nadelen

  • Geavanceerde functies van een of beide berichttechnologieën zijn mogelijk niet beschikbaar op de overbrugde route.
  • De overbrugde route moet rekening houden met de beperkingen van beide technologieën. De maximale berichtgrootte kan bijvoorbeeld 4 MB in MSMQ zijn, maar slechts 64 kB in Azure Storage-wachtrijen.

Problemen en overwegingen

Houd rekening met de volgende punten bij het implementeren van het patroon Messaging Bridge:

  • Als een van de geïntegreerde systemen afhankelijk is van gedistribueerde transacties, bijvoorbeeld Microsoft Distributed Transaction Coordinator (DTC), moet u een ontdubbelingsmechanisme in de brug implementeren.

  • Als een van de systemen die worden geïntegreerd geen berichteninfrastructuur gebruikt en niet kan worden gewijzigd, kunt u de Berichtenbrug bouwen tussen de infrastructuur die wordt gebruikt door het andere systeem en een door SQL Server geëmuleerde wachtrij. Het verouderde systeem kan berichten verzenden met behulp van de functie voor het vastleggen van wijzigingen van gegevens voor SQL Server om de wijzigingen naar een toegewezen wachtrijtabel te pushen. De brug kan deze berichten doorsturen naar de werkelijke berichteninfrastructuur.

  • U kunt één wachtrij gebruiken in elke berichteninfrastructuur, aangeduid als de overbruggingswachtrij. In deze topologie configureert u het verzendende systeem om die specifieke wachtrij te gebruiken als de bestemming voor berichttypen die naar het andere systeem worden verzonden. U kunt ook meerdere paren wachtrijen in elke berichteninfrastructuur gebruiken, zodat de afzender zich niet bewust is van de brug. Er wordt een schaduwwachtrij gemaakt voor elke doelwachtrij in de berichteninfrastructuur van het doelsysteem. De brug stuurt berichten door tussen de schaduwwachtrijen en hun tegenhangers.

  • Als u wilt voldoen aan de gewenste SLA's (Service Level Agreements), moet u de Messaging Bridge mogelijk uitschalen met behulp van de benadering concurrerende consumenten .

  • Normale onderdelen voor berichtverwerking gebruiken het patroon Opnieuw proberen om tijdelijke fouten af te handelen. Met de limiet voor opnieuw proberen kunnen onderdelen gifberichten detecteren en verwijderen uit de wachtrij om de verwerking op te heffen. De brug vereist mogelijk een ander beleid voor opnieuw proberen om te voorkomen dat berichten als gif worden geïdentificeerd als er een infrastructuurfout optreedt. U kunt het circuitonderbrekerpatroon gebruiken om doorsturen te onderbreken.

Wanneer dit patroon gebruiken

Gebruik het patroon Messaging Bridge wanneer u het volgende moet doen:

  • Integreer bestaande systemen met minimale behoefte aan aanpassingen.
  • Oudere toepassingen integreren die geen gebruik kunnen maken van andere berichttechnologieën.
  • Breid bestaande on-premises toepassingen uit met in de cloud gehoste onderdelen.
  • Verbinding maken geografisch gedistribueerde systemen wanneer de internetverbinding niet stabiel is.
  • Migreer één gedistribueerd systeem van de ene berichteninfrastructuur naar een andere, zonder dat het hele systeem in één poging hoeft te worden gemigreerd.

Dit patroon is mogelijk niet geschikt als:

  • Ten minste één van de betrokken systemen is afhankelijk van een functie van één berichteninfrastructuur die niet aanwezig is in de andere.
  • Integratie is synchroon en het initiërende systeem vereist onmiddellijke reactie.
  • Integratie heeft specifieke functionele of niet-functionele vereisten, zoals beveiligings- of privacyproblemen.
  • Het volume aan gegevens voor de integratie overschrijdt de capaciteit van het berichtensysteem of maakt berichten een dure oplossing voor het probleem.

Workloadontwerp

Een architect moet evalueren hoe het Messaging Bridge-patroon kan worden gebruikt in het ontwerp van hun workload om de doelstellingen en principes te verhelpen die worden behandeld in de pijlers van het Azure Well-Architected Framework. Voorbeeld:

Pijler Hoe dit patroon ondersteuning biedt voor pijlerdoelen
Kostenoptimalisatie is gericht op het ondersteunen en verbeteren van het rendement van uw workload op investering. Deze tussenliggende stap kan de levensduur van uw bestaande systeem verhogen zonder dat er herschrijven nodig is door interoperabiliteit mogelijk te maken met systemen die gebruikmaken van een andere bericht- of gebeurtenistechnologie.

- CO:07 Componentkosten
Operational Excellence helpt bij het leveren van workloadkwaliteit via gestandaardiseerde processen en teamcohesie. Deze ontkoppeling biedt flexibiliteit wanneer u berichten- en gebeurtenistechnologie binnen uw workload overschakelt of wanneer u heterogene vereisten hebt van externe afhankelijkheden.

- OE:06 Workloadwijzigingen implementeren

Net als bij elke ontwerpbeslissing moet u rekening houden met eventuele compromissen ten opzichte van de doelstellingen van de andere pijlers die met dit patroon kunnen worden geïntroduceerd.

Opmerking

Er is een toepassing geschreven in een .NET Framework voor het beheren van de planning van werknemers die on-premises worden gehost. De toepassing is goed gestructureerd met afzonderlijke onderdelen die communiceren via MSMQ. De toepassing werkt en het workloadteam heeft geen intentie om deze te herschrijven. Een nieuwe consument van de planningsgegevens moet worden gebouwd om te voldoen aan een bedrijfsbehoefte en de IT-strategie vraagt om nieuwe software te bouwen als cloudtoepassingen om de kosten en levertijd te optimaliseren.

De asynchrone architectuur op basis van wachtrijen werkte in het verleden voor het workloadteam, dus het team gaat dezelfde architectuurbenadering gebruiken, maar met de moderne technologie, Service Bus. Het workloadteam wil geen synchrone communicatie tussen de cloud en de on-premises implementatie introduceren om de latentie of onbeschikbaarheid te beperken die van invloed is op de andere.

Het team besluit het patroon Messaging Bridge te gebruiken om de twee systemen te verbinden. Het patroon bestaat uit twee delen. Eén onderdeel ontvangt berichten van de bestaande MSMQ-wachtrij en stuurt deze door naar Service Bus. Het andere deel neemt berichten van de Service Bus en stuurt ze door naar de bestaande MSMQ-wachtrij.

Diagram van de Messaging Bridge waarin MSMQ en Service Bus worden geïntegreerd.

Wanneer het implementatieteam deze benadering gebruikt, gebruiken ze bestaande infrastructuur in de bestaande toepassing om te integreren met de nieuwe onderdelen. De bestaande toepassing is niet op de hoogte dat de nieuwe onderdelen worden gehost in Azure. Op dezelfde manier communiceren de nieuwe onderdelen met de verouderde toepassing op dezelfde manier als ze onderling communiceren door Service Bus-berichten te verzenden. De brug stuurt berichten door tussen de twee systemen.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

  • Beschrijving van het Messaging Bridge-patroon van de community voor bedrijfsintegratiepatronen.
  • Meer informatie over het implementeren van een Messaging Bridge in het Spring Java-framework.
  • QPid-brug kan worden gebruikt om berichtentechnologieën met AMQP te overbruggingen.
  • De NServiceBus Messaging Bridge is een .NET-implementatie van een wachtrij-naar-wachtrij-brug die ondersteuning biedt voor verschillende berichteninfrastructuren, waaronder MSMQ, Service Bus en Azure Queue Storage.
  • NServiceBus.Router is een opensource-project dat het Messaging Bridge-patroon implementeert. Het maakt het ook mogelijk om meer dan twee technologieën in één exemplaar te overbruggen en beschikt over geavanceerde mogelijkheden voor berichtroutering.