Välj om du vill använda meddelanden eller händelser
Anta att du planerar arkitekturen för ett distribuerat musikdelningsprogram. Du vill se till att programmet är så tillförlitligt och skalbart som möjligt och att du tänker använda Azure-tekniker för att skapa en robust kommunikationsinfrastruktur.
Innan du kan välja rätt Azure-teknik måste du förstå varje enskild kommunikation som komponenterna i programmet utbyter. För varje kommunikation kan du välja en annan Azure-teknik.
Det första du behöver veta om en kommunikation är om den skickar meddelanden eller händelser. Den här kunskapen hjälper dig att välja lämplig Azure-tjänst att använda.
Kommunikationsstrategier i Azure (API:er)
Vad är ett meddelande?
I terminologin för distribuerade program meddelanden har följande egenskaper:
- Ett meddelande innehåller rådata som produceras av en komponent och som används av en annan komponent.
- Ett meddelande innehåller själva data, inte bara en referens till dessa data.
- Den sändande komponenten förväntar sig att målkomponenten bearbetar meddelandeinnehållet på ett visst sätt. Den övergripande systemintegriteten kan bero på att både avsändare och mottagare utför ett visst jobb.
Anta till exempel att en användare laddar upp en ny låt med hjälp av den mobila musikdelningsappen. Mobilappen måste skicka den låten till webb-API:et, som körs i Azure. Själva låtmediefilen måste skickas, inte bara en avisering som anger att en ny låt har lagts till. Mobilappen förväntar sig att webb-API:et lagrar den nya låten i databasen och gör den tillgänglig för andra användare. Den här är ett exempel på ett meddelande.
Vad är en händelse?
Händelser är enklare än meddelanden och används oftast för sändningskommunikation. Komponenterna som skickar händelsen kallas utgivareoch mottagare kallas prenumeranter.
Med händelser bestämmer mottagande komponenter i vilken kommunikation de är intresserade och "prenumererar" på dessa händelser. En mellanhand hanterar prenumerationen, till exempel Azure Event Grid eller Azure Event Hubs. När utgivare skickar en händelse dirigerar mellanhanden händelsen till intresserade prenumeranter. Det här mönstret kallas för en "publicera-prenumerera-arkitektur". Det är inte det enda sättet att hantera händelser, men det är det vanligaste.
Händelser har följande egenskaper:
- En händelse är ett enkelt meddelande som anger att något har hänt.
- Händelsen kan skickas till flera mottagare eller till ingen alls.
- Händelser är ofta avsedda att "sprida sig" eller ha ett stort antal prenumeranter för varje arrangör.
- Utgivaren av händelsen har inga förväntningar på den åtgärd som en mottagande komponent vidtar.
- Vissa händelser är diskreta enheter som inte är relaterade till andra händelser.
- Vissa händelser ingår i en relaterad och ordnad serie.
Anta till exempel att uppladdningen av musikfilen är klar och att den nya låten läggs till i databasen. För att informera användarna om den nya filen måste webb-API:et informera webbklientdelen och mobilappsanvändare om den nya filen. Användarna kan välja om de vill lyssna på den nya låten, så det första meddelandet innehåller inte musikfilen utan meddelar bara användarna att låten finns. Avsändaren har ingen specifik förväntan på att händelsemottagarna gör något särskilt som svar på den här händelsen.
Det här scenariot är ett exempel på en diskret händelse.
Så här väljer du meddelanden eller händelser
Ett enda program kommer sannolikt att använda händelser för vissa syften och meddelanden för andra. Innan du väljer måste du analysera programmets arkitektur och alla dess användningsfall för att identifiera alla olika syften där dess komponenter måste kommunicera med varandra.
Händelser är mer benägna att användas för sändningar och är ofta tillfälliga, vilket innebär att en kommunikation inte hanteras av någon mottagare om ingen prenumererar för närvarande. Det är mer troligt att meddelanden används där det distribuerade programmet kräver en garanti för att kommunikationen bearbetas.
Överväg följande fråga för varje kommunikation: Förväntar sig den sändande komponenten att kommunikationen bearbetas på ett visst sätt av målkomponenten?
Om svaret är javäljer du att använda ett meddelande. Om svaret är ingenkan du kanske använda händelser.
Att förstå hur dina komponenter behöver kommunicera hjälper dig att välja hur komponenterna ska kommunicera. Vi börjar med meddelanden.