Wat is Azure Service Bus?

Azure Service Bus is een volledig beheerde berichtenbroker voor ondernemingen met berichtenwachtrijen en onderwerpen voor publiceren/abonneren (in een naamruimte). Service Bus wordt gebruikt om toepassingen en services van elkaar los te koppelen, waardoor de volgende voordelen worden geboden:

  • Taakverdeling tussen concurrerende werkrollen
  • Veilig routeren en overdragen van gegevens en controle over de grenzen van services en toepassingen heen
  • Transactionele werkzaamheden coördineren waarvoor een hoge mate van betrouwbaarheid vereist is

Notitie

Zie Kiezen tussen Azure-berichtenservices - Event Grid, Event Hubs en Service Bus voor een vergelijking van Azure-berichtenservices.

Overzicht

Gegevens worden uitgewisseld tussen verschillende toepassingen en services met behulp van berichten. Een bericht is een container die is voorzien van metagegevens en gegevens bevat. De gegevens kunnen elk soort informatie zijn, inclusief gestructureerde gegevens die zijn gecodeerd in algemene indelingen, zoals de volgende: JSON, XML, Apache Avro, tekst zonder opmaak.

Enkele algemene berichtenscenario's:

  • Berichtenuitwisseling. Draag bedrijfsgegevens over, zoals verkoop- of inkooporders, dagboeken of voorraadverplaatsingen.

  • Toepassingen loskoppelen. Verbeter de betrouwbaarheid en schaalbaarheid van toepassingen en services. Producent en consument hoeven niet tegelijkertijd online of onmiddellijk beschikbaar te zijn. De belasting wordt verdeeld, zodat verkeerspieken een service niet overbelasten.

  • Taakverdeling. Meerdere concurrerende consumenten kunnen tegelijk lezen uit een wachtrij, waarbij elk veilig exclusief eigendom van specifieke berichten verkrijgt.

  • Onderwerpen en abonnementen. Schakel 1:n-relaties tussen uitgevers en abonnees in, zodat abonnees bepaalde berichten uit een stroom met gepubliceerde berichten kunnen selecteren.

  • Transacties. Hiermee kunt u verschillende bewerkingen uitvoeren, allemaal binnen het bereik van een atomische transactie. De volgende bewerkingen kunnen bijvoorbeeld worden uitgevoerd binnen het bereik van een transactie.

    1. Een bericht uit één wachtrij ophalen.
    2. Resultaten van verwerking naar een of meer verschillende wachtrijen verzenden.
    3. Het invoerbericht vanuit de oorspronkelijke wachtrij verplaatsen.

    Alleen bij geslaagde resultaten zijn deze zichtbaar voor downstreamconsumenten, inclusief de geslaagde afwikkeling van invoerberichten, waardoor er slechts één verwerking nodig is. Dit transactiemodel is een robuuste basis voor het patroon van compenserende transacties in de grotere oplossingscontext.

  • Berichtsessies. Implementeer een grootschalige coördinatie van werkstromen en gemultiplexte overdrachten waarvoor strikte berichtordening of berichtuitstel vereist is.

Als u bekend bent met andere berichtenbrokers zoals Apache ActiveMQ, zijn Service Bus-concepten vergelijkbaar met wat u al kent. Omdat Service Bus een PaaS-product (Platform-as-a-Service) is, is een belangrijk verschil dat u zich geen zorgen hoeft te maken over de volgende acties. Azure voert deze taken voor u uit.

  • Hardwarestoringen afhandelen
  • Patches toepassen op de besturingssystemen of de producten
  • Logboeken plaatsen en schijfruimte beheren
  • Back-ups afhandelen
  • Failover naar een reservecomputer uitvoeren

Concepten

In deze sectie worden basisconcepten van Service Bus.

Wachtrijen

Berichten worden verzonden naar en ontvangen van wachtrijen. Wachtrijen slaan berichten op totdat de ontvangende toepassing ze kan ontvangen en verwerken.

Wachtrij

Berichten in wachtrijen worden bij ontvangst geordend en voorzien van een tijdstempel. Als het bericht eenmaal door de broker is geaccepteerd, wordt het altijd opgeslagen in drievoudig-redundante opslag, verspreid over beschikbaarheidszones als de naamruimtezone is ingeschakeld. Service Bus houdt berichten nooit in het geheugen of vluchtige opslag nadat deze aan de client als geaccepteerd zijn gerapporteerd.

Berichten worden bezorgd in pull-modus, waarbij berichten alleen op aanvraag worden geleverd. In tegenstelling tot het busy-pollingmodel van sommige andere cloudwachtrijen, kan de pull-bewerking lang duren en pas worden voltooid als er een bericht beschikbaar is.

Notitie

