Vad är Azure Service Bus?

Azure Service Bus är en fullständigt hanterad meddelandekö för företag med meddelandeköer och publiceringsprenumeranter (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
  • Säkert routning och överföring av data och kontroll över tjänst- och programgränser
  • Samordna transaktionsarbete som kräver hög tillförlitlighet

Anteckning

En jämförelse av Azure-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 dekorerad med metadata och innehåller data. Data kan vara alla typer av information, inklusive strukturerade data som kodas med vanliga format, till exempel följande: JSON, XML, Apache Avro, oformaterad text.

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

  • Meddelanden. Överför affärsdata, till exempel försäljnings- 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ängliga på samma gång. Belastningen utjämnas så att trafiktoppar inte överbelastar en tjänst.

  • Belastningsutjämning. Tillåt flera konkurrerande konsumenter att läsa från en kö samtidigt, var och en får på ett säkert sätt exklusivt ägande till specifika meddelanden.

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

  • Transaktioner. Gör att du kan utfö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 synliga för nedströmskonsumenter endast när de lyckas, inklusive en lyckad lösning av indatameddelandet, vilket möjliggör bearbetning av semantik endast en gång. Den här transaktionsmodellen är en robust grund för det kompenserande transaktionsmönstret i en större lösningskontext.

  • Meddelandesessioner. Implementera storskalig samordning av arbetsflöden och multiplexade överföringar som kräver strikt meddelandeordning eller meddelandeuppsägning.

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

  • Oroa dig för maskinvarufel
  • Att hålla operativsystemen eller produkterna korrigerade
  • Placera loggar och hantera diskutrymme
  • Hantera säkerhetskopior
  • Växla över till en reservdator

Begrepp

I det här avsnittet beskrivs grundläggande begrepp för 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 meddelandet har godkänts av asynkron meddelandekö lagras det alltid i trippelredundant lagring, fördelat över tillgänglighetszoner om namnområdet är zonaktiverat. Service Bus lämnar aldrig meddelanden i minnet eller flyktig lagring efter att de har rapporterats till klienten som godkända.

Meddelanden levereras i pull-läge och levererar endast meddelanden när de begärs. Till skillnad från modellen med 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-köer med lagringsköer finns i Lagringsköer och Service Bus-köer – jämförda och kontrasterade.

Ä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 ansluter till ämnet och i övrigt fungerar exakt som köer från mottagarsidan. En prenumerant på ett ämne får en kopia av varje meddelande. Prenumerationer heter entiteter. Prenumerationer är varaktiga som standard, men kan konfigureras så att de upphör att gälla och tas sedan bort automatiskt. Via Java Message Service-API:et (JMS) kan du med Service Bus Premium även 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 meddelandemetadata. 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-köer, ä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 mäklare, men begreppen är inte direkt likvärdiga. Ett Service Bus-namnområde är din egen kapacitetssektor i ett stort kluster som består av dussintals helt aktiva virtuella datorer. Det kan också omfatta tre Azure-tillgänglighetszoner. Så du får alla fördelar med tillgänglighet och robusthet för att köra meddelandekoordinatorn i enorm skala. Och du behöver inte oroa dig för 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. Om du till exempel vill 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 får ett meddelande om att den är villig att bearbeta, men för vilken bearbetning för närvarande inte är möjlig 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.

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. Intervallet återställs när det finns trafik i kön. Minimilängden är 5 minuter.

Dubblettidentifiering

Om ett fel inträffar som gör att klienten har några tvivel om resultatet av en sändningsåtgärd, tar dubblettidentifieringen tvivel ur dessa situationer genom att låta avsändaren skicka samma meddelande igen och kön eller ämnet tar bort eventuella duplicerade kopior.

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 AMQP-protokoll (Advanced Message Queuing Protocol) 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 det möjligt för kunder att skriva program som fungerar mot Service Bus och lokala asynkrona mäklare, till exempel ActiveMQ eller RabbitMQ. AMQP-protokollguiden innehåller detaljerad information om du vill skapa en sådan abstraktion.

Service Bus Premium är helt kompatibelt med Java/Jakarta EE Java Message Service (JMS) 2.0 API. Och Service Bus Standard stöder JMS 1.1-delmängden med fokus 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 asynkrona meddelandeköer 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

Service Bus-klientbibliotek som stöds fullt ut är tillgängliga via Azure SDK.

Azure Service Bus primära protokollet är AMQP 1.0 och kan användas från alla AMQP 1.0-kompatibla protokollklienter. 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-funktioner 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
JavaScript/Node Rhea

Integrering

Service Bus integreras fullständigt 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: