Hej alla!
Jag började översätta en liten bok:
«',
författare: Jakub Korab, utgivare: O'Reilly Media, Inc., publiceringsdatum: juni 2017, ISBN: 9781492049296.
Från inledningen till boken:
" ... Den här boken kommer att lära dig hur du tänker på mäklarmeddelandesystem, genom att jämföra och kontrastera två populära mäklarteknologier: Apache ActiveMQ och Apache Kafka. Den kommer att beskriva de användningsfall och utvecklingsincitament som ledde till att deras utvecklare tog mycket olika tillvägagångssätt inom samma område – meddelanden mellan system med en mellanliggande mäklare. Vi kommer att titta på dessa tekniker från grunden och lyfta fram effekterna av olika designval längs vägen. Du kommer att få en djup förståelse för båda produkterna, en förståelse för hur de bör och inte bör användas, och en förståelse för vad du ska leta efter när du överväger andra meddelandetekniker i framtiden ... "
Hittills översatta delar:
Jag kommer att lägga upp färdiga kapitel allt eftersom de översätts.
KAPITEL 1
Inledning
System-till-system-meddelanden är ett av de minst förstådda områdena inom IT. Som utvecklare eller arkitekt kan du vara mycket bekant med olika ramverk och databaser. Det är dock troligt att du bara har en övergående förtrogenhet med hur mäklarbaserad meddelandeteknik fungerar. Om du känner så här, oroa dig inte, du är i gott sällskap.
Människor har vanligtvis mycket begränsad kontakt med meddelandeinfrastrukturen. De ansluter ofta till ett system som skapats för länge sedan, eller laddar ner en distribution från Internet, installerar det i PROM och börjar skriva kod för det. Efter att ha kört infrastrukturen i PROM kan resultaten blandas: meddelanden går förlorade på grund av misslyckanden, sändningen fungerar inte som du förväntade dig, eller mäklare "hänger" dina producenter eller skickar inte meddelanden till dina konsumenter.
Låter bekant?
Ett vanligt scenario är att din meddelandekod fungerar utmärkt för tillfället. Tills det slutar fungera. Denna period invaggar ens vakt till en falsk känsla av säkerhet, vilket leder till mer kod baserad på falska föreställningar om teknikens grundläggande beteende. När saker börjar gå fel ställs du inför en obekväm sanning: att du inte riktigt har förstått produktens underliggande beteende eller de avvägningar som författarna valt, såsom prestanda kontra tillförlitlighet, eller transaktionalitet kontra horisontell skalbarhet .
Utan en djup förståelse för hur mäklare fungerar, gör människor till synes rimliga uttalanden om sina meddelandesystem, som:
- Systemet kommer aldrig att förlora meddelanden
- Meddelanden kommer att behandlas sekventiellt
- Att lägga till konsumenter kommer att göra systemet snabbare
- Meddelanden kommer bara att levereras en gång
Tyvärr är vissa av dessa påståenden baserade på antaganden som bara gäller under vissa omständigheter, medan andra helt enkelt är felaktiga.
Den här boken kommer att lära dig hur du tänker på mäklarbaserade meddelandesystem, genom att jämföra och kontrastera två populära mäklarteknologier: Apache ActiveMQ och Apache Kafka. Den kommer att beskriva de användningsfall och utvecklingsincitament som ledde till att deras utvecklare tog mycket olika tillvägagångssätt inom samma område – meddelanden mellan system med en mellanliggande mäklare. Vi kommer att titta på dessa tekniker från grunden och lyfta fram effekterna av olika designval längs vägen. Du kommer att få en djup förståelse för båda produkterna, en förståelse för hur de bör och inte bör användas, och en förståelse för vad du ska leta efter när du överväger andra meddelandetekniker i framtiden.
Innan vi börjar, låt oss gå igenom grunderna.
Vad är ett meddelandesystem och varför behövs det?
För att två applikationer ska kunna kommunicera med varandra måste de först definiera ett gränssnitt. Att definiera detta gränssnitt innebär att välja en transport eller ett protokoll, såsom HTTP, MQTT eller SMTP, och förhandla om meddelandeformaten som kommer att utbytas mellan systemen. Detta kan vara en strikt process, till exempel att definiera ett XML-schema med kostnadskrav för meddelandenyttolast, eller så kan det vara mycket mindre formell, till exempel en överenskommelse mellan två utvecklare om att någon del av HTTP-förfrågan kommer att innehålla klientidentifieraren .
Så länge formatet på meddelanden och ordningen i vilken de skickas är konsekvent mellan systemen, kan de kommunicera med varandra utan att oroa sig för det andra systemets implementering. De interna funktionerna i dessa system, såsom programmeringsspråket eller ramverket som används, kan förändras över tiden. Så länge själva kontraktet upprätthålls kan samspelet fortsätta utan förändringar från andra sidan. De två systemen är effektivt frånkopplade (separerade) av detta gränssnitt.
Meddelandesystem involverar vanligtvis en mellanhand mellan två system som interagerar för att ytterligare frikoppla (separera) avsändaren från mottagaren eller mottagarna. I det här fallet tillåter meddelandesystemet avsändaren att skicka ett meddelande utan att veta var mottagaren är, om han är aktiv eller hur många instanser det finns.
Låt oss titta på ett par analogier för den typ av problem som ett meddelandesystem löser och introducera några grundläggande termer.
Punkt till punkt
Alexandra går till posten för att skicka ett paket till Adam. Hon går fram till fönstret och ger den anställde paketet. Den anställde hämtar paketet och ger Alexandra ett kvitto. Adam behöver inte vara hemma när paketet skickas. Alexandra är övertygad om att paketet kommer att levereras till Adam någon gång i framtiden och att hon kan fortsätta sin verksamhet. Senare vid något tillfälle får Adam ett paket.
Detta är ett exempel på en meddelandemodell punkt till punkt. Posten här fungerar som en paketdistributionsmekanism och säkerställer att varje paket levereras en gång. Att använda ett postkontor skiljer handlingen att skicka ett paket från leveransen av paketet.
I klassiska meddelandesystem implementeras punkt-till-punkt-modellen genom köer. Kön fungerar som en FIFO-buffert (först in, först ut) som kan abonneras på av en eller flera konsumenter. Varje meddelande levereras endast till en av de prenumererade konsumenterna. Köer försöker vanligtvis distribuera meddelanden rättvist bland konsumenterna. Endast en konsument kommer att få detta meddelande.
Termen "hållbar" används för köer. Надежность är en tjänstegenskap som säkerställer att meddelandesystemet kommer att bevara meddelanden i frånvaro av aktiva abonnenter tills en konsument prenumererar på kön för meddelandeleverans.
Tillförlitlighet förväxlas ofta med uthållighet och även om de två termerna används omväxlande, har de olika funktioner. Persistens avgör om meddelandesystemet skriver ett meddelande till någon form av lagring mellan att ta emot det och skicka det till konsumenten. Meddelanden som skickas till kön kan vara bestående eller inte.
Punkt-till-punkt-meddelanden används när användningsfallet kräver en engångsåtgärd på meddelandet. Exempel är att sätta in pengar på ett konto eller slutföra en leveransorder. Vi kommer att diskutera senare varför meddelandesystemet på egen hand inte kan tillhandahålla engångsleverans och varför köer i bästa fall kan ge leveransgaranti åtminstone en gång.
Publisher-Prenumerant
Gabriella slår konferensnumret. Medan hon är kopplad till konferensen hör hon allt talaren säger, tillsammans med resten av samtalsdeltagarna. När hon stämmer av missar hon det som sägs. När hon är återansluten fortsätter hon att höra vad som sägs.
Detta är ett exempel på en meddelandemodell publicera-prenumerera. Konferenssamtal fungerar som en sändningsmekanism. Personen som talar bryr sig inte om hur många personer som för närvarande är i samtalet - systemet ser till att alla som är anslutna hör vad som sägs.
I klassiska meddelandesystem implementeras meddelandemodellen för publicering och prenumeration blast. Topic tillhandahåller samma sändningsmetod som konferensmekanismen. När ett meddelande skickas till ett ämne distribueras det för alla prenumererade användare.
Ämnen är vanligtvis opålitlig (icke hållbar). Precis som en lyssnare som inte kan höra vad som sägs i ett konferenssamtal när lyssnaren kopplar bort, missar ämnesprenumeranter alla meddelanden som skickas när de är offline. Av denna anledning kan vi säga att ämnen ger en leveransgaranti inte mer än en gång för varje konsument.
Publicera-prenumerera meddelanden används vanligtvis när meddelandena är av informativ karaktär och förlusten av ett meddelande inte är särskilt betydande. Till exempel kan ett ämne överföra temperaturavläsningar från en grupp sensorer en gång per sekund. Ett system som är intresserad av den aktuella temperaturen och som prenumererar på ett ämne kommer inte att oroa sig om det missar ett meddelande – ett annat kommer inom en snar framtid.
hybridmodeller
Butikens hemsida placerar ordermeddelanden i en "meddelandekö". Huvudkonsumenten av dessa meddelanden är det verkställande systemet. Dessutom bör revisionssystemet ha kopior av dessa ordermeddelanden för efterföljande spårning. Båda systemen kan inte tillåta meddelanden att passera, även om själva systemen är otillgängliga under en tid. Webbplatsen bör inte vara medveten om andra system.
Användningsfall kräver ofta en kombination av publicera-prenumerera och punkt-till-punkt meddelandemodeller, till exempel när flera system kräver en kopia av ett meddelande och både tillförlitlighet och beständighet krävs för att förhindra meddelandeförlust.
Dessa fall kräver en destination (en allmän term för köer och ämnen) som distribuerar meddelanden i princip som ett ämne, så att varje meddelande skickas till ett separat system som är intresserad av dessa meddelanden, men också där varje system kan definiera flera konsumenter som tar emot inkommande meddelanden, vilket är mer som en kö. Lästypen i det här fallet är en gång för varje intressent. Dessa hybriddestinationer kräver ofta hållbarhet så att om en konsument går offline, tas meddelanden som skickas vid den tidpunkten emot efter att konsumenten återansluter.
Hybridmodeller är inte nya och kan användas i de flesta meddelandesystem, inklusive både ActiveMQ (via virtuella eller sammansatta destinationer som kombinerar ämnen och köer) och Kafka (implicit, som en grundläggande egenskap för dess destinationsdesign).
Nu när vi har lite grundläggande terminologi och en förståelse för vad vi kan använda ett meddelandesystem till, låt oss gå ner till detaljerna.
Översättning gjord:
Följande översatta del:
Fortsättning ...
Källa: will.com