Välj om du vill använda meddelanden eller händelser
Anta att du planerar arkitekturen för ett distribuerat musikdelningsprogram. Du vill att programmet ska vara så tillförlitligt och skalbart som möjligt och du planerar att använda Azure-tekniker till att bygga 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. Du kan välja olika Azure-tekniker för olika sorters kommunikation.
Det första du ska ta reda på är om en kommunikation 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 har meddelanden 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 informationen, 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 exempelvis att en användare laddar upp en ny låt med hjälp av mobilappen för musikdelning. Mobilappen måste skicka den låten till webb-API:et, som körs i Azure. Själva mediefilen 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. Detta ä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. De komponenter som skickar händelsen kallas för utgivare och mottagare kallas för 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 förenklat meddelande som anger att något har inträffat.
- Händelsen kan skickas till flera mottagare eller inte till någon alls.
- Händelser är ofta avsedda att ”förgrenas” eller har ett stort antal prenumeranter för varje utgivare.
- Utgivaren av händelsen har ingen förväntan på åtgärder från den mottagande komponenten.
- Vissa händelser är diskreta enheter som inte är relaterade till andra händelser.
- Vissa händelser är en del av en relaterad och ordnad serie.
Anta till exempel att uppladdningen av musikfilen har slutförts och att den nya låten har lagts till i databasen. För att kunna informera användarna om den nya filen måste webb-API:n meddela webbklientdelen och mobilappanvändarna om detta. 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.
Detta scenario är ett exempel på en diskret händelse.
Välja meddelanden eller händelser
Ett enskilt program använder troligen 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. Det innebär att en kommunikation kanske inte hanteras av någon mottagare om ingen prenumererar för närvarande. Det är sannolikt att meddelanden används där det distribuerade programmet kräver en garanti för att kommunikationen kommer att bearbetas.
För varje typ av kommunikation bör du ställa dig följande fråga: Förväntar den sändande komponenten att kommunikationen ska bearbetas på ett visst sätt av målkomponenten?
Om svaret är Ja bör du välja att använda ett meddelande. Om svaret är nej kanske du kan 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.