Een berichtenplatform kiezen
Veel communicatieplatforms zijn beschikbaar om de betrouwbaarheid van een gedistribueerde toepassing te verbeteren, waaronder verschillende in Microsoft Azure. Elk platform is een hulpprogramma dat een ander doel heeft. Het is belangrijk om het juiste hulpprogramma te kiezen voor elke vereiste in uw toepassing. Bekijk uw opties in Azure Service Bus.
Voor de voorgestelde gedistribueerde architectuur van Contoso Bicycles zijn verschillende onderdelen vereist, waaronder een website, gegevensopslag en een back-endservice. U kunt de onderdelen van uw toepassing op veel verschillende manieren verbinden en één toepassing kan profiteren van meerdere technieken.
U moet bepalen welke technieken moeten worden gebruikt in de nieuwe Contoso Bicycles-toepassing. De eerste stap is het evalueren van elke plaats waar er communicatie tussen meerdere onderdelen is. Sommige onderdelen moeten tijdig worden uitgevoerd om uw toepassing te laten werken. Sommige zijn mogelijk belangrijk, maar niet tijdkritiek. Ten slotte zijn andere onderdelen, zoals meldingen van mobiele apps, iets meer optioneel.
Kiezen tussen berichten en gebeurtenissen
Zowel berichten als gebeurtenissen zijn gegevensgrammen: pakketten met gegevens die van het ene onderdeel naar het andere worden verzonden. Ze zijn anders op manieren die in het begin subtiel lijken, maar de verschillen kunnen aanzienlijke verschillen maken in de manier waarop u uw toepassing ontwerpt.
Berichten
In de terminologie van gedistribueerde toepassingen is het definiëren van een bericht dat de algehele integriteit van de toepassing kan vertrouwen op berichten die worden ontvangen. U kunt het verzenden van een bericht zien als het ene onderdeel dat het stokje van de werkstroom doorgeeft aan een ander onderdeel. De hele werkstroom kan een essentieel bedrijfsproces zijn en het bericht is de mortier die de onderdelen bij elkaar houdt.
Een bericht bevat over het algemeen de werkelijke gegevens, niet alleen een verwijzing (zoals een id of een URL) naar gegevens. Het verzenden van gegevens als onderdeel van een datagram is minder broos dan het verzenden van een verwijzing. De berichtarchitectuur garandeert de bezorging van berichten en omdat er geen extra zoekacties vereist zijn, wordt het bericht betrouwbaar verwerkt. De verzendende toepassing moet echter precies weten welke gegevens moeten worden opgenomen om te voorkomen dat er te veel gegevens worden verzonden, waardoor het ontvangende onderdeel onnodig werk moet doen. In deze zin worden de afzender en ontvanger van het bericht vaak gekoppeld aan een strikt gegevenscontract.
In de nieuwe architectuur voor Contoso Bicycles, wanneer een bestelling wordt geplaatst, gebruikt het bedrijf waarschijnlijk berichten. De webfront-end- of mobiele app verzendt een bericht naar de back-endverwerkingsonderdelen. Op de back-end vindt u stappen zoals routering naar de dichtstbijzijnde winkel en het opladen van een creditcard plaats.
gebeurtenis
Een gebeurtenis activeert een melding waarin wordt meegedeeld dat er iets is voorgevallen. Gebeurtenissen zijn ‘lichter’ dan berichten en worden meestal gebruikt voor communicatie in de vorm van broadcasting.
Gebeurtenissen hebben de volgende kenmerken:
- De gebeurtenis kan worden verzonden naar meerdere ontvangers of helemaal niet.
- Gebeurtenissen zijn vaak bedoeld voor 'fan-out' of hebben een groot aantal abonnees voor elke uitgever.
- De gebeurtenisuitgever heeft geen verwachting over de actie die een ontvangend onderdeel neemt.
Een keten fietsonderdelen gebruikt waarschijnlijk gebeurtenissen voor gebruikersmeldingen over statuswijzigingen. Statuswijzigingsgebeurtenissen kunnen worden verzonden naar Azure Event Grid, vervolgens naar Azure Functions en naar Azure Notification Hubs voor een volledig serverloze oplossing.
Dit verschil tussen gebeurtenissen en berichten is van cruciaal belang omdat communicatieplatforms in het algemeen zijn ontworpen voor het verwerken van de een of de ander. Service Bus is ontworpen voor de verwerking van berichten. Als u gebeurtenissen wilt verzenden, kiest u waarschijnlijk Event Grid.
Azure heeft ook Azure Event Hubs, maar wordt het vaakst gebruikt voor een specifiek type stroom van communicatie die wordt gebruikt voor analyse. Als u bijvoorbeeld netwerksensoren in uw productiewarehouses had, kunt u Event Hubs in combinatie met Azure Stream Analytics gebruiken om te kijken naar patronen in temperatuurwijzigingen die kunnen duiden op ongewenste brand- of onderdeelslijtage.
Service Bus-onderwerpen en -wachtrijen
Azure Service Bus kan berichten op twee verschillende manieren uitwisselen: wachtrijen en onderwerpen.
Wat is een wachtrij?
Een Service Bus-wachtrij is een eenvoudige tijdelijke opslaglocatie voor berichten. Een verzendend onderdeel voegt een bericht aan de wachtrij toe. Een doelonderdeel haalt het bericht vooraan in de wachtrij op. Onder normale omstandigheden wordt elk bericht door slechts één ontvanger ontvangen.
Wachtrijen koppelen het bron- en -doelonderdeel van elkaar los om doelonderdelen af te schermen van een grote vraag.
Tijdens piektijden kunnen berichten sneller binnenkomen dan doelonderdelen deze kunnen verwerken. Omdat de brononderdelen geen directe verbinding met het doel hebben, wordt de bron niet beïnvloed en groeit de wachtrij. Doelonderdelen verwijderen berichten uit de wachtrij wanneer ze ze kunnen verwerken. Wanneer de vraag afneemt, kunnen doelonderdelen inhalen en wordt de wachtrij korter.
Een wachtrij reageert op hoge vraag zonder resources aan het systeem toe te voegen. Voor berichten die snel moeten worden verwerkt, kunnen er echter meer exemplaren van uw doelonderdeel worden gemaakt, zodat ze de belasting kunnen delen. Elk bericht wordt verwerkt door slechts één exemplaar. Deze methode is een effectieve manier om uw hele toepassing te schalen door alleen resources toe te voegen aan de onderdelen die deze daadwerkelijk nodig hebben.
Wat is een onderwerp?
Een Service Bus-onderwerp lijkt op een wachtrij, maar een onderwerp kan meerdere abonnementen hebben, wat betekent dat meerdere doelonderdelen zich kunnen abonneren op een specifiek onderwerp, zodat elk bericht wordt bezorgd bij meerdere ontvangers. Abonnementen kunnen ook de berichten in het onderwerp filteren voor het ontvangen van alleen de berichten die relevant zijn. Abonnementen bevatten de dezelfde losgekoppelde communicaties als wachtrijen en reageren op dezelfde manier op grote vraag. Gebruik een onderwerp als u wilt dat elk bericht aan meer dan één doelonderdeel moet worden afgeleverd.
Notitie
Onderwerpen worden niet ondersteund in de prijscategorie Basic.
Service Bus-wachtrijen en -opslagwachtrijen
Twee Azure-services omvatten berichtenwachtrijen: Service Bus en Azure Storage. Als algemene handleiding zijn opslagwachtrijen eenvoudiger te gebruiken, maar ze zijn minder geavanceerd en minder flexibel dan Service Bus-wachtrijen.
De belangrijkste voordelen van Service Bus-wachtrijen zijn:
- Ondersteunt grotere berichtengrootten van 256 kB (standard-laag) of 100 MB (Premium-laag) per bericht versus 64 kB voor Azure Storage-wachtrijberichten.
- Ondersteunt zowel ten hoogste één als ten minste één levering. Kies tussen een zeer kleine kans dat een bericht verloren gaat of een zeer kleine kans dat het twee keer wordt verwerkt.
- Garandeert first-in, first-out (FIFO) -volgorde. Berichten worden in dezelfde volgorde verwerkt als ze worden toegevoegd. Hoewel FIFO de normale werking van een wachtrij is, wordt het standaard FIFO-patroon gewijzigd als de organisatie gesequentieerde of geplande berichten instelt of tijdens onderbrekingen zoals een systeemcrash. Zie Azure Storage-wachtrijen en Azure Service Bus-wachtrijen vergelijken voor meer informatie.
- Kan meerdere berichten in één transactie groeperen. Als één bericht in de transactie niet kan worden bezorgd, worden alle berichten in de transactie niet bezorgd.
- Ondersteunt beveiliging op basis van rollen.
- Er zijn geen doelonderdelen vereist om de wachtrij continu te peilen.
Voordelen van opslagwachtrijen:
- Biedt ondersteuning voor onbeperkte wachtrijgrootte (in tegenstelling tot een limiet van 80 GB voor Service Bus-wachtrijen)
- Onderhoudt een logboek van alle berichten
Een communicatietechnologie kiezen
U hebt de verschillende concepten en de implementaties van Azure gezien. Bedenk vervolgens hoe uw beslissingsproces eruit moet zien voor elk van uw communicaties.
Overwegingen
Houd rekening met de volgende vragen wanneer u een methode kiest voor het verzenden en ontvangen van berichten:
Is de communicatie een gebeurtenis? Als dit het geval is, kunt u overwegen Event Grid of Event Hubs te gebruiken.
Moet een enkel bericht worden geleverd aan meer dan één bestemming? Gebruik in dit geval een Service Bus-onderwerp. Gebruik anders een Service Bus-wachtrij.
Wachtrijen: Service Bus versus opslag
Als u besluit dat u een wachtrij nodig hebt, kunt u uw keuze verder verfijnen.
Kies een Service Bus-wachtrij als:
- U hebt een garantie voor maximaal één levering nodig.
- U hebt een FIFO-garantie nodig (als er geen andere instellingen vooraf gaan aan de standaard FIFO-bestelling).
- U berichten wilt groeperen in transacties.
- U berichten wilt ontvangen zonder polling van de wachtrij.
- U moet op rollen gebaseerde toegang bieden tot de wachtrijen.
- U moet berichten verwerken die groter zijn dan 64 kB, maar kleiner dan 256 kB voor de standard-laag of 100 MB voor de Premium-laag.
- De grootte van uw wachtrij wordt niet groter dan 80 GB.
- U wilt batches van berichten kunnen publiceren en gebruiken.
Kies een opslagwachtrij als:
- U hebt een eenvoudige wachtrij nodig zonder specifieke extra vereisten.
- U een audittrail nodig heeft van alle berichten die door de wachtrij gaan.
- U verwacht dat de wachtrij groter wordt dan 80 GB.
- U wilt de voortgang bijhouden voor het verwerken van een bericht in de wachtrij.
Hoewel de onderdelen van een gedistribueerde toepassing rechtstreeks kunnen communiceren, kunt u de betrouwbaarheid van die communicatie vaak verhogen met behulp van een tussenliggend communicatieplatform, zoals Azure Event Hubs of Azure Event Grid.
Event Hubs en Event Grid zijn ontworpen voor gebeurtenissen, die ontvangers alleen op de hoogte stellen van een gebeurtenis en niet de onbewerkte gegevens bevatten die aan die gebeurtenis zijn gekoppeld. Azure Event Hubs is ontworpen voor high-flow, analysetypen van gebeurtenissen.
Azure Service Bus- en opslagwachtrijen zijn bedoeld voor berichten, die u kunt gebruiken voor het binden van de kernonderdelen van elke toepassingswerkstroom.
Als uw vereisten eenvoudig zijn, als u elk bericht naar slechts één bestemming wilt verzenden of als u zo snel mogelijk code wilt schrijven, is een opslagwachtrij mogelijk de beste optie. Anders bieden Service Bus-wachtrijen veel meer opties en flexibiliteit.
Als u berichten naar meerdere abonnees wilt verzenden, gebruikt u een Service Bus-onderwerp.