Hallo almal!
Ek het 'n klein boekie begin vertaal:
«',
skrywer: Jakub Korab, uitgewer: O'Reilly Media, Inc., datum van publikasie: Junie 2017, ISBN: 9781492049296.
Uit die inleiding tot die boek:
"... Hierdie boek sal jou leer hoe om oor makelaarboodskapstelsels te dink, en twee gewilde makelaartegnologieë te vergelyk en te kontrasteer: Apache ActiveMQ en Apache Kafka. Dit sal die gebruiksgevalle en ontwikkelingsaansporings uiteensit wat daartoe gelei het dat hul ontwikkelaars baie verskillende benaderings tot dieselfde area volg - boodskappe tussen stelsels met 'n intermediêre makelaar. Ons sal van die grond af na hierdie tegnologieë kyk en die impak van verskeie ontwerpkeuses langs die pad uitlig. Jy sal 'n diepgaande begrip van beide produkte kry, 'n begrip van hoe hulle moet en nie gebruik moet word nie, en 'n begrip van waarna om te kyk wanneer ander boodskaptegnologieë in die toekoms oorweeg word … »
Dele tot dusver vertaal:
Ek sal voltooide hoofstukke plaas soos dit vertaal word.
HOOFSTUK 1
Inleiding
Stelsel-tot-stelsel-boodskappe is een van die areas van IT wat die minste verstaan word. As 'n ontwikkelaar of argitek is jy dalk baie vertroud met verskeie raamwerke en databasisse. Dit is egter waarskynlik dat jy net 'n verbygaande vertroudheid het met hoe makelaar-gebaseerde boodskaptegnologieë werk. As jy so voel, moenie bekommerd wees nie, jy is in goeie geselskap.
Mense het gewoonlik baie beperkte kontak met die boodskap-infrastruktuur. Hulle koppel dikwels aan 'n stelsel wat lank gelede geskep is, of laai 'n verspreiding van die internet af, installeer dit in PROM en begin kode daarvoor skryf. Nadat u die infrastruktuur in PROM bestuur het, kan die resultate gemeng word: boodskappe gaan verlore as gevolg van mislukkings, stuur werk nie soos u verwag het nie, of makelaars “hang” u produsente of stuur nie boodskappe aan u verbruikers nie.
Klink dit bekend?
'n Algemene scenario is waar jou boodskapkode vir eers uitstekend werk. Totdat dit ophou werk. Hierdie tydperk sluimer 'n mens se wag in 'n valse gevoel van sekuriteit, wat lei tot meer kode gebaseer op valse oortuigings oor die fundamentele gedrag van die tegnologie. Wanneer dinge begin verkeerd loop, kom jy voor 'n ongerieflike waarheid te staan: dat jy nie regtig die onderliggende gedrag van die produk of die afwegings wat deur die skrywers gekies is, verstaan het nie, soos prestasie teenoor betroubaarheid, of transaksionaliteit teenoor horisontale skaalbaarheid .
Sonder 'n diep begrip van hoe makelaars werk, maak mense skynbaar redelike stellings oor hul boodskapstelsels, soos:
- Die stelsel sal nooit boodskappe verloor nie
- Boodskappe sal opeenvolgend verwerk word
- Die byvoeging van verbruikers sal die stelsel vinniger maak
- Boodskappe sal net een keer afgelewer word
Ongelukkig is sommige van hierdie stellings gebaseer op aannames wat slegs onder sekere omstandighede geld, terwyl ander bloot verkeerd is.
Hierdie boek sal jou leer hoe om oor makelaar-gebaseerde boodskapstelsels te dink, en twee gewilde makelaartegnologieë te vergelyk en te kontrasteer: Apache ActiveMQ en Apache Kafka. Dit sal die gebruiksgevalle en ontwikkelingsaansporings uiteensit wat daartoe gelei het dat hul ontwikkelaars baie verskillende benaderings tot dieselfde area volg - boodskappe tussen stelsels met 'n intermediêre makelaar. Ons sal van die grond af na hierdie tegnologieë kyk en die impak van verskeie ontwerpkeuses langs die pad uitlig. Jy sal 'n diepgaande begrip van beide produkte kry, 'n begrip van hoe hulle moet en nie gebruik moet word nie, en 'n begrip van waarna om te kyk wanneer ander boodskaptegnologieë in die toekoms oorweeg word.
Voordat ons begin, kom ons gaan oor die basiese beginsels.
Wat is 'n boodskapstelsel en hoekom is dit nodig?
Om twee toepassings met mekaar te laat kommunikeer, moet hulle eers 'n koppelvlak definieer. Om hierdie koppelvlak te definieer behels die keuse van 'n vervoer of protokol, soos HTTP, MQTT of SMTP, en die onderhandeling van die boodskapformate wat tussen die stelsels uitgeruil sal word. Dit kan 'n streng proses wees, soos om 'n XML-skema te definieer met boodskaploonvragkostevereistes, of dit kan baie minder formeel wees, soos 'n ooreenkoms tussen twee ontwikkelaars dat 'n deel van die HTTP-versoek die kliëntidentifiseerder sal bevat.
Solank die formaat van boodskappe en die volgorde waarin dit gestuur word konsekwent tussen stelsels is, kan hulle met mekaar kommunikeer sonder om bekommerd te wees oor die ander stelsel se implementering. Die interne van hierdie stelsels, soos die programmeertaal of raamwerk wat gebruik word, kan met verloop van tyd verander. Solank die kontrak self gehandhaaf word, kan die interaksie voortgaan sonder veranderinge van die ander kant. Die twee stelsels word effektief deur hierdie koppelvlak ontkoppel (geskei).
Boodskapstelsels behels tipies 'n tussenganger tussen twee stelsels wat interaksie het om die sender verder van die ontvanger of ontvangers te ontkoppel (skei). In hierdie geval laat die boodskapstelsel die sender toe om 'n boodskap te stuur sonder om te weet waar die ontvanger is, of hy aktief is, of hoeveel gevalle daar is.
Kom ons kyk na 'n paar analogieë vir die soort probleme wat 'n boodskapstelsel oplos en stel 'n paar basiese terme bekend.
Punt-tot-punt
Alexandra gaan na die poskantoor om vir Adam 'n pakkie te stuur. Sy gaan na die venster en gee die pakkie aan die werknemer. Die werknemer tel die pakkie op en gee vir Alexandra 'n kwitansie. Adam hoef nie tuis te wees wanneer die pakkie gestuur word nie. Alexandra is vol vertroue dat die pakkie een of ander tyd in die toekoms by Adam afgelewer sal word en kan voortgaan om haar besigheid te doen. Later op 'n stadium ontvang Adam 'n pakkie.
Dit is 'n voorbeeld van 'n boodskapmodel punt-tot-punt. Die poskantoor hier dien as 'n pakkieverspreidingsmeganisme, wat verseker dat elke pakkie een keer afgelewer word. Die gebruik van 'n poskantoor skei die handeling om 'n pakkie te stuur van die aflewering van die pakkie.
In klassieke boodskapstelsels word die punt-tot-punt-model deur geïmplementeer toue. Die tou dien as 'n EIEU (eerste in, eerste uit) buffer waarop een of meer verbruikers ingeteken kan word. Elke boodskap word slegs afgelewer aan een van die ingetekende verbruikers. Toue probeer gewoonlik om boodskappe regverdig onder verbruikers te versprei. Slegs een verbruiker sal hierdie boodskap ontvang.
Die term "duursaam" word op toue toegepas. Betroubaarheid is 'n dienseienskap wat verseker dat die boodskapstelsel boodskappe sal voortduur in die afwesigheid van aktiewe intekenare totdat 'n verbruiker inteken op die tou vir boodskapaflewering.
Betroubaarheid word dikwels verwar met volharding en alhoewel die twee terme uitruilbaar gebruik word, dien hulle verskillende funksies. Volharding bepaal of die boodskapstelsel 'n boodskap na 'n soort berging skryf tussen die ontvangs daarvan en die stuur daarvan aan die verbruiker. Boodskappe wat na die tou gestuur word, kan of mag nie aanhoudend wees nie.
Punt-tot-punt boodskappe word gebruik wanneer die gebruiksgeval 'n eenmalige handeling op die boodskap vereis. Voorbeelde sluit in die inbetaling van fondse in 'n rekening of die voltooiing van 'n afleweringsbestelling. Ons sal later bespreek waarom die boodskapstelsel op sy eie nie in staat is om eenmalige aflewering te verskaf nie en waarom toue op sy beste afleweringswaarborg kan bied ten minste een keer.
Uitgewer-Intekenaar
Gabriella skakel die konferensienommer. Terwyl sy aan die konferensie gekoppel is, hoor sy alles wat die spreker sê, saam met die res van die oproepdeelnemers. Wanneer sy uitskakel, mis sy wat gesê word. Wanneer sy weer verbind word, gaan sy voort om te hoor wat gesê word.
Dit is 'n voorbeeld van 'n boodskapmodel publiseer-teken in. Konferensie-oproepe dien as 'n uitsaaimeganisme. Die persoon wat praat gee nie om hoeveel mense tans op die oproep is nie – die stelsel verseker dat enigiemand wat tans gekoppel is, sal hoor wat gesê word.
In klassieke boodskapstelsels word die publiseer-teken-boodskapmodel deur geïmplementeer tops. Onderwerp verskaf dieselfde uitsaaimetode as die konferensiemeganisme. Wanneer 'n boodskap na 'n onderwerp gestuur word, word dit versprei vir alle ingetekende gebruikers.
Onderwerpe is gewoonlik onbetroubaar (onduursaam). Net soos 'n luisteraar wat nie kan hoor wat op 'n konferensie-oproep gesê word wanneer die luisteraar ontkoppel nie, mis onderwerpintekenare enige boodskappe wat gestuur word terwyl hulle vanlyn is. Om hierdie rede kan ons sê dat onderwerpe 'n afleweringswaarborg bied nie meer as een keer nie vir elke verbruiker.
Publiseer-inteken boodskappe word tipies gebruik wanneer die boodskappe inligting van aard is en die verlies van een boodskap nie besonder betekenisvol is nie. Byvoorbeeld, 'n onderwerp kan temperatuurlesings van 'n groep sensors een keer per sekonde oordra. ’n Stelsel wat in die huidige temperatuur belangstel en wat op ’n onderwerp inteken, sal nie bekommerd wees as dit ’n boodskap mis nie – nog een sal in die nabye toekoms opdaag.
hibriede modelle
Die winkel se webwerf plaas bestellingsboodskappe in 'n "boodskap-tou." Die hoofverbruiker van hierdie boodskappe is die uitvoerende stelsel. Daarbenewens moet die ouditstelsel afskrifte van hierdie bestellingsboodskappe hê vir daaropvolgende dop. Albei stelsels kan nie toelaat dat boodskappe deurgaan nie, selfs al is die stelsels self vir 'n geruime tyd onbeskikbaar. Die webwerf moet nie bewus wees van ander stelsels nie.
Gebruiksgevalle vereis dikwels 'n kombinasie van publiseer-inteken en punt-tot-punt-boodskapmodelle, soos wanneer veelvuldige stelsels 'n kopie van 'n boodskap vereis en beide betroubaarheid en volharding word vereis om boodskapverlies te voorkom.
Hierdie gevalle vereis 'n bestemming ('n algemene term vir toue en onderwerpe) wat boodskappe basies as 'n onderwerp versprei, sodat elke boodskap gestuur word na 'n aparte stelsel wat in daardie boodskappe belangstel, maar ook waarin elke stelsel verskeie verbruikers kan definieer wat inkomende ontvang boodskappe, wat meer soos 'n tou is. Die leestipe in hierdie geval is een keer vir elke belanghebbende. Hierdie hibriede bestemmings vereis dikwels duursaamheid sodat as 'n verbruiker vanlyn gaan, boodskappe wat op daardie tydstip gestuur word, ontvang word nadat die verbruiker weer gekoppel is.
Hibriede modelle is nie nuut nie en kan in die meeste boodskapstelsels gebruik word, insluitend beide ActiveMQ (via virtuele of saamgestelde bestemmings wat onderwerpe en rye kombineer) en Kafka (implisiet, as 'n fundamentele eienskap van sy bestemmingsontwerp).
Noudat ons 'n paar basiese terminologie en 'n begrip het van waarvoor ons 'n boodskapstelsel kan gebruik, kom ons gaan na die besonderhede.
Vertaling gedoen:
Die volgende vertaalde deel:
Vervolg…
Bron: will.com