Vad är Azure Service Bus?

Azure Service Bus är en fullständigt hanterad meddelandekö för företag med meddelandeköer och publiceringsprenumeranter. Service Bus används för att frikoppla program och tjänster från varandra, vilket ger följande fördelar:

  • Belastningsutjämningsarbete mellan konkurrerande arbetare
  • Valv dirigering 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:

  • Meddelandetjänster. Överföra 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 överbeskattar en tjänst.

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

  • Ä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 den större lösningskontexten.

  • Meddelandesessioner. Implementera storskalig samordning av arbetsflöden och multiplexerade ö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 de här sysslorna åt dig.

  • Oroa dig för maskinvarufel
  • 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.

Diagram that shows a Service Bus queue with a sender and a receiver sending and receiving messages.

Meddelanden i köer ordnas och tidsstämplas vid ankomst. När asynkron meddelandekö har godkänts lagras meddelandet alltid i trippelredundant lagring, fördelat över tillgänglighetszoner om namnområdet är zonaktiverat. Service Bus behåller meddelanden i minne eller flyktig lagring tills klienten rapporterar dem som godkända.

Meddelanden levereras i pull-läge och levererar bara 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.

Kommentar

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. En kö används ofta för punkt-till-punkt-kommunikation, men ämnen är användbara i scenarier med publicering och prenumeration.

Diagram that shows a Service Bus topic with one sender and multiple receivers.

Ämnen kan ha flera oberoende prenumerationer som ansluter till ämnet och i övrigt fungerar precis 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 flyktiga 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 att meddelandet 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 skickas via en prenumeration.

Kommentar

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). Ett namnområde kan ha en eller flera köer och ämnen och fungerar ofta som en programcontainer.

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 omfattar även tre Azure-tillgänglighetszoner. Så du får alla fördelar med tillgänglighet och robusthet för att köra meddelandeköer 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änd sessioner för att förverkliga en första-i-först-ut-garanti (FIFO) för att bearbeta meddelanden i Service Bus-köer eller prenumerationer. 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 ett sätt för mottagaren 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 vidarebefordran

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. 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. 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 tidpunkt. Meddelandet finns kvar i kön eller prenumerationen, men det har lagts åt sidan. Mer information finns i Meddelandeförsening.

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. För varje matchande regelvillkor skapar prenumerationen en kopia av meddelandet, som kan kommenteras olika för varje matchande regel. 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 har några tvivel om resultatet av en sändningsåtgärd, tar duplicerad identifiering tvivel ur dessa situationer genom att göra det möjligt för avsändaren att skicka samma meddelande igen, och kön eller ämnet tar bort eventuella duplicerade kopior. Mer information finns i Dubblettidentifiering.

Säkerhet

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

Service Bus har stöd för AMQP-protokoll (Advanced Message Queuing Protocol) 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.

Kommentar

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 mäklare som 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 koordinatorer 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 är tillgängliga via Azure SDK.

Azure Service Bus primära protokoll ä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: