Vad är Azure Service Bus?

  • Artikel

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

Ö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 asynkron meddelandekö har godkänts lagras meddelandet alltid i trippelredundant lagring, fördelat på tillgänglighetszoner om namnområdet är zonaktiverat. Service Bus behåller meddelanden i minnet eller flyktig lagring tills de har rapporterats av 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 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 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

Om du vill få en första-i-först-ut-garanti (FIFO) för bearbetning av meddelanden i Service Bus-kö eller prenumerationer använder du sessioner. Sessioner kan också användas för att implementera mönster för begärandesvar. Mönstret för begäran-svar gör det möjligt för avsändarprogrammet att skicka en begäran och ger mottagaren ett sätt att skicka ett svar tillbaka till avsändarprogrammet. Mer information finns i Meddelandesessioner

Automatisk vidarebefordring

Med funktionen Automatisk vidarebefordring kan du länka en kö eller prenumeration till en annan kö eller ett annat ä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). Mer information finns i Länka Service Bus-entiteter med automatisk vidarebefordring

Olevererade brev

Service Bus-köer och ämnesprenumerationer tillhandahåller en sekundär underfråga, kallad en kö med obeställbara meddelanden (DLQ). Kön med obeställbara meddelanden innehåller meddelanden som inte kan levereras till någon mottagare eller meddelanden som inte kan bearbetas. Du kan ta bort meddelanden från DQL och inspektera dem. Ett program kan med hjälp av en operatör korrigera problem och skicka meddelandet igen, logga det faktum att det uppstod ett fel och vidta en korrigerande åtgärd. Mer information finns i Översikt över Service Bus-köer med obeställbara meddelanden.

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. Mer information finns i Schemalagda meddelanden.

Skjut upp meddelanden

När en kö- eller prenumerationsklient får ett meddelande som 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 punkt. Meddelandet finns kvar i kön eller prenumerationen, men det sparas åt sidan. Mer information finns i Meddelandeuppskjutning.

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. Mer information finns i Översikt över Service Bus-transaktionsbearbetning.

Filter 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. Varje regel består av ett filtervillkor som väljer specifika meddelanden och som eventuellt innehåller en åtgärd som kommenterar det valda meddelandet. Prenumerationen skapar en kopia av meddelandet som får kommenteras på olika sätt för varje matchande regel för varje matchande regelvillkor. Mer information finns i Ämnesfilter och åtgärder.

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 uppstår som gör att klienten är osäker på resultatet av en sändningsåtgärd tar dubblettidentifieringen bort tvivel från dessa situationer genom att låta avsändaren skicka samma meddelande igen och kön eller ämnet tar bort eventuella dubbletter. Mer information finns i Dubblettidentifiering.

Säkerhet

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

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

Geohaveriberedskap

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

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 ADVANCED Messaging Queueing Protocol (AMQP) 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 meddelandeköer, 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 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 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 demonstrerar 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: