Vad är Azure Service Bus?

Azure Service Bus är en fullständigt hanterad meddelandekö för företag med meddelandeköer och publicera/prenumerera-ämnen (i ett namnområde). Service Bus används för att frikoppla program och tjänster från varandra, vilket ger följande fördelar:

  • Belastningsutjämningsarbete för konkurrerande arbetare
  • Routning och överföring av data och kontroll över tjänst- och programgränser på ett säkert sätt
  • Samordna transaktionsarbete som kräver hög tillförlitlighet

Anteckning

En jämförelse av Azures meddelandetjänster finns i Välja mellan Azure-meddelandetjänster – Event Grid, Event Hubs och Service Bus.

Översikt

Data överförs mellan olika program och tjänster med meddelanden. Ett meddelande är en container som är uppsmyckad med metadata och som innehåller data. Data kan vara vilken typ av information som helst, inklusive strukturerade data som kodats med vanliga format, till exempel följande: JSON, XML, Apache Avro, oformaterad text.

Några vanliga scenarier för meddelanden är:

  • Meddelanden. Överföra affärsdata, till exempel försäljning eller inköpsorder, journaler eller lagerförflyttningar.

  • Frikoppla program. Förbättra tillförlitligheten och skalbarheten för program och tjänster. Producent och konsument behöver inte vara online eller lättillgänglig samtidigt. Belastningen utjämnas så att trafiktoppar inte överbelastar en tjänst.

  • Belastningsutjämning. Gör det möjligt för flera konkurrerande konsumenter att läsa från en kö samtidigt, där var och en på ett säkert sätt får exklusiv ägarskap till specifika meddelanden.

  • Ämnen och prenumerationer. Aktivera 1:n relationer mellan utgivare och prenumeranter,så att prenumeranter kan välja specifika meddelanden från en publicerad meddelandeström.

  • Transaktioner. Gör att du kan göra flera åtgärder, allt inom omfånget för en atomisk transaktion. Följande åtgärder kan till exempel utföras i omfånget för en transaktion.

    1. Hämta ett meddelande från en kö.
    2. Publicera resultatet av bearbetningen till en eller flera olika köer.
    3. Flytta indatameddelandet från den ursprungliga kön.

    Resultaten blir bara synliga för nedströmskonsumenter när de lyckas, inklusive en lyckad lösning av indatameddelanden, vilket möjliggör en enda bearbetningssemantik. Den här transaktionsmodellen är en robust grund för mönstret för kompenserande transaktioner i den större lösningskontexten.

  • Meddelandesessioner. Implementera storskalig samordning av arbetsflöden och multiplexerade överföringar som kräver strikt meddelandeordning eller upp skjuta upp meddelanden.

Om du är bekant med andra a brokers för meddelanden som Apache ActiveMQ Service Bus begrepp liknar det du vet. Eftersom Service Bus är ett PaaS-erbjudande (plattform som en tjänst) är en viktig skillnad att du inte behöver bekymra dig om följande åtgärder. Azure tar hand om dessa sysslor åt dig.

  • Oroa dig för maskinvarufel
  • Hålla operativsystemen eller produkterna korrigerade
  • Placera loggar och hantera diskutrymme
  • Hantera säkerhetskopior
  • Vid fel till en reservdator

Begrepp

I det här avsnittet beskrivs grundläggande Service Bus.

Köer

Meddelanden skickas till och tas emot från köer. Köer lagrar meddelanden tills det mottagande programmet är tillgängligt för att ta emot och bearbeta dem.

Kö

Meddelanden i köer sorteras och tidsstämplas vid ankomst. När det har godkänts av den a broker hålls meddelandet alltid durably i trippelredundant lagring, fördelat över tillgänglighetszoner om namnområdet är zonaktiverad. Service Bus lämnar aldrig meddelanden i minnet eller beständig lagring när de har rapporterats till klienten som godkända.

Meddelanden levereras i pull-läge och levererar endast meddelanden när det begärs. Till skillnad från modellen för upptagen avsökning i vissa andra molnköer kan pull-åtgärden vara långlivad och bara slutföras när ett meddelande är tillgängligt.