Voor een vergelijking van Service Bus wachtrijen met Storage-wachtrijen, zie Storage queues and Service Bus queues - compared and contrasted.

Onderwerpen

U kunt ook onderwerpen gebruiken voor het verzenden en ontvangen van berichten. Daar waar een wachtrij vaak wordt gebruikt voor punt-naar-punt communicatie, zijn onderwerpen handig in scenario's met publiceren/abonneren.

Onderwerp

Onderwerpen kunnen meerdere, onafhankelijke abonnementen hebben, die aan het onderwerp worden gekoppeld en anders exact als wachtrijen van de ontvangerzijde werken. Een abonnee van een onderwerp kan een kopie ontvangen van elk bericht dat naar dat onderwerp wordt verzonden. Abonnementen worden entiteiten genoemd. Abonnementen duren standaard lang, maar kunnen worden geconfigureerd om te verlopen en vervolgens automatisch te worden verwijderd. Via de Java Message Service -API (JMS) kunt Service Bus Premium ook vluchtige abonnementen maken die bestaan voor de duur van de verbinding.

U kunt regels definiëren voor een abonnement. Een abonnementsregel bevat een filter om een voorwaarde te definiëren voor het bericht dat moet worden gekopieerd naar het abonnement en een optionele actie die metagegevens van berichten kan wijzigen. Zie Onderwerpfilters en acties voor meer informatie. Deze functie is handig in de volgende scenario's:

  • U wilt niet dat een abonnement alle berichten ontvangt die naar een onderwerp worden gestuurd.
  • U wilt berichten met extra metagegevens markeren wanneer deze via een abonnement worden doorgegeven.

Notitie

Zie wachtrijen, Service Bus, onderwerpen en abonnementen voor meer informatie over wachtrijen en onderwerpen.

Naamruimten

Een naamruimte is een container voor alle berichtenonderdelen (wachtrijen en onderwerpen). Er kunnen zich meerdere wachtrijen en onderwerpen in één naamruimte bevinden, en naamruimten fungeren vaak als toepassingscontainers.

Een naamruimte kan worden vergeleken met een server in de terminologie van andere brokers, maar de concepten zijn niet direct gelijkwaardig. Een Service Bus-naamruimte is uw eigen capaciteitssegment van een groot cluster dat uit tientallen allemaal actieve virtuele machines bestaat. Deze kan eventueel drie Azure-beschikbaarheidszones omvatten. Daarom krijgt u alle voordelen van beschikbaarheid en robuustheid van het uitvoeren van de berichtenbroker op een enorme schaal. En u hoeft zich geen zorgen te maken over de onderliggende complexiteiten. Service Bus is serverloze berichten.

Geavanceerde functies

Service Bus beschikt ook over geavanceerde functies waarmee u meer complexe problemen met berichtenuitwisseling kunt oplossen. In de volgende secties worden deze belangrijke functies in meer detail beschreven:

Berichtsessies

Als u er zeker van wilt zijn dat berichten in Service Bus op basis van FIFO (first-in, first-out) worden verwerkt, moet u sessies gebruiken. Berichtsessies maken gezamenlijke en geordende verwerking van niet-gebonden reeksen gerelateerde berichten mogelijk.

Automatisch doorsturen

De functie Automatisch doorsturen maakt het mogelijk om een wachtrij of abonnement te verbinden met andere wachtrijen of onderwerpen die deel uitmaken van dezelfde naamruimte. Wanneer automatisch doorsturen is ingeschakeld, worden berichten die in de eerste wachtrij of het eerste abonnement (bron) worden geplaatst, automatisch verwijdert en in de tweede wachtrij of het tweede onderwerp (doel) geplaatst.

Verwerking van onbestelbare berichten

Service Bus ondersteunt een wachtrij voor onbestelbare berichten (dead-letter queue of DLQ) voor het opslaan van berichten die niet bij een ontvanger kunnen worden bezorgd of berichten die niet kunnen worden verwerkt. U kunt berichten in deze wachtrij vervolgens verwijderen en controleren.

Geplande bezorging

U kunt berichten verzenden naar een wachtrij of onderwerp voor vertraagde verwerking. Als u bijvoorbeeld wilt plannen dat een taak op een bepaald moment beschikbaar komt voor verwerking door een systeem.

Berichten uitstellen

Wanneer een wachtrij of abonnementsclient een bericht ontvangt dat hij bereid is te verwerken, maar waarvoor verwerking momenteel niet mogelijk is vanwege speciale omstandigheden binnen de toepassing, kan de entiteit het ophalen van het bericht uitstellen naar een later punt. Het bericht blijft in de wachtrij of het abonnement staan, maar wordt nog niet verwerkt.

Batchverwerking

