Dela via

Vad är Azure Service Bus?

Azure Service Bus är en fullständigt hanterad företagsmeddelandeförmedlare med meddelandeköer och publicera-prenumerera-ämnen. 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
  • 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

Overview

Data överförs mellan olika program och tjänster med hjälp av 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:

  • Messaging. Ö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.

  • Transactions. 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 meddelandeinmatningen från originalkö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 meddelandemäklare som Apache ActiveMQ, är Service Bus-koncepten liknande de du redan känner till. 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

Concepts

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

Queues

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 som visar en Service Bus-kö med en avsändare och en mottagare som skickar och tar emot meddelanden.

Meddelanden i köer ordnas och tidsstämplas vid ankomst. När mäklaren har godkänt meddelandet lagras meddelandet alltid stadigt i trippel-redundant förvaring, fördelat över tillgänglighetszoner om namnområdet är zonaktiverad. 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.

Note

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.

Topics

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 som visar ett Service Bus-ämne med en avsändare och flera mottagare.

Ämnen kan ha flera oberoende prenumerationer som ansluter till ämnet och fungerar i övrigt precis som köer från mottagarsidan. En prenumerant på ett ämne kan ta emot en kopia av varje meddelande som skickas till det ämnet. Prenumerationer är namngivna 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.

Note

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

Namespaces

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 av att köra meddelandebroker i enorm skala. Och du behöver inte oroa dig för underliggande komplexitet. Service Bus är en serverlös meddelandetjänst.

Avancerade funktioner

Service Bus har också avancerade funktioner som gör att du kan lösa mer komplexa meddelandeproblem. Följande avsnitt beskriver dessa viktiga funktioner:

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.

Auto-forwarding

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 vidarebefordran är aktiverad tar Service Bus automatiskt bort meddelanden som placeras i den första kön eller prenumerationen (källa) och placerar dem i den andra kön eller ämnet (målet). Mer information finns i Koppla samman Service Bus-entiteter med automatisk vidarebefordran

Dead-lettering

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 sedan ta bort meddelanden från DLQ 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. För mer information, se Översikt över Service Bus dödbrevköer.

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.

Transactions

En transaktion grupperar två eller flera åtgärder i en exekveringsram. Service Bus stöder grupperingsåtgärder mot en enda meddelandeentitet (kö, ämne, prenumeration) inom en transaktions omfång. 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 inaktivt intervall varefter kön tas bort automatiskt. Intervallet återställs när det finns trafik i kön. Den minsta varaktigheten ä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 dubbeldetektionssystemet tvivlen ur dessa situationer genom att göra det möjligt för avsändaren att skicka samma meddelande igen, och kön eller ämnet kasserar eventuella duplicerade kopior. Mer information finns i Dubblettidentifiering.

Massradering av meddelanden

Azure Service Bus stöder borttagning av meddelanden i batchar. Detta är användbart i scenarier när meddelanden i köer eller prenumerationer har upphört att gälla, eller inte längre är relevanta, vilket kräver en rensning. För mer information, se Partiell radering.

Security

Service Bus har stöd för säkerhetsprotokoll som Shared Access Signatures (SAS), rollbaserad åtkomstkontroll (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 .

Geo-Replication

När Azure-regioner eller datacenter upplever driftstopp kan geo-replikering göra det möjligt för databearbetning att fortsätta att fungera i en annan region.

Note

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.

Language Library
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

Integration

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

Nästa steg

Information om hur du kommer igång med Service Bus-meddelanden finns i följande artiklar:

  • Last updated on