Anteckning

En jämförelse av Service Bus med Storage finns i Storage och andra Service Bus köer – jämförd och kontrasterad.

Ämnen

Du kan också använda ämnen för att skicka och ta emot meddelanden. Medan en kö oftast används för kommunikation från punkt till punkt är ämnen användbara i scenarier med publicering/prenumeration.

Avsnitt

Ämnen kan ha flera oberoende prenumerationer, som bifogas till ämnet och fungerar på annat sätt precis som köer från mottagarsidan. En prenumerant på ett ämne får en kopia av varje meddelande. Prenumerationer är namngivna entiteter. Prenumerationer är beständiga som standard, men kan konfigureras att upphöra att gälla och sedan tas bort automatiskt. Via JMS-API:et (Java Message Service) Service Bus Premium du också skapa beständiga prenumerationer som finns under anslutningens varaktighet.

Du kan definiera regler för en prenumeration. En prenumerationsregel har ett filter för att definiera ett villkor för meddelandet som ska kopieras till prenumerationen och en valfri åtgärd som kan ändra meddelandets metadata. Mer information finns i Ämnesfilter och åtgärder. Den här funktionen är användbar i följande scenarier:

  • Du vill inte att en prenumeration ska ta emot alla meddelanden som skickas till ett ämne.
  • Du vill markera meddelanden med extra metadata när de passerar genom en prenumeration.

Anteckning

Mer information om köer och ämnen finns i Service Bus, ämnen och prenumerationer.

Namnrymder

Ett namnområde är en container för alla meddelandekomponenter (köer och ämnen). Flera köer och ämnen kan finnas i ett enda namnområde, och namnområden fungerar ofta som programcontainrar.

Ett namnområde kan jämföras med en server i terminologin för andra a brokers, men begreppen är inte direkt likvärdiga. En Service Bus namnrymd är din egen kapacitetssegment i ett stort kluster som består av dussintals alla aktiva virtuella datorer. Den kan även omfatta tre Azure-tillgänglighetszoner. Därför får du alla fördelar med tillgänglighet och robusthet när du kör meddelandeutjämning i enorm skala. Och du behöver inte bekymra dig om underliggande komplexitet. Service Bus är serverlösa meddelanden.

Avancerade funktioner

Service Bus har också avancerade funktioner som hjälper dig att lösa problem med mer komplexa meddelanden. I följande avsnitt beskrivs dessa nyckelfunktioner:

Meddelandesessioner

Använda sessioner för att använda en först in-, först ut-garanti (FIFO) i Service Bus. Meddelandesessioner aktiverar gemensamma och organiserad hantering av frigjorda sekvenser av relaterade meddelanden.

Automatisk vidarebefordring

Med funktionen automatisk vidarebefordring kan du koppla en kö eller en prenumeration på en annan kö eller ett ämne som ingår i samma namnområde. När automatisk vidarebefordring är aktiverat tar Service Bus automatiskt bort meddelanden som har placerats i den första kön eller prenumerationen (källan) och placerar dem i den andra kön eller ämnet (målet).

Olevererade brev

Service Bus stöder en kö med olevererade brev (DQL) för meddelanden som inte kan levereras till alla mottagare eller meddelanden som inte kan bearbetas. Du kan ta bort meddelanden från DQL och inspektera dem.

Schemalagd leverans

Du kan skicka meddelanden till en kö eller ett ämne för fördröjd bearbetning. Till exempel för att schemalägga ett jobb så att det blir tillgängligt för bearbetning av ett system vid en viss tidpunkt.

Skjut upp meddelanden

När en kö- eller prenumerationsklient tar emot ett meddelande som den är villig att bearbeta, men för vilken bearbetning för närvarande inte är möjligt på grund av särskilda omständigheter i programmet, kan entiteten skjuta upp hämtningen av meddelandet till en senare tidpunkt. Meddelandet finns kvar i kön eller prenumerationen, men det är reserverat.