Met batching aan de clientzijde kan een wachtrij of onderwerpclient het verzenden van een bericht voor een bepaalde periode vertragen. Als de client gedurende deze periode meer berichten verzendt, worden de berichten in één batch verzonden.

Transacties

Een transactie groept twee of meer bewerkingen samen in een uitvoeringsbereik. Service Bus biedt ondersteuning voor het groeperen van bewerkingen voor één berichtentiteit (wachtrij, onderwerp of abonnement) binnen het bereik van een transactie.

Filteren en acties

Abonnees kunnen definiëren welke berichten ze willen ontvangen van een onderwerp. Deze berichten worden opgegeven in de vorm van een of meer benoemde abonnementsregels. Voor elke regelvoorwaarde waaraan wordt voldaan, produceert het abonnement een kopie van het bericht, dat anders voor elke overeenkomende regel anders kan worden geannoteerd.

Automatische verwijderen bij inactiviteit

Automatische verwijderen bij inactiviteit houdt in dat u een interval voor inactiviteit kunt opgeven waarna de wachtrij automatisch wordt verwijderd. De minimale duur is vijf minuten.

Detectie van duplicaten

Als er een fout optreedt waardoor de client twijfelt over het resultaat van een verzendbewerking, neemt duplicaatdetectie de twijfel weg uit deze situaties door de afzender in staat te stellen hetzelfde bericht opnieuw te verzenden en worden eventuele dubbele kopieën verwijderd uit de wachtrij of het onderwerp.

Shared Access Signature (SAS), op rollen gebaseerd toegangsbeheer en beheerde identiteiten

Service Bus biedt ondersteuning voor beveiligingsprotocollen zoals SAS (Shared Access Signatures), RBAC (op rollen gebaseerd toegangsbeheer) en MSI (Managed Service Identity) voor Azure-resources.

Geo-noodherstel

Wanneer azure-regio's of -datacenters te maken hebben met uitvaltijd, zorgt geo-noodherstel ervoor dat gegevensverwerking in een andere regio of een ander datacenter kan blijven werken.

Beveiliging

Service Bus ondersteunt standaard Advanced Message Queueing Protocol (AMQP) 1.0- en HTTP/REST-protocollen.

Notitie

Zie Geavanceerde functies van Azure Service Bus voor meer informatie over Service Bus.

Naleving van standaarden en protocollen

Het primaire wire-protocol voor Service Bus is Advanced Messaging Queueing Protocol (AMQP) 1.0, een open ISO/IEC-standaard. Hiermee kunnen klanten toepassingen schrijven die werken met Service Bus en on-premises brokers, zoals ActiveMQ of RabbitMQ. De AMQP-protocolhandleiding bevat gedetailleerde informatie voor het geval u een dergelijke abstractie wilt maken.

Service Bus Premium is volledig compatibel met de API van Java/Jakarta EE Java Message Service (JMS) 2.0. En Service Bus Standard biedt ondersteuning voor de JMS 1.1-subset die op wachtrijen gericht is. JMS is een algemene abstractie voor berichtenbrokers en kan worden geïntegreerd met veel toepassingen en frameworks, waaronder het populaire Spring-framework. Als u van een andere broker wilt overschakelen naar Azure Service Bus, hoeft u alleen de topologie van wachtrijen en onderwerpen opnieuw te maken en de afhankelijkheden en configuratie van de clientprovider te wijzigen. Zie de ActiveMQ-migratiehandleiding voor een voorbeeld.

Clientbibliotheken

Volledig ondersteunde Service Bus-clientbibliotheken zijn beschikbaar via de Azure SDK.

Het primaire protocol van Azure Service Bus is AMQP 1.0 en kan worden gebruikt vanuit elke client die compatibel is met het AMQP 1.0-protocol. Verschillende open source AMQP-clients bevatten voorbeelden die expliciet interoperabiliteit met Service Bus illustreren. Lees de AMQP 1.0-protocolhandleiding voor meer informatie over het rechtstreeks gebruiken van Service Bus functies met AMQP 1.0-clients.

Taal Bibliotheek
Java Apache Qpid Proton-J
C/C++ Azure UAMQP C, Apache Qpid Proton-C
Python Azure uAMQP voor python, Apache Qpid Proton python
PHP Azure-uAMQP voor PHP
Ruby Apache Qpid Proton ruby
Go Azure go AMQP, Apache Qpid Proton go
C#/F #/VB AMQP .net Lite, Apache NMS AMQP
Java script/knoop punt Rhea

Integratie

Service Bus is volledig geïntegreerd met veel Microsoft- en Azure-services, bijvoorbeeld:

Volgende stappen

Zie de volgende artikelen om aan de slag te gaan met de Service Bus-berichtenservice: