Vad är RabbitMQ?
I alla molnbaserade appar måste mikrotjänster kommunicera för att få all information de behöver för att svara användarna. Du bör se till att den här meddelandefunktionen är robust även när det finns nätverksproblem eller fel mellan integreringarna. RabbitMQ är ett verktyg som du kan använda för att öka tillförlitligheten för meddelanden.
I din återförsäljare av utomhusutrustning gör du snabba framsteg med dina mikrotjänster. I programtestning verkar dock vissa anrop från en mikrotjänst till en annan gå förlorade. Du vill se till att det här problemet inte uppstår i produktionsmiljön där företagets rykte står på spel.
I den här lektionen får du se hur RabbitMQ kan skapa en flexibel och elastisk kommunikationsplattform för mikrotjänster.
Varför ska du använda en meddelandekö i en molnbaserad app?
Molnbaserade appar består av oberoende mikrotjänster, ofta byggda av separata team och med olika tekniker och språk. Varje team har sina egna utvecklingssprintar och uppgraderingsscheman och kan distribuera korrigeringar och nya funktioner kontinuerligt. Men när en begäran kommer från en användare måste den mikrotjänst som tar emot den nästan alltid anropa andra mikrotjänster och stödtjänster och ta emot svar från dem för att formulera det fullständiga svaret.
Självklart måste formatet och schemat för dessa begäranden och svar mellan tjänster överensstämmas mellan utvecklingsteamen och ändras sällan. De implementeras vanligtvis som REST-API:er. Du bör företrädesvis implementera nya funktioner i varje gränssnitt utan att ändra befintliga metoder och parametrar. Men om du väljer att låta mikrotjänster kommunicera direkt kan det uppstå flera problem:
- Vad händer med meddelanden som skickas till den när en målmikrotjänst är offline eller upptagen? Vilka är konsekvenserna av att meddelanden går förlorade?
- Hur kan du skicka samma meddelande till fler än ett mål?
- Om en mikrotjänst körs på mer än en container, vilket ska du skicka meddelanden till?
En meddelandekö är mellanprogram som åtgärdar dessa problem. Tjänster skickar meddelanden till meddelandekoordinatorn i stället för direkt till ett mål. Mäklaren lagrar dem i köer i den ordning de anländer. Måltjänster prenumererar på dessa köer och hämtar meddelanden, en i taget, för bearbetning.
Om måltjänsten inte är tillgänglig kan den sändande mikrotjänsten fortfarande placera meddelanden i kön. När målet startas om fortsätter det att hämta meddelanden från kön, från samma punkt. Inga meddelanden går förlorade, även om avsändaren måste vänta längre.
Eftersom fler än ett mål kan prenumerera på en kö kan ett enda meddelande tas emot av mer än en mikrotjänst. När flera containrar är värd för instanser av en enda mikrotjänst hämtar dessutom den första instansen som blir tillgänglig meddelandet. Asynkron meddelandekö distribuerar automatiskt meddelanden till instanser för att sprida belastningen.
Vad är RabbitMQ?
RabbitMQ är en av de mest populära meddelandeköerna och har många funktioner som gör det till en idealisk kandidat för att hantera kommunikation i en molnbaserad app. Den innehåller:
- RabbitMQ-servern som är värd för köerna. Servern stöder klustring och redundans för hög tillgänglighet och kan köras i containrar.
- Implementeringar av Advanced Message Queuing Protocol (AMQP), Simple Text Oriented Message Protocol (STOMP) och MQTT (Message Queuing Telemetry Transport).
- AMQP-klientbibliotek som du kan använda i .NET, Java och Erlang.
RabbitMQ-begrepp
I RabbitMQ-termer är dina mikrotjänster, som skickar och tar emot meddelanden, klienter. Klienter som skickar meddelanden kallas meddelandeproducenter. Klienter som tar emot meddelanden är meddelandekonsumenter. RabbitMQ-tjänsten är meddelandekö.
Så här skickar du meddelanden
RabbitMQ är mångsidig och kan implementera många olika kömodeller. Nu ska vi undersöka några populära mönster.
Om du har en enskild producent och en enskild konsument använder du en enda kö och alla meddelanden når samma mål. Även i den här enkla konfigurationen skapar du ett robust meddelandesystem som hanterar avbrott smidigt:
Skicka meddelanden till konkurrerande konsumenter
I den konkurrerande konsumentmodellen skickar en producent meddelanden till en enda arbetskö. Två eller flera konsumenter hämtar meddelanden från kön. Konsumenterna konkurrerar om att hämta meddelanden eftersom varje meddelande bara kan hämtas av en enskild konsument.
Det här mönstret är användbart i molnbaserade appar när du har en förbrukande mikrotjänst som finns på flera containrar för att öka kapaciteten. Varje meddelande når bara en instans av konsumenten, så bearbetas bara en gång. Arbetet dupliceras inte.
Publicera och prenumerera
Om du vill skicka ett enda meddelande från en producent till flera konsumenter använder du modellen publicera/prenumerera . Producenten skickar meddelanden till ett utbyte. Varje konsument prenumererar på meddelanden från det utbytet. När de prenumererar skapar RabbitMQ en ny arbetskö för den prenumerationen. Varje meddelande kopieras till varje kö för det utbytet och tas emot av alla konsumenter som prenumererar. Konsumenterna konkurrerar inte om varje meddelande. I stället får alla en kopia av varje meddelande.
Publicerings-/prenumerationsmodellen använder ett fanout-utbyte som kopierar varje meddelande till varje arbetskö.
Det här mönstret är användbart när du vill att varje meddelande ska bearbetas av flera mikrotjänster. När en kund till exempel checkar ut en korg kanske du vill skicka ett meddelande om antalet produkter som de har köpt. Det här meddelandet bör nå både leveransmikrotjänsten, för att instruera lagret att packa paketet och lagermikrotjänsten, att minska lagernumren och kanske utlösa beställningar till leverantörer.
Routningsmeddelanden och ämnen
Ibland vill du distribuera enskilda meddelanden till flera konsumenter, men för varje konsument använder du ett filter. Det här mönstret kallas för en meddelanderouter. Precis som i publicerings-/prenumerationsmodellen prenumererar konsumenterna på utbytet för att skapa flera arbetsköer. Men i stället för ett fanout-utbyte använder modellen ett direktutbyte . Med det här utbytet har varje prenumeration en bindningsnyckel. Endast meddelanden vars routningsnyckel matchar bindningsnyckeln skickas till den här prenumerationen. Andra filtreras bort.
Det här mönstret är användbart när vissa konsumenter endast bör bearbeta en delmängd av meddelandeströmmen. Anta till exempel att du har en mikrotjänst som skickar meddelanden när fel inträffar. Alla fel ska skickas till loggningsmikrotjänsten. Kritiska fel ska skickas till den administrationsmikrotjänst som aviserar tekniker att åtgärda problemet.
Direktutbytet dirigerar meddelanden baserat på ett enda villkor. Om du vill göra saker och ting ännu mer flexibla kan du använda ett ämnesutbyte . För varje meddelande kan du använda en routningsnyckel med flera termer avgränsade med punkter. I bindningsnyckeln kan du använda jokertecken *, för att ersätta exakt ett ord eller # ersätta med noll eller fler ord.
Kommentar
Alternativ till RabbitMQ är Apache Kafka och Azure Service Bus. Båda dessa meddelandeköer stöds av dedikerade integreringar i .NET Aspire. Du får lära dig mer om Azure Service Bus i en senare modul i den här utbildningsvägen.