Hej alle sammen!
Jeg er begyndt at oversætte en lille bog:
««,
forfatter: Jakub Korab, forlag: O’Reilly Media, Inc., udgivelsesdato: Juni 2017, ISBN: 9781492049296.
Fra bogens indledning:
«… Denne bog vil lære dig at tænke over systemer til beskedudveksling via mæglere, ved at sammenligne og kontrastere to populære mæglerteknologier: Apache ActiveMQ og Apache Kafka. Der vil blive præsenteret anvendelseseeksempler og udviklingsmotiver, som har fået deres udviklere til at anvende helt forskellige tilgange til det samme område - beskedudveksling mellem systemer med en mægler. Vi vil gennemgå disse teknologier fra bunden og fremhæve indflydelsen af forskellige designvalg undervejs. Du vil få en dybdegående forståelse af begge produkter, vide hvordan de skal og ikke skal bruges, samt vide, hvad du skal være opmærksom på, når du overvejer andre teknologier til beskedudveksling i fremtiden. …»
De dele, der er blevet oversat indtil nu:
Jeg vil offentliggøre de færdige kapitler, efterhånden som de bliver oversat.
KAPITEL 1
Introduktion
Beskedudveksling mellem systemer er et af de mindst forståede områder inden for IT. Som udvikler eller arkitekt kan du være godt bekendt med forskellige rammer og databaser. Men det er meget sandsynligt, at du kun har en overfladisk forståelse af, hvordan mæglerbaserede beskedteknologier fungerer. Hvis du har det på denne måde, så frygt ikke, du er i godt selskab.
Folk interagerer typisk med beskedudvekslingsinfrastrukturen i meget begrænset omfang. Det er ikke sjældent, at de tilslutter sig et system, der er blevet bygget for længe siden, eller downloader et distributionsprogram fra internettet, installerer det i PRODUKTION og begynder at skrive kode til det. Efter at infrastrukturen er blevet startet i PRODUKTION, kan resultaterne være tvetydige: tab af beskeder ved fejl, sending fungerer ikke som forventet, eller mæglere "hænger" dine producenter eller sender ikke beskeder til dine forbrugere.
Lyder det bekendt?
Et almindeligt scenarie er, når din meddelelsesudvekslingskode fungerer perfekt, indtil den pludselig holder op med at virke. Denne periode kan føre til falsk tryghed og en følelse af sikkerhed, hvilket resulterer i endnu mere kode, der er baseret på fejlagtige opfattelser af den grundlæggende teknologiopførsel. Når noget går galt, konfronteres du med en ubehagelig sandhed: at du faktisk ikke forstod produktets grundlæggende adfærd eller de kompromiser, som udviklerne har valgt, såsom ydeevne versus pålidelighed, eller transaktionalitet versus horisontal skalérbarhed.
Uden en dyb forståelse af, hvordan mæglere fungerer, kommer folk til at lave tilsyneladende rimelige udsagn om deres meddelelsessystemer, såsom:
- Systemet vil aldrig miste beskeder
- Beskeder vil blive behandlet i rækkefølge
- Tilføjelse af forbrugere vil gøre systemet hurtigere
- Beskeder vil blive leveret kun én gang
Desværre er nogle af disse udsagn baseret på antagelser, der kun gælder under bestemte omstændigheder, mens andre simpelthen er forkerte.
Denne bog vil lære dig at tænke over meddelelsessystemer baseret på mæglere ved at sammenligne og kontrastere to populære mæglerteknologier: Apache ActiveMQ og Apache Kafka. Her vil der blive præsenteret brugstilfælde og udviklingsincitamenter, der har ført til, at deres udviklere anvendte vidt forskellige tilgange til det samme område – meddelelsesudveksling mellem systemer med en mægler. Vi vil se på disse teknologier fra bunden og fremhæve indflydelsen fra forskellige designmuligheder på denne rejse. Du vil få en dybdegående forståelse af begge produkter, indsigt i, hvordan de bør og ikke bør anvendes, samt hvad du skal være opmærksom på, når du overvejer andre meddelelsesteknologier i fremtiden.
Før vi begynder, lad os gennemgå grundlæggende principper.
Hvad er et meddelelsessystem, og hvorfor er det nødvendigt
For two applications to communicate with each other, they first need to define an interface. Defining this interface includes choosing a transport or protocol, such as HTTP, MQTT, or SMTP, and agreeing on the message formats to be exchanged by the systems. This can be a strict process, such as defining an XML schema with payload requirements for the message, or it can be much less formal, like an agreement between two developers that a certain part of the HTTP request will contain the client ID.
As long as the message formats and the order in which they are sent between the systems are agreed upon, they will be able to interact with each other without worrying about the implementation of the other system. The internals of these systems, such as the programming language or framework used, can change over time. As long as the contract itself is maintained, interaction can continue unchanged from the other side. These two systems are effectively decoupled by this interface.
Messaging systems typically involve a mediator between the two systems that interact to further decouple the sender from the recipient or recipients. In this way, the messaging system allows the sender to send a message without knowing where the recipient is, whether they are active, or how many instances there are.
Let’s consider a couple of analogies of the types of problems that a messaging system solves, and introduce some basic terms.
Point-to-Point
Alexandra goes to the post office to send a package to Adam. She approaches the window and hands the package to the clerk. The clerk takes the package and gives Alexandra a receipt. Adam does not need to be home at the time of sending the package. Alexandra is confident that the package will be delivered to Adam at some point in the future and can continue with her business. Later, at some point, Adam receives the package.
This is an example of a messaging model point-to-point. The post office acts here as a mechanism for distributing packages, ensuring that each package is delivered exactly once. Using the post office separates the act of sending a package from delivering it.
I klassiske beskedudvekslingssystemer implementeres 'point-to-point'-modellen gennem af. En kø fungerer som en FIFO-buffer (først ind, først ud), som én eller flere forbrugere kan abonnere på. Hver besked leveres kun til én af de tilmeldte forbrugere. Køer forsøger normalt at fordele beskeder retfærdigt mellem forbrugerne. Kun én forbruger vil modtage den pågældende besked.
Køer anvendes ofte med termen 'pålidelig' ('durable'). Pålidelighed — det er en egenskab ved tjenesten, der sikrer, at beskedudvekslingssystemet vil gemme beskeder, når der ikke er aktive abonnenter, indtil en forbruger tilmelder sig køen for at modtage beskeder.
Pålidelighed forveksles ofte med persistens , og selvom disse to termer kan bruges om hinanden, udfører de forskellige funktioner. Persistens definerer, om systemet til beskedudveksling skriver en besked til en form for lager mellem modtagelsen og leveringen til forbrugeren. Beskeder sendt til køen kan være eller ikke være persistente.
Beskedudveksling af 'point-to-point'-typen anvendes, når brugsscenariet kræver en enkelt handling med beskeden. Et eksempel kunne være at indbetale penge på en konto eller gennemføre en leveringsbestilling. Vi vil senere diskutere, hvorfor beskedudvekslingssystemet ikke i sig selv kan garantere en enkelt levering, og hvorfor køer kun i bedste fald kan sikre levering mindst én gang.
Publisher-Subscriber
Gabriella ringer op til konferenceopkaldet. Mens hun er tilsluttet konferencen, hører hun alt, hvad taleren siger, sammen med de andre deltagere i opkaldet. Når hun afbryder forbindelsen, går hun glip af hvad der bliver sagt. Ved at genoprette forbindelsen kan hun fortsætte med at høre, hvad der bliver sagt.
This is an example of a messaging model publikation-abonnement. Konferenceopkald fungerer som en broadcastmekanisme. Taleren bryder sig ikke om, hvor mange mennesker der i øjeblikket er tilsluttet opkaldet — systemet sikrer, at enhver, der tilslutter sig, hører, hvad der bliver sagt.
I klassiske beskedudvekslingssystemer implementeres 'publikation-abonnement'-modellen gennem emnerEt emne giver en lige så god mulighed for broadcast som konferencetelefoni-mekanismen. Når en besked sendes til emnet, distribueres det til alle tilmeldte brugere..
Emner er typisk ikke-pålidelige (nondurable).Ligesom en lytter, der ikke hører, hvad der bliver sagt på konferencen, når lytteren slukker, går emnets abonnenter glip af meddelelser, der sendes, mens de er offline. Af denne grund kan det siges, at emner giver en leveringsgaranti ikke mere end én gang for hver forbruger.
Messaging-typologien "publikation-abonnement" bruges typisk, når meddelelserne er informerende, og tabet af en enkelt meddelelse ikke er af særlig betydning. For eksempel kan et emne transmittere temperaturmålinger fra en gruppe sensorer én gang i sekundet. Et system, der er interesseret i den aktuelle temperatur og som abonnerer på emnet, vil ikke bekymre sig, hvis det går glip af en meddelelse — en anden vil komme i nær fremtid.
Hybridmodeller
Webshoppen placerer beskeder om ordrer i en "beskedkø". Den primære forbruger af disse beskeder er det eksekverende system. Derudover skal revisionssystemet have kopier af disse beskeder om ordrer til senere opfølgning. Begge systemer må ikke gå glip af beskeder, selvom systemerne selv er utilgængelige i en periode. Webshoppen skal ikke kende til de andre systemer.
Brugsscenarier kræver ofte en kombination af messaging-modellerne "publikation-abonnement" og "punkt-til-punkt", for eksempel når flere systemer har brug for en kopi af meddelelsen, og både pålidelighed og persistens er nødvendige for at forhindre tab af meddelelser.
I disse tilfælde kræves en modtager (destination) (et generelt udtryk for køer og emner), som distribuerer beskeder især som et emne, så hver besked sendes til et separat system, der er interesseret i disse beskeder, men hvor hver system kan definere flere forbrugere, der modtager indkommende meddelelser, hvilket mere ligner en kø. Læsetypen i dette tilfælde er én gang for hver interesseret part.Disse hybride adresser kræver ofte pålidelighed, så hvis forbrugeren bliver frakoblet, accepteres de beskeder, der sendes i den periode, når forbrugeren genopretter forbindelsen.
Hybride modeller er ikke nye og kan anvendes i de fleste meddelelsessystemer, herunder både ActiveMQ (gennem virtuelle eller sammensatte adresser, der kombinerer emner og køer) og Kafka (implicit, som et grundlæggende designelement af dens adresse).
Nu hvor vi har noget grundlæggende terminologi og forståelse af, hvad vi måske ville få brug for et meddelelsessystem til, lad os gå videre til detaljerne.
Oversættelsen er udført:
Næste oversatte del:
Fortsætter…
Kilde: habr.com
