Välja en plattform för meddelanden
Många kommunikationsplattformar är tillgängliga för att förbättra tillförlitligheten för ett distribuerat program, inklusive flera i Microsoft Azure. Varje plattform är ett verktyg som har olika syften. Det är viktigt att välja rätt verktyg för varje krav i ditt program. Ta en titt på dina alternativ i Azure Service Bus.
Den föreslagna Contoso Bicycles-beställningen och spårningsprogrammets distribuerade arkitektur kräver flera komponenter, inklusive en webbplats, datalagring och en serverdelstjänst. Du kan binda ihop komponenterna i ditt program på många olika sätt, och ett enda program kan dra nytta av flera tekniker.
Du måste bestämma vilka tekniker som ska användas i det nya Contoso Bicycles-programmet. Det första steget är att utvärdera varje plats där det finns kommunikation mellan flera delar. Vissa komponenter måste köras i tid för att programmet ska kunna utföra sitt jobb alls. Vissa kan vara viktiga, men inte tidskritiska. Slutligen är andra komponenter, till exempel mobilappsaviseringar, lite mer valfria.
Välja mellan meddelanden och händelser
Både meddelanden och händelser är datagram: paket med data som skickas från en komponent till en annan. De är olika på sätt som först verkar subtila, men skillnaderna kan göra betydande skillnader i hur du utformar ditt program.
Meddelanden
I terminologin för distribuerade program är det avgörande kännetecknande för ett meddelande att programmets övergripande integritet kan vara beroende av att meddelanden tas emot. Du kan föreställa dig att när du skickar ett meddelande till en komponent skickas stafettpinnen från ett arbetsflöde vidare till en annan komponent. Hela arbetsflödet kan vara en viktig affärsprocess och meddelandet är murbruket som håller ihop komponenterna.
Ett meddelande innehåller vanligtvis faktiska data, inte bara en referens (till exempel ett ID eller en URL) till data. Att skicka data som en del av ett datagram är mindre sprött än att skicka en referens. Meddelandearkitekturen garanterar meddelandeleverans och eftersom inga extra sökningar krävs hanteras meddelandet på ett tillförlitligt sätt. Det sändande programmet måste dock veta exakt vilka data som ska inkluderas för att undvika att skicka för mycket data, vilket skulle kräva att den mottagande komponenten utför onödigt arbete. I den meningen kopplas meddelandesändaren och mottagaren ofta ihop med ett strikt datakontrakt.
När en beställning görs i den nya arkitekturen för Contoso Bicycles använder företaget sannolikt meddelanden. Webbklientdelen eller mobilappen skickar ett meddelande till serverdelsbearbetningskomponenterna. I serverdelen sker steg som routning till butiken närmast kunden och debitering av ett kreditkort.
Händelser
En händelse utlöser ett meddelande om att något har skett. Händelser är ”enklare” än meddelanden och används oftast för sändningskommunikation.
Händelser har följande egenskaper:
- Händelsen kan skickas till flera mottagare eller till ingen alls.
- Händelser är ofta avsedda att ”förgrenas” eller har ett stort antal prenumeranter för varje utgivare.
- Händelseutgivaren har inga förväntningar på den åtgärd som en mottagande komponent vidtar.
En cykeldelskedja skulle sannolikt använda händelser för användarmeddelanden om statusändringar. Statusändringshändelser kan skickas till Azure Event Grid, sedan vidare till Azure Functions och till Azure Notification Hubs för en helt serverlös lösning.
Den här skillnaden mellan händelser och meddelanden är grundläggande eftersom kommunikationsplattformar vanligen är utformade för att hantera det ena eller det andra. Service Bus är utformat för att hantera meddelanden. Om du vill skicka händelser väljer du förmodligen Event Grid.
Azure har också Azure Event Hubs, men används oftast för en viss typ av högflödesström av kommunikation som används för analys. Om du till exempel har nätverksanslutna sensorer i dina tillverkningslager kan du använda Event Hubs i kombination med Azure Stream Analytics för att titta efter mönster i temperaturförändringar som kan tyda på en oönskad brand eller komponentslitage.
Service Bus-ämnen och köer
Azure Service Bus kan utbyta meddelanden på två olika sätt: köer och ämnen.
Vad är en kö?
En Service Bus-kö är en enkel tillfällig lagringsplats för meddelanden. En sändande komponent lägger till ett meddelande till kön. En målkomponent hämtar det meddelande som ligger först i kön. Under normala förhållanden tas varje meddelande emot av endast en mottagare.
Köer frikopplar käll- och målkomponenterna för att isolera målkomponenter från hög efterfrågan.
Under tider med hög belastning kan meddelanden komma in snabbare än målkomponenterna kan hantera dem. Eftersom källkomponenter inte har någon direkt anslutning till målet påverkas inte källan och kön växer. Målkomponenter tar bort meddelanden från kön eftersom de kan hantera dem. När efterfrågan minskar kan målkomponenterna komma ikapp och kön förkortas.
En kö svarar på hög efterfrågan utan att behöva lägga till resurser i systemet. För meddelanden som behöver hanteras snabbt kan det dock göra att de kan dela belastningen genom att skapa fler instanser av målkomponenten. Varje meddelande hanteras bara av en instans. Det här är ett effektivt sätt att skala hela programmet genom att bara lägga till resurser i de komponenter som faktiskt behöver det.
Vad är ett ämne?
Ett Service Bus-ämne liknar en kö, men ett ämne kan ha flera prenumerationer. Det innebär att flera målkomponenter kan prenumerera på ett specifikt ämne, så varje meddelande levereras till flera mottagare. Prenumerationer kan även filtrera meddelandena i ämnet för att bara ta emot relevanta meddelanden. Prenumerationer erbjuder samma frikopplade kommunikation som köer och svarar på hög efterfrågan på samma sätt. Använd ett ämne om du vill att varje meddelande ska levereras till mer än en målkomponent.
Kommentar
Ämne kan inte användas på Basic-prisnivån.
Service Bus-köer och Storage-köer
Två Azure-tjänster omfattar meddelandeköer: Service Bus och Azure Storage. Som en allmän guide är lagringsköer enklare att använda, men de är mindre avancerade och mindre flexibla än Service Bus-köer.
De viktigaste fördelarna med Service Bus-köer är:
- Har stöd för större meddelandestorlekar på 256 KB (standardnivå) eller 100 MB (premiumnivå) per meddelande jämfört med 64 KB för Azure Storage-kömeddelanden.
- Stöder både leverans högst en gång och minst en gång. Välj mellan en mycket liten chans att ett meddelande går förlorat eller en mycket liten chans att det hanteras två gånger.
- Garanterar fifo-order (first-in, first-out). Meddelanden hanteras i samma ordning som de läggs till. Även om FIFO är den normala driften av en kö ändras fifo-standardmönstret om organisationen konfigurerar sekvenserade eller schemalagda meddelanden eller under avbrott som en systemkrasch. Mer information finns i Jämför Azure Storage-köer och Azure Service Bus-köer.
- Kan gruppera flera meddelanden i en transaktion. Om ett meddelande i transaktionen inte kan levereras levereras inte alla meddelanden i transaktionen.
- Stöder rollbaserad säkerhet.
- Kräver inte målkomponenter för att kontinuerligt avsöka kön.
Fördelar med Storage-köer:
- Stöder obegränsad köstorlek (jämfört med högst 80 GB för Service Bus-köer)
- Innehåller en logg över alla meddelanden
Så här väljer du en kommunikationsteknik
Du har sett de olika begreppen och implementeringarna som Azure tillhandahåller. Tänk sedan på hur din beslutsprocess ska se ut för var och en av dina kommunikationer.
Överväganden
Tänk på följande frågor när du väljer en metod för att skicka och ta emot meddelanden:
Är kommunikationen en händelse? I så fall bör du överväga att använda Event Grid eller Event Hub.
Ska ett enda meddelande levereras till mer en ett mål? Om det ska det använder du ett Service Bus-ämne. Annars använder du en Service Bus-kö.
Köer: Service Bus jämfört med lagring
Om du bestämmer dig för att du behöver en kö kan du begränsa ditt val ytterligare.
Välj en Service Bus-kö om:
- Du behöver en leveransgaranti högst en gång.
- Du behöver en FIFO-garanti (om inga andra inställningar föregriper FIFO-standardordningen).
- Du behöver gruppera meddelanden i transaktioner.
- Du vill ta emot meddelanden utan att avsöka kön.
- Du måste ge rollbaserad åtkomst till köerna.
- Du måste hantera meddelanden som är större än 64 KB men mindre än 256 KB för standardnivån eller 100 MB för premiumnivån.
- Köstorleken blir inte större än 80 GB.
- Du vill kunna publicera och använda batchar med meddelanden.
Välj en lagringskö om:
- Du behöver en enkel kö utan några särskilda extra krav.
- Du behöver en spårningslogg för alla meddelanden som skickas via kön.
- Du förväntar dig att kön kommer att överskrida 80 GB i storlek.
- Du vill spåra förloppet för bearbetning av ett meddelande i kön.
Även om komponenterna i ett distribuerat program kan kommunicera direkt kan du ofta öka kommunikationens tillförlitlighet med hjälp av en mellanliggande kommunikationsplattform som Azure Event Hubs eller Azure Event Grid.
Event Hubs och Event Grid är utformade för händelser som endast meddelar mottagarna om en händelse och inte innehåller rådata som är associerade med händelsen. Azure Event Hubs är utformat för högflödesanalystyper av händelser.
Azure Service Bus och lagringsköer är till för meddelanden, som du kan använda för att binda kärndelarna i alla programarbetsflöden.
Om dina krav är enkla, om du bara vill skicka varje meddelande till ett mål, eller om du vill skriva kod så snabbt som möjligt, kan en lagringskö vara det bästa alternativet. I annat fall erbjuder Service Bus-köer många fler alternativ och större flexibilitet.
Om du vill skicka meddelanden till flera prenumeranter kan du använda ett Service Bus-ämne.