Batchbearbetning

Med klientsidans batchbearbetning förhindras en kö- eller ämnesklient från att skicka ett meddelande under en viss tidsperiod. Om klienten skickar fler meddelanden under den här tidsperioden överförs meddelandena i en enda batch.

Transaktioner

En transaktion grupperar två eller flera åtgärder tillsammans i en körning. Service Bus stöder grupperingsåtgärder mot en enskild meddelandeenhet (kö, ämne, prenumeration) inom en transaktion.

Filtrering och åtgärder

Prenumeranter kan definiera vilka meddelanden som de vill ta emot från ett ämne. Dessa meddelanden anges i form av en eller flera namngivna prenumerationsregler. Prenumerationen skapar en kopia av meddelandet som får kommenteras på olika sätt för varje matchande regel för varje matchande regelvillkor.

Automatisk borttagning vid inaktivitet

Med automatisk borttagning vid inaktivitet kan du ange ett intervall för inaktivitet varefter kön tas bort automatiskt. Minimilängden är 5 minuter.

Dubblettidentifiering

Om ett fel inträffar som gör att klienten är osäker på resultatet av en skicka-åtgärd, tar dubblettidentifiering bort denna situation genom att göra så att avsändaren kan skicka samma meddelande igen, och kön eller ämnet tar bort eventuella dubblettkopior.

Signatur för delad åtkomst (SAS), rollbaserad åtkomstkontroll och hanterade identiteter

Service Bus stöder säkerhetsprotokoll som signaturer för delad åtkomst (SAS), rollbaserad åtkomstkontroll (RBAC) och hanterade identiteter för Azure-resurser.

Geohaveriberedskap

När Azure-regioner eller datacenter drabbas av driftstopp låter geohaveriberedskap databearbetningen fortsätta i en annan region eller datacenter.

Säkerhet

Service Bus stöder standardprotokollen Advanced Message Queueing Protocol (AMQP) 1.0 och HTTP/REST.

Anteckning

Mer information om dessa funktioner finns i Avancerade funktioner i Azure Service Bus.

Efterlevnad av standarder och protokoll

Det primära trådprotokollet för Service Bus är AMQP (Advanced Messaging Queueing Protocol) 1.0, en öppen ISO/IEC-standard. Det gör att kunder kan skriva program som fungerar Service Bus lokala a brokers som ActiveMQ eller RabbitMQ. AMQP-protokollguiden innehåller detaljerad information om du vill skapa en sådan abstraktion.

Service Bus Premium är helt kompatibel med JAVA/Jakarta EE JAVA Message Service (JMS) 2.0 API. Och Service Bus Standard har stöd för JMS 1.1-delmängden som fokuserar på köer. JMS är en vanlig abstraktion för meddelandeköer och integreras med många program och ramverk, inklusive det populära Spring-ramverket. Om du vill växla från andra a brokers till Azure Service Bus behöver du bara återskapa topologin för köer och ämnen och ändra klientproviderns beroenden och konfiguration. Ett exempel finns i migreringsguiden för ActiveMQ.

Klientbibliotek

Klientbibliotek Service Bus stöds fullt ut via Azure SDK.

Azure Service Bus primära protokoll är AMQP 1.0 och kan användas från valfri AMQP 1.0-kompatibel protokollklient. Flera AMQP-klienter med öppen källkod har exempel som uttryckligen visar Service Bus samverkan. Läs protokollguiden för AMQP 1.0 för att förstå hur du använder Service Bus med AMQP 1.0-klienter direkt.

Språk Bibliotek
Java Apache qpid Proton-J
C/C++ Azure UAMQP C, Apache qpid Proton-C
Python Azure-uAMQP för python, Apache qpid Proton python
PHP Azure-uAMQP för 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/Node Rhea

Integrering

Service Bus integreras helt med många Microsoft- och Azure-tjänster, till exempel:

Nästa steg

Om du vill komma igång med Service Bus-meddelanden, kan du läsa följande artiklar: