Service-naar-service-communicatie
Tip
Deze inhoud is een fragment uit het eBook, Cloud Native .NET Applications for Azure ontwerpen, beschikbaar op .NET Docs of als een gratis downloadbare PDF die offline kan worden gelezen.
Als u overstapt van de front-endclient, communiceren we nu met elkaar over back-end microservices.
Wanneer u een cloudeigen toepassing maakt, wilt u gevoelig zijn voor hoe back-endservices met elkaar communiceren. In het ideale geval, hoe minder communicatie tussen services, hoe beter. Vermijding is echter niet altijd mogelijk omdat back-endservices vaak afhankelijk zijn van elkaar om een bewerking te voltooien.
Er zijn verschillende algemeen geaccepteerde benaderingen voor het implementeren van communicatie tussen services. Het type communicatie-interactie bepaalt vaak de beste aanpak.
Houd rekening met de volgende interactietypen:
Query : wanneer een aanroepende microservice een reactie van een gebelde microservice vereist, zoals 'Hé, geef mij de koperinformatie voor een bepaalde klant-id'.
Opdracht : wanneer de aanroepende microservice een andere microservice nodig heeft om een actie uit te voeren, maar geen antwoord nodig heeft, zoals 'Hey, just ship this order'.
Gebeurtenis : wanneer een microservice, de uitgever genoemd, een gebeurtenis genereert die is gewijzigd of een actie heeft plaatsgevonden. Andere microservices, abonnees die geïnteresseerd zijn, kunnen op de juiste wijze reageren op de gebeurtenis. De uitgever en de abonnees zijn niet op de hoogte van elkaar.
Microservicesystemen gebruiken doorgaans een combinatie van deze interactietypen bij het uitvoeren van bewerkingen waarvoor interactie tussen services is vereist. Laten we eens kijken hoe u ze kunt implementeren.
Query's
Vaak moet één microservice mogelijk een query uitvoeren op een andere, waarvoor een onmiddellijke reactie nodig is om een bewerking te voltooien. Een winkelmand microservice heeft mogelijk productinformatie en een prijs nodig om een artikel aan zijn winkelwagen toe te voegen. Er zijn veel benaderingen voor het implementeren van querybewerkingen.
Bericht over aanvragen/antwoorden
Een optie voor het implementeren van dit scenario is dat de aanroepende back-end microservice directe HTTP-aanvragen kan indienen bij de microservices waarvoor een query moet worden uitgevoerd, zoals wordt weergegeven in afbeelding 4-8.
Afbeelding 4-8. Directe HTTP-communicatie
Hoewel directe HTTP-aanroepen tussen microservices relatief eenvoudig te implementeren zijn, moet u ervoor zorgen dat deze procedure wordt geminimaliseerd. Om te beginnen zijn deze aanroepen altijd synchroon en worden de bewerking geblokkeerd totdat een resultaat wordt geretourneerd of er een time-out optreedt voor de aanvraag. Wat ooit zelfstandige, onafhankelijke services waren, onafhankelijk van elkaar konden ontwikkelen en regelmatig konden implementeren, worden nu gekoppeld aan elkaar. Naarmate de koppeling tussen microservices toeneemt, nemen hun architecturale voordelen af.
Het uitvoeren van een onregelmatige aanvraag die één directe HTTP-aanroep naar een andere microservice uitvoert, is mogelijk acceptabel voor sommige systemen. Aanroepen van grote volumes die directe HTTP-aanroepen naar meerdere microservices aanroepen, zijn echter niet aan te raden. Ze kunnen latentie verhogen en een negatieve invloed hebben op de prestaties, schaalbaarheid en beschikbaarheid van uw systeem. Nog erger, een lange reeks directe HTTP-communicatie kan leiden tot diepe en complexe ketens van synchrone microservicesaanroepen, zoals weergegeven in afbeelding 4-9:
Afbeelding 4-9. HTTP-query's koppelen
U kunt zich zeker het risico voorstellen in het ontwerp dat in de vorige afbeelding wordt weergegeven. Wat gebeurt er als stap 3 mislukt? Of mislukt stap 8? Hoe herstelt u dit? Wat gebeurt er als stap 6 traag is omdat de onderliggende service bezet is? Hoe gaat u verder? Zelfs als alles correct werkt, denk dan aan de latentie die deze aanroep zou veroorzaken. Dit is de som van de latentie van elke stap.
De grote mate van koppeling in de vorige afbeelding suggereert dat de services niet optimaal zijn gemodelleerd. Het team zou moeten terugkeren naar hun ontwerp.
Gerealiseerde weergave-patroon
Een populaire optie voor het verwijderen van microservicekoppelingen is het patroon Gerealiseerde weergave. Met dit patroon slaat een microservice een eigen lokale, gedenormaliseerde kopie op van gegevens die eigendom zijn van andere services. In plaats van de microservice Shopping Basket die query's uitvoert op de microservices Productcatalogus en Prijzen, onderhoudt deze een eigen lokale kopie van die gegevens. Dit patroon elimineert onnodige koppeling en verbetert de betrouwbaarheid en reactietijd. De hele bewerking wordt binnen één proces uitgevoerd. We verkennen dit patroon en andere problemen met betrekking tot gegevens in hoofdstuk 5.
Serviceaggregator-patroon
Een andere optie voor het elimineren van microservice-naar-microservicekoppeling is een Aggregator-microservice, weergegeven in paars in afbeelding 4-10.
Afbeelding 4-10. Aggregator-microservice
Het patroon isoleert een bewerking die aanroept naar meerdere back-end microservices, waarbij de logica wordt gecentraliseerd in een gespecialiseerde microservice. De paarse aggregator-microservice voor uitchecken in de vorige afbeelding organiseert de werkstroom voor de uitgecheckte bewerking. Het omvat aanroepen naar verschillende back-end microservices in een gesequentieerde volgorde. Gegevens uit de werkstroom worden geaggregeerd en geretourneerd naar de aanroeper. Hoewel er nog steeds directe HTTP-aanroepen worden geïmplementeerd, vermindert de microservice van de aggregator directe afhankelijkheden tussen back-end microservices.
Patroon Aanvraag/antwoord
Een andere benadering voor het loskoppelen van synchrone HTTP-berichten is een request-reply-patroon, dat gebruikmaakt van wachtrijcommunicatie. Communicatie met behulp van een wachtrij is altijd een éénrichtingskanaal, waarbij een producent het bericht verzendt en de consument het ontvangt. Met dit patroon worden zowel een aanvraagwachtrij als een antwoordwachtrij geïmplementeerd, weergegeven in afbeelding 4-11.
Afbeelding 4-11. Patroon aanvraag-antwoord
Hier maakt de producent van berichten een op query's gebaseerd bericht met een unieke correlatie-id en plaatst deze in een aanvraagwachtrij. De verbruikende service verwijdert de berichten, verwerkt deze en plaatst het antwoord in de antwoordwachtrij met dezelfde correlatie-id. De producerservice verwijdert het bericht uit de wachtrij, komt overeen met de correlatie-id en blijft verwerken. We behandelen wachtrijen in detail in de volgende sectie.
Opdracht
Een ander type communicatie-interactie is een opdracht. Een microservice heeft mogelijk een andere microservice nodig om een actie uit te voeren. De order microservice heeft mogelijk de microservice Verzending nodig om een zending te maken voor een goedgekeurde bestelling. In afbeelding 4-12 verzendt één microservice, een producent genoemd, een bericht naar een andere microservice, de consument, die opdracht geeft om iets te doen.
Afbeelding 4-12. Interactie met opdrachten met een wachtrij
Meestal heeft de producent geen antwoord nodig en kan het bericht worden geactiveerd en vergeten . Als er een antwoord nodig is, stuurt de consument een afzonderlijk bericht terug naar Producer op een ander kanaal. Een opdrachtbericht wordt het beste asynchroon verzonden met een berichtenwachtrij. ondersteund door een lichtgewicht berichtbroker. In het vorige diagram ziet u hoe een wachtrij beide services scheidt en loskoppelt.
Aangezien veel berichtenwachtrijen hetzelfde bericht meer dan één keer kunnen verzenden, ook wel ten minste één keer bezorging genoemd, moet de consument deze scenario's correct kunnen identificeren en afhandelen met behulp van de relevante idempotente berichtverwerkingspatronen.
Een berichtenwachtrij is een tussenliggende constructie waarmee een producent en consument een bericht doorgeven. Wachtrijen implementeren een asynchroon, punt-naar-punt-berichtenpatroon. De producent weet waar een opdracht moet worden verzonden en routes op de juiste wijze moet worden gerouteerd. De wachtrij garandeert dat een bericht wordt verwerkt door precies een van de consumentenexemplaren die vanuit het kanaal worden gelezen. In dit scenario kan de producent of consumentenservice worden uitgeschaald zonder dat dit van invloed is op de andere. Daarnaast kunnen technologieën aan elke kant verschillen, wat betekent dat we mogelijk een Java-microservice hebben die een Golang-microservice aanroept.
In hoofdstuk 1 hebben we het gehad over backingservices. Backing-services zijn ondersteunende resources waarop cloudeigen systemen afhankelijk zijn. Berichtenwachtrijen zijn back-upservices. De Azure-cloud ondersteunt twee soorten berichtenwachtrijen die uw cloudeigen systemen kunnen gebruiken om opdrachtberichten te implementeren: Azure Storage Queues en Azure Service Bus Queues.
Azure Storage-wachtrijen
Azure Storage-wachtrijen bieden een eenvoudige infrastructuur voor wachtrijen die snel, betaalbaar en ondersteund wordt door Azure-opslagaccounts.
Azure Storage-wachtrijen bieden een op REST gebaseerd wachtrijmechanisme met betrouwbare en permanente berichten. Ze bieden een minimale functieset, maar zijn goedkoop en slaan miljoenen berichten op. Hun capaciteit varieert tot 500 TB. Eén bericht kan maximaal 64 kB groot zijn.
U kunt overal ter wereld toegang krijgen tot berichten via geverifieerde aanroepen via HTTP of HTTPS. Opslagwachtrijen kunnen worden uitgebreid naar grote aantallen gelijktijdige clients om pieken in het verkeer te verwerken.
Dat gezegd hebbende, er zijn beperkingen met de service:
Berichtvolgorde is niet gegarandeerd.
Een bericht kan slechts zeven dagen worden bewaard voordat het automatisch wordt verwijderd.
Ondersteuning voor statusbeheer, dubbele detectie of transacties is niet beschikbaar.
Afbeelding 4-13 toont de hiërarchie van een Azure Storage-wachtrij.
Afbeelding 4-13. Opslagwachtrijhiërarchie
In de vorige afbeelding ziet u hoe opslagwachtrijen hun berichten opslaan in het onderliggende Azure Storage-account.
Voor ontwikkelaars biedt Microsoft verschillende client- en serverbibliotheken voor opslagwachtrijverwerking. De meeste belangrijke platforms worden ondersteund, waaronder .NET, Java, JavaScript, Ruby, Python en Go. Ontwikkelaars moeten nooit rechtstreeks met deze bibliotheken communiceren. Hierdoor wordt uw microservicecode nauw gekoppeld aan de Azure Storage Queue-service. Het is een betere gewoonte om de implementatiedetails van de API te isoleren. Introduceer een tussenliggende laag of tussenliggende API die algemene bewerkingen blootstelt en de concrete bibliotheek inkapselt. Met deze losse koppeling kunt u de ene wachtrijservice voor een andere verwisselen zonder dat u wijzigingen hoeft aan te brengen in de code van de mainlineservice.
Azure Storage-wachtrijen zijn een voordelige optie voor het implementeren van opdrachtberichten in uw cloudeigen toepassingen. Vooral wanneer een wachtrij groter is dan 80 GB of een eenvoudige functieset acceptabel is. U betaalt alleen voor de opslag van de berichten; er zijn geen vaste kosten per uur.
Azure Service Bus-wachtrijen
Overweeg Azure Service Bus-wachtrijen voor complexere berichtenvereisten.
Azure Service Bus ondersteunt een brokered messaging-model boven op een robuuste berichtinfrastructuur. Berichten worden betrouwbaar opgeslagen in een broker (de wachtrij) totdat ze zijn ontvangen door de consument. De wachtrij garandeert de bezorging van FIFO-berichten (First-In/First-Out), met inachtneming van de volgorde waarin berichten aan de wachtrij zijn toegevoegd.
De grootte van een bericht kan veel groter zijn, tot 256 kB. Berichten blijven gedurende een onbeperkte periode in de wachtrij staan. Service Bus ondersteunt niet alleen HTTP-aanroepen, maar biedt ook volledige ondersteuning voor het AMQP-protocol. AMQP is een open-standaard voor leveranciers die ondersteuning bieden voor een binair protocol en hogere mate van betrouwbaarheid.
Service Bus biedt een uitgebreide set functies, waaronder transactieondersteuning en een functie voor dubbele detectie. De wachtrij garandeert 'maximaal één keer bezorgen' per bericht. Er wordt automatisch een bericht verwijderd dat al is verzonden. Als een producent twijfelt, kan het hetzelfde bericht opnieuw verzenden en garandeert Service Bus dat slechts één exemplaar wordt verwerkt. Dubbele detectie zorgt ervoor dat u geen extra infrastructuurinstallatie hoeft te bouwen.
Nog twee bedrijfsfuncties zijn partitionering en sessies. Een conventionele Service Bus-wachtrij wordt verwerkt door één berichtenbroker en opgeslagen in één berichtenarchief. Service Bus Partitioning verspreidt echter de wachtrij over meerdere berichtenbrokers en berichtenarchieven. De totale doorvoer wordt niet langer beperkt door de prestaties van één berichtenbroker of berichtenarchief. Een tijdelijke onderbreking van een berichtenarchief geeft geen gepartitioneerde wachtrij niet beschikbaar.
Service Bus-sessies bieden een manier om berichten te groeperen. Stel u een werkstroomscenario voor waarin berichten samen moeten worden verwerkt en de bewerking aan het einde moet worden voltooid. Als u wilt profiteren, moeten sessies expliciet worden ingeschakeld voor de wachtrij en moet elk gerelateerd bericht dezelfde sessie-id bevatten.
Er zijn echter enkele belangrijke opmerkingen: De grootte van Service Bus-wachtrijen is beperkt tot 80 GB, wat veel kleiner is dan wat er beschikbaar is in winkelwachtrijen. Daarnaast worden voor Service Bus-wachtrijen basiskosten en kosten per bewerking in rekening gebracht.
Afbeelding 4-14 geeft een overzicht van de architectuur op hoog niveau van een Service Bus-wachtrij.
Afbeelding 4-14. Service Bus-wachtrij
Noteer in de vorige afbeelding de punt-naar-punt-relatie. Twee exemplaren van dezelfde provider voeren berichten uit in één Service Bus-wachtrij. Elk bericht wordt gebruikt door slechts één van de drie consumentenexemplaren aan de rechterkant. Vervolgens bespreken we hoe we berichten implementeren waarbij verschillende consumenten mogelijk allemaal hetzelfde bericht interesseren.
gebeurtenis
Berichtenwachtrijen is een effectieve manier om communicatie te implementeren waarbij een producent asynchroon een bericht kan verzenden naar een consument. Wat gebeurt er echter wanneer veel verschillende consumenten geïnteresseerd zijn in hetzelfde bericht? Een speciale berichtenwachtrij voor elke consument zou niet goed worden geschaald en zou moeilijk te beheren zijn.
Om dit scenario aan te pakken, gaan we naar het derde type berichtinteractie, de gebeurtenis. Eén microservice kondigt aan dat er een actie is opgetreden. Andere microservices, indien geïnteresseerd, reageren op de actie of gebeurtenis. Dit wordt ook wel de gebeurtenisgestuurde architectuurstijl genoemd.
Eventing is een proces in twee stappen. Voor een bepaalde statuswijziging publiceert een microservice een gebeurtenis naar een berichtenbroker, zodat deze beschikbaar is voor elke andere geïnteresseerde microservice. De geïnteresseerde microservice wordt op de hoogte gesteld door u te abonneren op de gebeurtenis in de berichtenbroker. U gebruikt het patroon Publiceren/Abonneren om communicatie op basis van gebeurtenissen te implementeren.
In afbeelding 4-15 ziet u een microservice voor winkelwagens waarin een gebeurtenis wordt gepubliceerd met twee andere microservices die zich hierop abonneren.
Afbeelding 4-15. Gebeurtenisgestuurde berichten
Let op het event bus-onderdeel dat zich midden in het communicatiekanaal bevindt. Het is een aangepaste klasse die de berichtbroker inkapselt en loskoppelt van de onderliggende toepassing. De bestellen en inventaris microservices bedienen het evenement onafhankelijk zonder kennis van elkaar, noch de microservice voor winkelwagens. Wanneer de geregistreerde gebeurtenis wordt gepubliceerd naar de gebeurtenisbus, handelen ze hierop.
Met eventing gaan we van wachtrijtechnologie naar onderwerpen. Een onderwerp is vergelijkbaar met een wachtrij, maar ondersteunt een een-op-veel-berichtenpatroon. Eén microservice publiceert een bericht. Meerdere abonnerende microservices kunnen ervoor kiezen om dat bericht te ontvangen en erop te reageren. Afbeelding 4-16 toont een onderwerparchitectuur.
Afbeelding 4-16. Onderwerparchitectuur
In de vorige afbeelding verzenden uitgevers berichten naar het onderwerp. Aan het einde ontvangen abonnees berichten van abonnementen. In het midden stuurt het onderwerp berichten door naar abonnementen op basis van een set regels, weergegeven in donkerblauwe vakken. Regels fungeren als een filter waarmee specifieke berichten worden doorgestuurd naar een abonnement. Hier wordt een 'GetPrice'-gebeurtenis verzonden naar de prijs- en logboekregistratieabonnementen, omdat het logboekregistratieabonnement ervoor heeft gekozen om alle berichten te ontvangen. Er wordt een 'GetInformation'-gebeurtenis verzonden naar de informatie en logboekregistratieabonnementen.
De Azure-cloud ondersteunt twee verschillende onderwerpservices: Azure Service Bus-onderwerpen en Azure EventGrid.
Azure Service Bus-onderwerpen
Het zit bovenop hetzelfde robuuste brokered berichtmodel van Azure Service Bus-wachtrijen zijn Azure Service Bus-onderwerpen. Een onderwerp kan berichten ontvangen van meerdere onafhankelijke uitgevers en berichten verzenden naar maximaal 2000 abonnees. Abonnementen kunnen dynamisch worden toegevoegd of verwijderd tijdens runtime zonder het systeem te stoppen of het onderwerp opnieuw te maken.
Veel geavanceerde functies van Azure Service Bus-wachtrijen zijn ook beschikbaar voor onderwerpen, waaronder ondersteuning voor dubbele detectie en transactie. Service Bus-onderwerpen worden standaard verwerkt door één berichtenbroker en opgeslagen in één berichtenarchief. Service Bus Partitioning schaalt echter een onderwerp door het te verspreiden over veel berichtbrokers en berichtenarchieven.
Geplande berichtbezorging tagt een bericht met een specifieke tijd voor verwerking. Het bericht wordt vóór die tijd niet weergegeven in het onderwerp. Met berichtuitstel kunt u het ophalen van een bericht naar een later tijdstip uitstellen. Beide worden vaak gebruikt in werkstroomverwerkingsscenario's waarbij bewerkingen in een bepaalde volgorde worden verwerkt. U kunt de verwerking van ontvangen berichten uitstellen totdat het eerdere werk is voltooid.
Service Bus-onderwerpen zijn een robuuste en bewezen technologie voor het inschakelen van communicatie over publiceren/abonneren in uw cloudsystemen.
Azure Event Grid
Hoewel Azure Service Bus een bestreden berichtenbroker is met een volledige set bedrijfsfuncties, is Azure Event Grid de nieuwe jongen op het blok.
Op het eerste gezicht kan Event Grid eruitzien als een ander berichtensysteem op basis van een onderwerp. Het is echter op veel manieren anders. Gericht op gebeurtenisgestuurde workloads, maakt het realtime gebeurtenisverwerking, diepe Azure-integratie en een open-platform mogelijk, allemaal op serverloze infrastructuur. Het is ontworpen voor moderne cloudeigen en serverloze toepassingen
Event Grid reageert als gecentraliseerd backplane of pijpgebeurtenisvlak op gebeurtenissen in Azure-resources en vanuit uw eigen services.
Gebeurtenismeldingen worden gepubliceerd naar een Event Grid-onderwerp, dat op zijn beurt elke gebeurtenis doorstuurt naar een abonnement. Abonnees worden toegewezen aan abonnementen en gebruiken de gebeurtenissen. Net als Service Bus ondersteunt Event Grid een gefilterd abonneemodel waarbij een abonnementsregel instelt voor de gebeurtenissen die het wil ontvangen. Event Grid biedt een snelle doorvoer met een garantie van 10 miljoen gebeurtenissen per seconde die bijna realtime levering mogelijk maken, veel meer dan wat Azure Service Bus kan genereren.
Een zoete plek voor Event Grid is de diepe integratie in de infrastructuur van De Azure-infrastructuur. Een Azure-resource, zoals Cosmos DB, kan ingebouwde gebeurtenissen rechtstreeks publiceren naar andere geïnteresseerde Azure-resources, zonder dat hiervoor aangepaste code nodig is. Event Grid kan gebeurtenissen publiceren vanuit een Azure-abonnement, resourcegroep of service, zodat ontwikkelaars nauwkeurige controle hebben over de levenscyclus van cloudresources. Event Grid is echter niet beperkt tot Azure. Het is een open platform dat aangepaste HTTP-gebeurtenissen kan gebruiken die zijn gepubliceerd vanuit toepassingen of services van derden en gebeurtenissen naar externe abonnees kan routeren.
Bij het publiceren en abonneren op systeemeigen gebeurtenissen van Azure-resources is geen codering vereist. Met eenvoudige configuratie kunt u gebeurtenissen van de ene Azure-resource integreren naar een andere met behulp van ingebouwde sanitair voor onderwerpen en abonnementen. Afbeelding 4-17 toont de anatomie van Event Grid.
Afbeelding 4-17. Anatomie van Event Grid
Een belangrijk verschil tussen EventGrid en Service Bus is het onderliggende patroon voor het uitwisselen van berichten.
Service Bus implementeert een ouder pull-model in stijl waarin de downstreamabonnee het onderwerpabonnement actief pollt voor nieuwe berichten. Aan de kant geeft deze benadering de abonnee volledige controle over het tempo waarmee berichten worden verwerkt. Hiermee bepaalt u wanneer en hoeveel berichten op een bepaald moment moeten worden verwerkt. Ongelezen berichten blijven in het abonnement staan totdat ze zijn verwerkt. Een aanzienlijke shortcoming is de latentie tussen het moment waarop de gebeurtenis wordt gegenereerd en de polling-bewerking die dat bericht naar de abonnee haalt voor verwerking. Bovendien verbruikt de overhead van constante polling voor de volgende gebeurtenis resources en geld.
EventGrid is echter anders. Het implementeert een pushmodel waarin gebeurtenissen naar de EventHandlers worden verzonden als ontvangen, wat bijna realtime levering van gebeurtenissen geeft. Het vermindert ook de kosten omdat de service alleen wordt geactiveerd wanneer deze nodig is om een gebeurtenis te gebruiken, niet voortdurend zoals bij polling. Dat gezegd hebbende, moet een gebeurtenis-handler de binnenkomende belasting afhandelen en beperkingsmechanismen bieden om zichzelf te beschermen tegen overweldiging. Veel Azure-services die deze gebeurtenissen gebruiken, zoals Azure Functions en Logic Apps, bieden automatische schaalaanpassingsmogelijkheden voor het afhandelen van verhoogde belastingen.
Event Grid is een volledig beheerde serverloze cloudservice. Het schaalt dynamisch op basis van uw verkeer en brengt alleen kosten in rekening voor uw werkelijke gebruik, niet vooraf aangeschafte capaciteit. De eerste 100.000 bewerkingen per maand zijn gratis: bewerkingen die worden gedefinieerd als inkomend gebeurtenissen (binnenkomende gebeurtenismeldingen), abonnementsbezorgingspogingen, beheeroproepen en filteren op onderwerp. Met een beschikbaarheid van 99,99% garandeert EventGrid de levering van een gebeurtenis binnen een periode van 24 uur, met ingebouwde functionaliteit voor opnieuw proberen voor mislukte levering. Niet-bezorgde berichten kunnen worden verplaatst naar een wachtrij met 'dode letters' voor oplossing. In tegenstelling tot Azure Service Bus is Event Grid afgestemd op snelle prestaties en biedt geen ondersteuning voor functies zoals geordende berichten, transacties en sessies.
Streamingberichten in de Azure-cloud
Azure Service Bus en Event Grid bieden uitstekende ondersteuning voor toepassingen die afzonderlijke, discrete gebeurtenissen beschikbaar maken, zoals een nieuw document, zijn ingevoegd in een Cosmos DB. Maar wat gebeurt er als uw cloudeigen systeem een stroom gerelateerde gebeurtenissen moet verwerken? Gebeurtenisstromen zijn complexer. Ze zijn doorgaans geordend, onderling gerelateerd en moeten als groep worden verwerkt.
Azure Event Hub is een platform voor gegevensstreaming en gebeurtenisopnameservice waarmee gebeurtenissen worden verzameld, getransformeerd en opgeslagen. Het is afgestemd op het vastleggen van streaminggegevens, zoals continue gebeurtenismeldingen die worden verzonden vanuit een telemetriecontext. De service is zeer schaalbaar en kan miljoenen gebeurtenissen per seconde opslaan en verwerken. Weergegeven in afbeelding 4-18, is het vaak een voordeur voor een gebeurtenispijplijn, waarbij de opnamestroom wordt ontkoppeld van gebeurtenisverbruik.
Afbeelding 4-18. Azure Event Hub
Event Hub ondersteunt lage latentie en configureerbare tijdretentie. In tegenstelling tot wachtrijen en onderwerpen, bewaren Event Hubs gebeurtenisgegevens nadat deze zijn gelezen door een consument. Met deze functie kunnen andere gegevensanalyseservices, zowel intern als extern, de gegevens opnieuw afspelen voor verdere analyse. Gebeurtenissen die zijn opgeslagen in Event Hub, worden alleen verwijderd na het verstrijken van de bewaarperiode, wat standaard één dag is, maar kan worden geconfigureerd.
Event Hub ondersteunt algemene protocollen voor het publiceren van gebeurtenissen, waaronder HTTPS en AMQP. Het ondersteunt ook Kafka 1.0. Bestaande Kafka-toepassingen kunnen communiceren met Event Hub met behulp van het Kafka-protocol en bieden een alternatief voor het beheren van grote Kafka-clusters. Veel opensource-cloudsystemen omarmen Kafka.
Event Hubs implementeert berichtstreaming via een gepartitioneerd consumentenmodel waarin elke consument alleen een specifieke subset of partitie van de berichtenstroom leest. Dit patroon maakt enorme horizontale schaal mogelijk voor gebeurtenisverwerking en biedt andere streamgerichte functies die niet beschikbaar zijn in wachtrijen en onderwerpen. Een partitie is een geordende reeks gebeurtenissen die in een Event Hub wordt bewaard. Als er nieuwere gebeurtenissen plaatsvinden, worden deze toegevoegd aan het einde van deze reeks. Afbeelding 4-19 toont partitionering in een Event Hub.
Afbeelding 4-19. Event Hub partitioneren
In plaats van uit dezelfde resource te lezen, leest elke consumentengroep over een subset of partitie van de berichtenstroom.
Voor cloudtoepassingen die grote aantallen gebeurtenissen moeten streamen, kan Azure Event Hub een robuuste en betaalbare oplossing zijn.
