Hallo allemaal!
Ik ben begonnen met het vertalen van een klein boek:
««,
auteur: Jakub Korab, uitgeverij: O’Reilly Media, Inc., publicatiedatum: juni 2017, ISBN: 9781492049296.
Uit de inleiding van het boek:
«… Dit boek leert je nadenken over berichtenoverdrachtsystemen op basis van brokers, door twee populaire brokertechnologieën te vergelijken en tegenover elkaar te stellen: Apache ActiveMQ en Apache Kafka. Voorbeelden van gebruik en ontwikkelingsdrijfveren die hebben geleid tot heel verschillende benaderingen van hetzelfde gebied — berichtenoverdracht tussen systemen met een tussenliggende broker — worden hier gepresenteerd. We zullen deze technologieën vanaf de basis bekijken en de invloed van verschillende ontwerpmogelijkheden op dat pad benadrukken. Je krijgt een diepgaand begrip van beide producten, inzicht in hoe je ze moet en niet moet gebruiken, en begrip van wat je moet overwegen bij het bekijken van andere berichtenoverdrachtstechnologieën in de toekomst. …»
Tot nu toe vertaalde delen:
Ik zal voltooide hoofdstukken plaatsen naarmate ik ze vertaal.
HOOFDSTUK 1
Inleiding
Berichtenoverdracht tussen systemen is een van de minst begrepen gebieden in IT. Als ontwikkelaar of architect ben je misschien goed bekend met verschillende frameworks en databases. Toch is het heel goed mogelijk dat je slechts een oppervlakkige kennis hebt van hoe berichtenoverdrachtstechnologieën die zijn gebaseerd op brokers werken. Als je je zo voelt, maak je geen zorgen, je bent in goed gezelschap.
Mensen komen meestal slechts in beperkte mate in contact met berichteninfrastructuur. Het is niet ongewoon om verbinding te maken met een systeem dat lang geleden is gemaakt, of om een distributie van het internet te downloaden, deze in een productieomgeving te installeren en begin met het schrijven van code daarvoor. Na het opzetten van de infrastructuur in productie kunnen de resultaten tegenvallend zijn: verlies van berichten bij storingen, verzending werkt niet zoals verwacht, of brokers ‘vergrendelen’ je producenten of verzenden geen berichten naar je consumenten.
Klinkt herkenbaar?
Een veelvoorkomend scenario is dat uw berichtenuitwisseling perfect werkt, tot het moment dat het stopt met werken. Deze periode verleidt tot een vals gevoel van veiligheid, waardoor er nog meer code wordt geschreven die is gebaseerd op verkeerde aannames over het fundamentele gedrag van de technologie. Wanneer er iets misgaat, komt u erachter dat u de basisprincipes van het product of de compromissen die door de ontwikkelaars zijn gemaakt, zoals prestaties versus betrouwbaarheid, of transactioneel versus horizontaal schalen, in werkelijkheid niet begreep.
Zonder een diepgaand begrip van hoe brokers functioneren, doen mensen schijnbaar verstandige uitspraken over hun berichtenuitwisselingssystemen, zoals:
- Het systeem zal nooit berichten verliezen.
- Berichten worden sequentieel verwerkt.
- Het toevoegen van consumenten zal het systeem sneller maken.
- Berichten worden slechts één keer afgeleverd.
Helaas zijn sommige van deze uitspraken gebaseerd op aannames die alleen onder bepaalde omstandigheden gelden, terwijl andere simpelweg onjuist zijn.
Dit boek leert u om na te denken over berichtenuitwisselingssystemen op basis van brokers, door twee populaire brokertechnologieën te vergelijken en tegenover elkaar te stellen: Apache ActiveMQ en Apache Kafka. Voor elke technologie worden gebruikscases en ontwikkelimpulsen besproken die hebben geleid tot totaal verschillende benaderingen van hetzelfde domein - de berichtenuitwisseling tussen systemen met een tussenliggende broker. We bekijken deze technologieën vanaf het begin en belichten de impact van verschillende ontwerpmogelijkheden onderweg. U krijgt een diepgaand begrip van beide producten, inzicht in hoe deze wel en niet moeten worden gebruikt, en oog voor wat belangrijk is bij de overweging van andere berichtenuitwisselingstechnologieën in de toekomst.
Voordat we beginnen, laten we de basisprincipes doorlopen.
Wat is een berichtenuitwisselingssysteem en waarom is het nodig?
Om ervoor te zorgen dat twee applicaties met elkaar kunnen communiceren, moeten ze eerst de interface bepalen. Het definiëren van deze interface omvat het kiezen van een transportmiddel of protocol, zoals HTTP, MQTT of SMTP, en het afstemmen van de berichtformaten die de systemen zullen uitwisselen. Dit kan een strikt proces zijn, zoals het definiëren van een XML-schema met vereisten voor de payload van het bericht, of het kan veel minder formeel zijn, bijvoorbeeld een afspraak tussen twee ontwikkelaars dat een bepaald deel van het HTTP-verzoek een klant-ID zal bevatten.
Zolang het formaat van de berichten en de volgorde van verzending tussen de systemen zijn afgestemd, kunnen ze met elkaar communiceren zonder zich zorgen te maken over de implementatie van het andere systeem. De interne werking van deze systemen, zoals de programmeertaal of de gebruikte framework, kan in de loop der tijd veranderen. Zolang het contract zelf wordt gehandhaafd, kan de interactie doorgaan zonder wijzigingen van de andere kant. Deze twee systemen zijn effectief van elkaar losgekoppeld door deze interface.
Messaging-systemen voorzien meestal in de deelname van een tussenpersoon tussen twee systemen die met elkaar interageren, voor verdere decoupling van de zender van de ontvanger of ontvangers. Het messaging-systeem stelt de zender in staat om een bericht te verzenden zonder te weten waar de ontvanger zich bevindt, of deze actief is, of hoeveel exemplaren er zijn.
Laten we een paar analogieën over de soorten problemen die een messaging-systeem oplost, bekijken en enkele basisbegrippen introduceren.
Point-to-Point
Alexandra gaat naar het postkantoor om een pakket naar Adam te versturen. Ze loopt naar de balie en geeft het pakket aan de medewerker. De medewerker neemt het pakket aan en geeft Alexandra een ontvangstbewijs. Adam hoeft niet thuis te zijn op het moment dat het pakket wordt verzonden. Alexandra is ervan overtuigd dat het pakket op een gegeven moment in de toekomst bij Adam zal worden afgeleverd en kan haar zaken blijven doen. Later ontvangt Adam het pakket.
Dit is een voorbeeld van een messaging-model point-to-point. Het postkantoor fungeert hier als een mechanisme voor het distribueren van pakketten, waarbij wordt gegarandeerd dat elk pakket eenmaal wordt afgeleverd. Het gebruik van het postkantoor scheidt de handeling van het verzenden van een pakket van de aflevering ervan.
In klassieke berichtensystemen wordt het model 'point-to-point' geïmplementeerd via wachtrijen. Een wachtrij fungeert als een FIFO-buffer (first in, first out), waarop een of meerdere consumenten zich kunnen abonneren. Elk bericht wordt alleen bezorgd aan één van de abonnees. Wachtrijen proberen doorgaans berichten eerlijk te verdelen tussen de consumenten. Slechts één consument ontvangt dit specifieke bericht.
De term 'betrouwbare' ('durable') wordt toegepast op wachtrijen. Betrouwbaarheid — dit is een eigenschap van de service die garandeert dat het berichten systeem berichten opslaat zolang er geen actieve abonnees zijn, totdat een consument zich abonneert op de wachtrij voor de aflevering van berichten.
Betrouwbaarheid wordt vaak verward met persistentie , en hoewel deze twee termen uitwisselbaar zijn, vervullen ze verschillende functies. Persistentie bepaalt of het berichten systeem een bericht opslaat in een soort opslag tussen het ontvangen en afgeven aan de consument. Berichten die naar een wachtrij worden verzonden, kunnen al dan niet persistent zijn.
Point-to-point messaging wordt gebruikt wanneer de use case een eenmalige actie met een bericht vereist. Bijvoorbeeld het storten van geld op een rekening of het plaatsen van een leveringsorder. We zullen later bespreken waarom het berichten systeem zelf niet in staat is om een eenmalige aflevering te garanderen en waarom wachtrijen in de beste gevallen alleen aflevering kunnen garanderen ten minste één keer.
Publisher-Subscriber
Gabriëlla belt het conferentienummer. Terwijl ze verbonden is met de conferentie, hoort ze alles wat de spreker zegt, samen met de andere deelnemers aan de oproep. Wanneer ze zich afmeldt, mist ze wat er gezegd is. Bij het opnieuw verbinden, hoort ze weer wat er wordt gezegd.
Dit is een voorbeeld van een messaging-model publicatie-abonnement. De conferentie heeft de functie van een broadcast-mechanisme. De spreker maakt zich geen zorgen over hoeveel mensen momenteel deelnemen aan de oproep — het systeem zorgt ervoor dat iedereen die op dat moment verbonden is, hoort wat er wordt gezegd.
In klassieke berichtensystemen wordt het publicatie-abonnementsmodel geïmplementeerd via topicsEen topic biedt een vergelijkbare manier van broadcasten als het mechanisme van conferentiegesprekken. Wanneer een bericht naar een topic wordt verzonden, wordt het verspreid over alle ingeschreven gebruikers..
Topics zijn meestal onbetrouwbaar (nondurable).Net zoals een luisteraar die niet hoort wat er wordt gezegd tijdens een conferentiegesprek wanneer de luisteraar wordt afgesneden, missen topicabonnees alle berichten die worden verzonden op het moment dat zij offline zijn. Om deze reden kan worden gesteld dat topics een aflevergarantie bieden van niet meer dan één keer voor elke consument.
Publicatie-abonnementscommunicatiemodellen worden meestal gebruikt wanneer berichten informatief van aard zijn en het verlies van één bericht niet van groot belang is. Bijvoorbeeld, een topic kan temperatuurmetingen van een groep sensoren één keer per seconde versturen. Een systeem dat geïnteresseerd is in de huidige temperatuur en dat zich heeft ingeschreven op het topic, zal zich geen zorgen maken als het een bericht mist - er zal spoedig een ander komen.
Hybride modellen.
De winkelwebsite plaatst bestelberichten in een 'berichtwachtrij'. De belangrijkste consument van deze berichten is het uitvoerende systeem. Daarnaast moet het auditsysteem kopieën van deze bestelberichten hebben voor latere opvolging. Beide systemen mogen geen berichten missen, zelfs niet als de systemen zelf gedurende een bepaalde tijd niet beschikbaar zijn. De website hoeft niet op de hoogte te zijn van de andere systemen.
Gebruiksscenario's vereisen vaak een combinatie van publicatie-abonnements- en point-to-point-berichtenmodellen, bijvoorbeeld wanneer meerdere systemen een kopie van het bericht nodig hebben, en waar zowel betrouwbaarheid als persistentie vereist is om het verlies van berichten te voorkomen.
In deze gevallen is een bestemmeling (destination) nodig (een algeme term voor wachtrijen en topics), die berichten voornamelijk distribueert als een topic, zodat elk bericht naar een afzonderlijk systeem dat geïnteresseerd is in deze berichten wordt verzonden, maar ook waarin elk systeem meerdere consumenten kan bepalen die de binnenkomende berichten ontvangen, wat meer op een wachtrij lijkt. Het type lezen in dit geval is één keer voor elke geïnteresseerde partij.Deze hybride adressen vereisen vaak betrouwbaarheid, dus als de consument wordt losgekoppeld, worden de berichten die tijdens deze tijd worden verzonden, na opnieuw verbinden van de consument geaccepteerd.
Hybride modellen zijn niet nieuw en kunnen in de meeste berichten-systemen worden toegepast, waaronder zowel ActiveMQ (via virtuele of samengestelde adressen die onderwerpen en wachtrijen combineren) als Kafka (impliciet, als een fundamentele ontwerpeigenschap van haar adressen).
Nu we wat basis terminologie en begrip hebben van waar een berichten-systeem nuttig voor kan zijn, laten we naar de details gaan.
Vertaling uitgevoerd:
De volgende vertaalde sectie:
Wordt vervolgd…
Bron: habr.com
