Hallo iedereen!
Ik begon een klein boekje te vertalen:
«',
auteur: Jakub Korab, uitgever: O'Reilly Media, Inc., publicatiedatum: juni 2017, ISBN: 9781492049296.
Uit de inleiding van het boek:
' ... Dit boek leert u nadenken over berichtensystemen voor makelaars, waarbij u twee populaire makelaarstechnologieën vergelijkt en contrasteert: Apache ActiveMQ en Apache Kafka. Het zal de gebruiksscenario's en ontwikkelingsprikkels schetsen die hun ontwikkelaars ertoe brachten om zeer verschillende benaderingen op hetzelfde gebied te volgen: berichten uitwisselen tussen systemen met een tussenpersoon. We zullen deze technologieën vanaf de basis bekijken en gaandeweg de impact van verschillende ontwerpkeuzes benadrukken. U krijgt een diepgaand inzicht in beide producten, inzicht in hoe ze wel en niet moeten worden gebruikt, en inzicht in waar u op moet letten bij het overwegen van andere berichtentechnologieën in de toekomst ... "
Tot nu toe vertaalde delen:
Ik zal voltooide hoofdstukken posten zodra ze vertaald zijn.
HOOFDSTUK 1
Introductie
Systeem-naar-systeem-berichtenuitwisseling is een van de minst begrepen gebieden van IT. Als ontwikkelaar of architect bent u wellicht zeer bekend met verschillende raamwerken en databases. Het is echter waarschijnlijk dat u slechts een voorbijgaande bekendheid heeft met de manier waarop op makelaars gebaseerde berichtentechnologieën werken. Als u zich zo voelt, hoeft u zich geen zorgen te maken, u bevindt zich in goed gezelschap.
Mensen hebben doorgaans zeer beperkt contact met de berichteninfrastructuur. Ze maken vaak verbinding met een systeem dat lang geleden is gemaakt, of downloaden een distributie van internet, installeren deze in PROM en beginnen er code voor te schrijven. Nadat u de infrastructuur in PROM heeft uitgevoerd, kunnen de resultaten gemengd zijn: berichten gaan verloren door storingen, het verzenden werkt niet zoals u had verwacht, of makelaars 'hangen' uw producenten op of sturen geen berichten naar uw consumenten.
Klinkt bekend?
Een veelvoorkomend scenario is dat uw berichtcode voorlopig prima werkt. Tot het niet meer werkt. Deze periode zorgt ervoor dat iemand op zijn hoede is voor een vals gevoel van veiligheid, wat leidt tot meer code gebaseerd op valse overtuigingen over het fundamentele gedrag van de technologie. Wanneer er iets misgaat, wordt u geconfronteerd met een ongemakkelijke waarheid: dat u het onderliggende gedrag van het product of de door de auteurs gekozen afwegingen, zoals prestatie versus betrouwbaarheid, of transactionaliteit versus horizontale schaalbaarheid, niet echt hebt begrepen. .
Zonder een diep begrip van hoe makelaars werken, doen mensen ogenschijnlijk redelijke uitspraken over hun berichtensystemen, zoals:
- Het systeem zal nooit berichten kwijtraken
- Berichten worden opeenvolgend verwerkt
- Door consumenten toe te voegen, wordt het systeem sneller
- 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 hoe u na kunt denken over op makelaars gebaseerde berichtensystemen, waarbij u twee populaire makelaarstechnologieën vergelijkt en contrasteert: Apache ActiveMQ en Apache Kafka. Het zal de gebruiksscenario's en ontwikkelingsprikkels schetsen die hun ontwikkelaars ertoe brachten om zeer verschillende benaderingen op hetzelfde gebied te volgen: berichten uitwisselen tussen systemen met een tussenpersoon. We zullen deze technologieën vanaf de basis bekijken en gaandeweg de impact van verschillende ontwerpkeuzes benadrukken. U krijgt een diepgaand inzicht in beide producten, inzicht in hoe ze wel en niet moeten worden gebruikt, en inzicht in waar u op moet letten als u in de toekomst andere berichtentechnologieën overweegt.
Voordat we beginnen, laten we de basisbeginselen doornemen.
Wat is een berichtensysteem en waarom is het nodig?
Om twee applicaties met elkaar te laten communiceren, moeten ze eerst een interface definiëren. Het definiëren van deze interface omvat het selecteren van een transport of protocol, zoals HTTP, MQTT of SMTP, en het onderhandelen over de berichtformaten die tussen de systemen zullen worden uitgewisseld. Dit kan een strikt proces zijn, zoals het definiëren van een XML-schema met kostenvereisten voor de payload van berichten, of het kan veel minder formeel zijn, zoals een overeenkomst tussen twee ontwikkelaars dat een deel van het HTTP-verzoek de client-ID zal bevatten.
Zolang het formaat van de berichten en de volgorde waarin ze worden verzonden consistent zijn tussen systemen, kunnen ze met elkaar communiceren zonder zich zorgen te hoeven maken over de implementatie van het andere systeem. De interne onderdelen van deze systemen, zoals de gebruikte programmeertaal of het gebruikte raamwerk, kunnen in de loop van de tijd veranderen. Zolang het contract zelf in stand blijft, kan de interactie doorgaan zonder veranderingen van de andere kant. Door deze interface worden de twee systemen effectief ontkoppeld (gescheiden).
Bij berichtensystemen is doorgaans sprake van een tussenpersoon tussen twee systemen die samenwerken om de afzender verder te ontkoppelen (scheiden) van de ontvanger of ontvangers. In dit geval stelt het berichtensysteem de afzender in staat een bericht te verzenden zonder te weten waar de ontvanger zich bevindt, of hij actief is en hoeveel exemplaren er zijn.
Laten we eens kijken naar een paar analogieën voor het soort problemen dat een berichtensysteem oplost en enkele basistermen introduceren.
Point-to-Point
Alexandra gaat naar het postkantoor om Adam een pakketje te sturen. Ze loopt naar het raam en overhandigt het pakketje aan de medewerker. De medewerker haalt het pakket op en geeft Alexandra een ontvangstbewijs. Adam hoeft niet thuis te zijn als het pakketje wordt verzonden. Alexandra heeft er vertrouwen in dat het pakketje op een bepaald moment in de toekomst bij Adam zal worden afgeleverd en haar gang kan blijven gaan. Later ontvangt Adam op een gegeven moment een pakketje.
Dit is een voorbeeld van een berichtenmodel punt naar punt. Het postkantoor fungeert hier als pakketdistributiemechanisme en zorgt ervoor dat elk pakket één keer wordt afgeleverd. Het gebruik van een postkantoor scheidt het verzenden van een pakket van de bezorging van het pakket.
In klassieke berichtensystemen wordt het point-to-point-model geïmplementeerd via wachtrijen. De wachtrij fungeert als een FIFO-buffer (first in, first out) waarop een of meer consumenten zich kunnen abonneren. Elk bericht wordt alleen afgeleverd aan een van de geabonneerde consumenten. Wachtrijen proberen doorgaans berichten eerlijk onder consumenten te verdelen. Slechts één consument ontvangt dit bericht.
Op wachtrijen wordt de term ‘duurzaam’ toegepast. Betrouwbaarheid is een service-eigenschap die ervoor zorgt dat het berichtensysteem berichten blijft bewaren bij afwezigheid van actieve abonnees totdat een consument zich abonneert op de wachtrij voor berichtbezorging.
Betrouwbaarheid wordt vaak verward met vasthoudendheid en hoewel de twee termen door elkaar worden gebruikt, dienen ze verschillende functies. Persistentie bepaalt of het berichtensysteem een bericht naar een bepaalde opslagplaats schrijft tussen het ontvangen ervan en het verzenden ervan naar de consument. Berichten die naar de wachtrij worden verzonden, kunnen al dan niet persistent zijn.
Point-to-point-berichten worden gebruikt wanneer de use-case een eenmalige actie op het bericht vereist. Voorbeelden hiervan zijn het storten van geld op een rekening of het voltooien van een leveringsopdracht. We zullen later bespreken waarom het berichtensysteem op zichzelf niet in staat is om een eenmalige bezorging te bieden en waarom wachtrijen op zijn best een bezorggarantie kunnen bieden ten minste een keer.
Uitgever-abonnee
Gabriella belt het conferentienummer. Terwijl ze verbonden is met de conferentie, hoort ze alles wat de spreker zegt, samen met de rest van de gespreksdeelnemers. Als ze afstemt, mist ze wat er gezegd wordt. Als ze weer verbinding heeft, blijft ze horen wat er wordt gezegd.
Dit is een voorbeeld van een berichtenmodel publiceren-abonneren. Conferentiegesprekken fungeren als uitzendmechanisme. Het maakt de spreker niet uit hoeveel mensen er momenteel aan het bellen zijn; het systeem zorgt ervoor dat iedereen die momenteel verbonden is, kan horen wat er gezegd wordt.
In klassieke berichtensystemen wordt het berichtenmodel voor publiceren en abonneren geïmplementeerd via onderwerpen. Topic biedt dezelfde uitzendmethode als het conferentiemechanisme. Wanneer een bericht naar een onderwerp wordt verzonden, wordt het verspreid voor alle geabonneerde gebruikers.
Onderwerpen zijn meestal onbetrouwbaar (niet duurzaam). Net als een luisteraar die niet kan horen wat er tijdens een telefonische vergadering wordt gezegd wanneer de luisteraar de verbinding verbreekt, missen onderwerpabonnees alle berichten die worden verzonden terwijl ze offline zijn. Om deze reden kunnen we zeggen dat onderwerpen een leveringsgarantie bieden niet vaker dan één keer voor elke consument.
Publish-subscribe-berichten worden doorgaans gebruikt wanneer de berichten informatief van aard zijn en het verlies van één bericht niet bijzonder significant is. Een onderwerp kan bijvoorbeeld één keer per seconde temperatuurmetingen van een groep sensoren verzenden. Een systeem dat geïnteresseerd is in de huidige temperatuur en zich op een onderwerp abonneert, zal zich geen zorgen maken als het een bericht mist: er komt in de nabije toekomst een ander bericht.
hybride modellen
De website van de winkel plaatst bestelberichten in een 'berichtenwachtrij'. De belangrijkste consument van deze berichten is het uitvoerende systeem. Bovendien moet het auditsysteem kopieën van deze bestelberichten hebben voor latere tracking. Beide systemen kunnen geen berichten doorlaten, ook al zijn de systemen zelf enige tijd niet beschikbaar. De website mag geen kennis hebben van andere systemen.
Gebruiksscenario's vereisen vaak een combinatie van publiceren-abonneren en point-to-point-berichtenmodellen, bijvoorbeeld wanneer meerdere systemen een kopie van een bericht vereisen en zowel betrouwbaarheid als persistentie vereist zijn om berichtverlies te voorkomen.
Deze gevallen vereisen een bestemming (een algemene term voor wachtrijen en onderwerpen) die berichten in principe als onderwerp verspreidt, zodat elk bericht naar een afzonderlijk systeem wordt gestuurd dat geïnteresseerd is in die berichten, maar ook waarin elk systeem verschillende consumenten kan definiëren die inkomende berichten ontvangen. berichten, wat meer op een wachtrij lijkt. Het leestype is in dit geval één keer voor elke belanghebbende. Deze hybride bestemmingen vereisen vaak duurzaamheid, zodat als een consument offline gaat, berichten die op dat moment worden verzonden, worden ontvangen nadat de consument opnieuw verbinding heeft gemaakt.
Hybride modellen zijn niet nieuw en kunnen in de meeste berichtensystemen worden gebruikt, waaronder zowel ActiveMQ (via virtuele of samengestelde bestemmingen die onderwerpen en wachtrijen combineren) als Kafka (impliciet, als een fundamentele eigenschap van het bestemmingsontwerp).
Nu we wat basisterminologie hebben en begrijpen waarvoor we een berichtensysteem zouden kunnen gebruiken, gaan we tot de details overgaan.
Vertaling gedaan:
Het volgende vertaalde deel:
Wordt vervolgd ...
Bron: www.habr.com