Zerk behartu lezake Lamoda bezalako enpresa handi bat, prozesu arin batekin eta elkarri konektatutako hamaika zerbitzurekin, bere ikuspegia nabarmen aldatzera? Motibazioa guztiz ezberdina izan daiteke: legegintzalditik hasi eta programatzaile guztien berezko esperimentazio nahiera arte.
Baina horrek ez du esan nahi onura gehigarriekin kontatu ezin denik. Sergey Zaikak esango dizu zer irabaz dezakezun zehatz-mehatz Kafkan gertaeren araberako APIa ezartzen baduzu (). Zalantzarik gabe, plano handiei eta aurkikuntza interesgarriei buruz ere hitz egingo da - esperimentuak ezin du haiek gabe egin.
Lege-oharra: artikulu hau Sergeyk 2018ko azaroan HighLoad++-en egin zuen topaketa bateko materialetan oinarritzen da. Lamodak Kafkarekin lan egiteko zuzeneko esperientziak entzuleak erakarri zituen programazioaren beste erreportajeek baino gutxiago. Uste dugu hau beti ideia berdineko jendea aurki dezakezula eta aurkitu behar duzularen adibide bikaina dela, eta HighLoad++-ko antolatzaileek horretarako giro egokia sortzen saiatzen jarraituko dute.
Prozesuari buruz
Lamoda merkataritza elektronikoko plataforma handi bat da, bere kontaktu-zentroa, entrega-zerbitzua (eta afiliatu asko), argazki-estudioa, biltegi erraldoia eta hori guztia bere software propioan exekutatzen duena. Dozenaka ordainketa-metodo daude, zerbitzu horiek guztiak edo batzuk erabil ditzaketen b2b bazkideak eta beren produktuei buruzko informazio eguneratua ezagutu nahi dutenak. Horrez gain, Lamodak Errusiar Federazioaz gain hiru herrialdetan jarduten du eta han dena apur bat ezberdina da. Guztira, ziurrenik ehun modu baino gehiago egongo dira eskaera berri bat konfiguratzeko, bere erara prozesatu behar direnak. Horrek guztiak, batzuetan begi bistakoak ez diren moduetan komunikatzen diren dozenaka zerbitzuren laguntzarekin funtzionatzen du. Sistema zentral bat ere badago, bere ardura nagusia ordena-egoerak dituena. BOB deitzen diogu, berarekin lan egiten dut.
Itzulketa-tresna gertaeretan oinarritutako APIarekin
Gertaetek bultzatutako hitza nahiko makala da; pixka bat gehiago zehatzago zehaztuko dugu zer esan nahi duen honekin. Kafkan gertaeren araberako API ikuspegia probatzea erabaki genuen testuinguruarekin hasiko naiz.
Edozein dendatan, bezeroek ordaintzen dituzten eskaerez gain, dendak dirua itzultzeko eskatzen zaion une batzuetan, produktua bezeroari egokitzen ez zaiolako. Prozesu labur samarra da hau: informazioa argitzen dugu, behar izanez gero, eta dirua transferitzen dugu.
Baina itzulera zaildu egin zen legediaren aldaketen ondorioz, eta horretarako mikrozerbitzu bereizia ezarri behar izan genuen.
Gure motibazioa:
- FZ-54 Legea - Laburbilduz, legeak zerga-bulegoari diru-transakzio bakoitzari buruz jakinaraztea eskatzen du, izan itzulera edo ordainagiria, minutu gutxiko SLA nahiko labur baten barruan. Guk, merkataritza elektronikoko enpresa gisa, eragiketa dezente egiten ditugu. Teknikoki, horrek erantzukizun berria (eta, beraz, zerbitzu berria) eta inplikatutako sistema guztietan hobekuntzak suposatzen ditu.
- BOB zatitu enpresaren barne-proiektu bat da, BOB ez-oinarrizko erantzukizun ugarietatik arintzeko eta bere konplexutasun orokorra murrizteko.
Diagrama honek Lamoda sistema nagusiak erakusten ditu. Orain gehienak gehiago dira 5-10 mikrozerbitzuen konstelazio bat uzkurtzen ari den monolito baten inguruan. Poliki-poliki hazten ari dira, baina txikiagoak egiten saiatzen ari gara, erdian hautatutako zatia zabaltzea beldurgarria delako - ezin dugu erortzen utzi. Truke guztiak (geziak) erreserbatzera behartuta gaude eta haietakoren bat erabilgarri egon daitekeela kontuan hartzen dugu.
BOBek ere truke dezente ditu: ordainketa sistemak, entrega sistemak, jakinarazpen sistemak, etab.
Teknikoki BOB hau da:
- ~150k kode-lerro + ~100k proba-lerro;
- php7.2 + Zend 1 eta Symfony osagaiak 3;
- > 100 API eta ~50 irteerako integrazio;
- Negozio logika propioa duten 4 herrialde.
BOB hedatzea garestia eta mingarria da, konpontzen dituen kode eta arazoen kopurua inork ezin duela dena buruan sartu. Oro har, arrazoi asko daude sinplifikatzeko.
Itzulketa Prozesua
Hasieran, bi sistemak parte hartzen dute prozesuan: BOB eta Ordainketa. Orain beste bi agertzen dira:
- Fiskalizazio Zerbitzua, fiskalizazio arazoak eta kanpoko zerbitzuekiko komunikazioa zainduko duena.
- Itzulketa-tresna, truke berriak besterik ez dituena, BOB-a ez puzteko.
Orain prozesua honelakoa da:
- BOBek itzultzeko eskaera jasotzen du.
- BOB Itzulketa-tresna honi buruz hitz egiten du.
- Itzulketa-tresnak Ordainketari esaten dio: "Itzuli dirua".
- Ordainketak dirua itzultzen du.
- Refund Tool eta BOB egoerak elkarren artean sinkronizatzen dituzte, oraingoz biek behar dutelako. Oraindik ez gaude prest Itzulketa-tresnara guztiz aldatzeko, BOB-ek UI bat, kontabilitate-txostenak eta, oro har, hain erraz transferitu ezin diren datu asko baititu. Bi aulkitan eseri behar duzu.
- Fiskalizazio eskaera desagertzen da.
Ondorioz, ekitaldi-bus moduko bat egin genuen Kafkan - gertaera-autobusa, eta bertan dena hasi zen. Aupa, orain hutsegite puntu bakarra dugu (sarkasmoa).
Alde onak eta txarrak nahiko agerikoak dira. Autobus bat egin genuen, hau da, orain zerbitzu guztiak horren menpekoak dira. Honek diseinua errazten du, baina hutsegite puntu bakarra sartzen du sisteman. Kafkak huts egingo du, prozesua geldituko da.
Zer da gertaerak gidatutako API bat
Galdera honi erantzun ona Martin Fowler-en txostenean dago (GOTO 2017) .
Laburbilduz zer egin genuen:
- Bilatu truke asinkrono guztiak bidez gertaeren biltegiratzea. Interesa duten kontsumitzaile guztiei sarean egoera-aldaketa baten berri eman beharrean, biltegiratze zentralizatuko egoera-aldaketari buruzko gertaera bat idazten dugu, eta gaian interesa duten kontsumitzaileek hortik agertzen den guztia irakurtzen dute.
- Kasu honetan gertaera jakinarazpen bat da (jakinarazpenak) zerbait aldatu dela nonbait. Adibidez, eskaeraren egoera aldatu egin da. Jakinarazpenean jasotzen ez diren egoera-aldaketarekin batera datozen datu batzuetan interesa duen kontsumitzaileak berak jakin dezake haren egoera.
- Gehienezko aukera gertaeren iturri osoa da, estatu transferentzia, ekitaldi horretan prozesatzeko beharrezkoa den informazio guztia jasotzen du: nondik datorren eta zein egoeratan joan den, datuak nola aldatu diren zehazki, etab. Galdera bakarra bideragarritasuna eta gorde dezakezun informazio kopurua da.
Itzulketa tresnaren abiaraztearen baitan, hirugarren aukera erabili dugu. Gertaeren prozesamendua sinplifikatu zen, informazio zehatza atera beharrik ez zegoenez, eta, gainera, gertaera berri bakoitzak kontsumitzaileen eskaerak argitzeko leherketa sortzen duen eszenatokia ezabatu zuen.
Itzulketa-tresna zerbitzua kargatu gabe, beraz, Kafka luma zaporea behar baino gehiago dago. Ez dut uste itzulketa zerbitzua karga handiko proiektu bat bihurtuz gero, negozioak pozik egongo zirenik.
Truke asinkronikoa BEZALA
Truke asinkronoetarako, PHP sailak RabbitMQ erabiltzen du normalean. Eskaeraren datuak bildu, ilaran jarri, eta zerbitzu bereko kontsumitzaileak irakurri eta bidali (edo ez zuen bidali). APIrako, Lamodak aktiboki erabiltzen du Swagger. API bat diseinatzen dugu, Swagger-en deskribatzen dugu eta bezero eta zerbitzariaren kodea sortzen dugu. JSON RPC 2.0 apur bat hobetua ere erabiltzen dugu.
Leku batzuetan ESB autobusak erabiltzen dira, batzuk activeMQ-n bizi dira, baina, oro har, RabbitMQ - estandarra.
Truke asinkronikoa IZAN
Gertaeren-bus bidez trukea diseinatzean, analogia bat egin daiteke. Era berean, etorkizuneko datu-trukea gertaeren egitura deskribapenen bidez deskribatzen dugu. Yaml formatua, guk geuk egin behar genuen kodea sortzea, sorgailuak DTOak zehaztapenaren arabera sortzen ditu eta bezeroei eta zerbitzariei eurekin lan egiten irakasten die. Belaunaldia bi hizkuntzatara doa - golang eta php. Horrek liburutegiak koherente mantentzen laguntzen du. Sorgailua golangez idatzita dago, horregatik gogi izena hartu zuen.
Kafka-n gertaera-sourcing ohiko gauza bat da. Kafka Confluent-en enpresa-bertsio nagusiaren irtenbide bat dago, badago , gure domeinu anaien Zalandoren irtenbidea. Gure bainila Kafkarekin hasteko motibazioa - horrek esan nahi du irtenbidea libre uztea edonon erabiliko dugun erabaki arte, eta, gainera, maniobra eta hobekuntzarako tartea uztea: gure laguntza nahi dugu. JSON RPC 2.0, bi hizkuntzetarako sorgailuak eta ea zer gehiago.
Ironikoa da halako kasu alai batean ere, gutxi gorabehera antzeko negozio bat dagoenean, Zalando, gutxi gorabehera antzeko irtenbidea egin zuena, ezin dugula eraginkortasunez erabili.
Abian jarritako eredu arkitektonikoa honakoa da: Kafkatik zuzenean irakurtzen dugu, baina gertaeren-bus bidez soilik idazten dugu. Asko dago prest irakurtzeko Kafkan: artekariak, orekatzaileak, eta gutxi-asko prest dago eskalatze horizontalerako, hau mantendu nahi nuen. Grabaketa Gateway aka Events-bus baten bidez osatu nahi genuen, eta hona hemen zergatik.
Ekitaldiak-autobusa
Edo ekitaldien autobusa. Estaturik gabeko http atebide bat besterik ez da, eta hainbat rol garrantzitsu hartzen ditu:
- Balioztatzea ekoiztea — ekitaldiek gure zehaztapenak betetzen dituztela egiaztatzen dugu.
- Gertaeren sistema nagusia, hau da, zein ekitaldirekin zein egiturekin baliozkotzat jotzen diren galderari erantzuten dion enpresaren sistema nagusia eta bakarra. Balioztatzeak datu-motak eta enumerazioak besterik ez ditu barne hartzen, edukia zorrotz zehazteko.
- Hash funtzioa zatiketa egiteko - Kafka mezuaren egitura gako-balioa da eta gako hash-a erabiliz non jarri behar den kalkulatzen da.
Zergatik
Enpresa handi batean lan egiten dugu prozesu arin batekin. Zergatik aldatu ezer? Hau esperimentu bat da, eta hainbat onura ateratzea espero dugu.
1:n+1 trukeak (bat eta asko)
Kafkak oso erraza da kontsumitzaile berriak APIra konektatzea.
Demagun hainbat sistema aldi berean (eta berri batzuetan) eguneratuta eduki behar duzun direktorio bat duzula. Aurretik, set-API inplementatzen zuen sorta bat asmatu genuen, eta sistema nagusiari kontsumitzaileen helbideen berri eman zitzaion. Orain sistema nagusiak gaiaren eguneraketak bidaltzen ditu, eta interesa duten guztiek irakurtzen dute. Sistema berri bat agertu da - sinatu dugu gairako. Bai, sorta ere bai, baina sinpleagoa.
BOB zati bat den itzulketa-tresnaren kasuan, komenigarria zaigu Kafkaren bidez sinkronizatuta mantentzea. Ordainketak dio dirua itzuli zela: BOB, RT-k horren berri izan zuten, egoera aldatu zuten, Fiskalizazio Zerbitzuak horren berri izan eta txeke bat eman zuten.
Jakinarazpen Zerbitzu bateratu bat sortzeko asmoa dugu, bezeroari bere eskaera/itzulketei buruzko berrien berri emango diona. Orain ardura hori sistemen artean zabaltzen da. Nahikoa izango zaigu Jakinarazpen Zerbitzuari Kafkaren informazio garrantzitsua harrapatzen eta horri erantzuten irakastea (eta beste sistema batzuetan jakinarazpen hauek desgaitzen). Ez da zuzeneko truke berririk beharko.
Datuetan oinarrituta
Sistemen arteko informazioa gardena bihurtzen da - ez du axola zer "enpresa odoltsua" duzun eta ez du axola zenbaterainokoa den zure atzerapena. Lamodak Datuen Analitika sail bat du, sistemetatik datuak bildu eta forma berrerabilgarri batean jartzen dituena, bai negozioetarako bai sistema adimendunetarako. Kafkak datu asko azkar emateko eta informazio-fluxu hori eguneratuta mantentzeko aukera ematen du.
Erreplikazioen erregistroa
Mezuak ez dira desagertzen irakurri ondoren, RabbitMQ-n bezala. Gertaera batek prozesatzeko behar adina informazio duenean, objektuaren azken aldaketen historia dugu, eta, nahi izanez gero, aldaketa horiek aplikatzeko gaitasuna.
Erreplikazio-erregistroaren biltegiratze-aldia gai honi idazteko intentsitatearen araberakoa da; Kafkak biltegiratze-denboraren eta datu-bolumenaren mugak malgutasunez ezartzeko aukera ematen du. Gai intentsiboetarako, garrantzitsua da kontsumitzaile guztiek informazio hori desagertu baino lehen irakurtzeko denbora izatea, baita epe laburreko funtzionamendurik ez dagoenean ere. Normalean posible da datuak gordetzeko egunen unitateak, nahikoa da laguntzarako.
Jarraian, dokumentazioaren berriketa txiki bat, Kafka ezagutzen ez dutenentzat (argazkia ere dokumentaziokoa da)
AMQP-k ilarak ditu: kontsumitzaileentzako ilara batean mezuak idazten ditugu. Normalean, ilara bat sistema batek prozesatzen du negozio-logika berarekin. Hainbat sistema jakinarazi behar badituzu, aplikazioari irakats diezaiokezu hainbat ilaratan idazten edo trukea konfiguratzen duen fanout mekanismoarekin, berak klonatzen dituena.
Kafkak antzeko abstrakzioa du Gaia, mezuak idazten dituzunean, baina irakurri ondoren ez dira desagertzen. Lehenespenez, Kafka-ra konektatzen zarenean, mezu guztiak jasotzen dituzu eta utzi zenuen tokian gordetzeko aukera duzu. Hau da, sekuentzialki irakurtzen baduzu, agian ez duzu mezua irakurritako gisa markatu, baina id-a gorde, gero irakurtzen jarraitu ahal izateko. Konfiguratu duzun IDari offset deitzen zaio eta mekanismoari konpromezuaren desplazamendua da.
Horren arabera, logika desberdinak ezarri daitezke. Esate baterako, BOB dugu 4 kasutan herrialde desberdinetarako - Lamoda Errusian, Kazakhstanen, Ukrainan, Bielorrusian dago. Bereizita zabaltzen direnez, konfigurazio apur bat desberdinak dituzte eta negozio-logika propioa dute. Mezuan zein herrialderi egiten dion erreferentzia adierazten dugu. Herrialde bakoitzeko BOB kontsumitzaile bakoitzak groupId ezberdin batekin irakurtzen du, eta mezua aplikatzen ez bazaie, saltatzen dute, hau da. berehala konpentsatzen du +1 offset. Gure Ordainketa Zerbitzuak gai bera irakurtzen badu, talde ezberdin batekin egingo du, eta, beraz, konpentsazioak ez dira gurutzatzen.
Ekitaldiaren baldintzak:
- Datuen osotasuna. Ekitaldiak nahikoa datu izatea gustatuko litzaidake prozesatu ahal izateko.
- Osotasuna. Events-bus-i delegatzen diogu gertaera koherentea dela eta prozesatu dezakeen egiaztapena.
- Ordena garrantzitsua da. Itzulera baten kasuan, historiarekin lan egitera behartuta gaude. Jakinarazpenekin, eskaera ez da garrantzitsua, jakinarazpen homogeneoak badira, posta elektronikoa berdina izango da edozein dela ere lehenengo zein eskaera iritsi den. Itzulketa baten kasuan, prozesu argia dago; eskaera aldatzen badugu, salbuespenak sortuko dira, itzulketa ez da sortuko edo prozesatu - beste egoera batean amaituko dugu.
- Koherentzia. Denda bat dugu, eta orain API baten ordez gertaerak sortzen ditugu. Gertaera berriei eta lehendik daudenei egindako aldaketei buruzko informazioa azkar eta merke transmititzeko modu bat behar dugu gure zerbitzuetara. Hau git biltegi eta kode-sorgailu bereizi batean zehaztapen komun baten bidez lortzen da. Beraz, zerbitzu ezberdinetako bezeroak eta zerbitzariak koordinatzen dira.
Kafka Lamodan
Kafka hiru instalazio ditugu:
- Erregistroak;
- I+G;
- Ekitaldiak-autobusa.
Gaur azken puntuaz bakarrik ari gara. Ekitaldi-busean, ez ditugu instalazio oso handiak - 3 artekari (zerbitzariak) eta 27 gai bakarrik. Oro har, gai bat prozesu bat da. Baina hau puntu sotila da, eta orain ukituko dugu.
Goian rps grafikoa dago. Itzulketa-prozesua marra turkesa batekin markatuta dago (bai, X ardatzean dagoena), eta marra arrosa edukia eguneratzeko prozesua da.
Lamoda katalogoak milioika produktu ditu, eta datuak etengabe eguneratzen dira. Bilduma batzuk modatik pasatzen dira, horiek ordezkatzeko berriak kaleratzen dira eta katalogoan etengabe agertzen dira modelo berriak. Bihar gure bezeroentzat interesgarria izango dena iragartzen saiatzen gara, beraz, etengabe erosten ditugu gauza berriak, argazkiak egiten ditugu eta erakusleihoa eguneratzen dugu.
Pink peaks produktuen eguneraketak dira, hau da, produktuen aldaketak. Ikusten da mutilek argazkiak atera, argazkiak eta gero berriro! — ekitaldi sorta bat kargatu du.
Lamoda Events erabilera kasuak
Eraikitako arkitektura erabiltzen dugu eragiketa hauetarako:
- Itzultzeko egoeraren jarraipena: ekintzarako deia eta egoeraren jarraipena inplikatutako sistema guztietatik. Ordainketa, egoerak, fiskalizazioa, jakinarazpenak. Hemen ikuspegia probatu genuen, tresnak egin, akats guztiak bildu, dokumentazioa idatzi eta gure lankideei nola erabili esan genien.
- Produktuen txartelak eguneratzea: konfigurazioa, metadatuak, ezaugarriak. Sistema batek irakurtzen du (bistaratzen dena) eta hainbat idazten.
- Posta elektronikoa, push eta sms: eskaria bildu da, eskaera iritsi da, itzulera onartu da, etab., asko dira.
- Stocka, biltegia berritzea — gaien eguneraketa kuantitatiboa, zenbakiak besterik ez: biltegira iristea, itzulera. Beharrezkoa da ondasunak erreserbatzearekin lotutako sistema guztiek datu berrienekin funtzionatzea. Gaur egun, stock eguneratzeko sistema nahiko konplexua da; Kafkak sinplifikatu egingo du.
- Datuen analisia (I+G saila), ML tresnak, analitika, estatistikak. Informazioa gardena izatea nahi dugu - Kafka oso egokia da horretarako.
Orain, azken sei hilabeteetan gertatu diren kolpe handiei eta aurkikuntza interesgarriei buruzko zati interesgarriena.
Diseinu arazoak
Demagun gauza berri bat egin nahi dugula; adibidez, entrega-prozesu osoa Kafkara transferitzea. Orain prozesuaren zati bat BOB-en Eskaerak Prozesatzeko inplementatzen da. Eskaera bat entrega-zerbitzura transferitzearen, tarteko biltegi batera mugitzearen eta abarren atzean egoera-eredu bat dago. Monolito oso bat dago, baita bi ere, gehi entregari eskainitako API mordo bat. Bidalketari buruz askoz gehiago dakite.
Antzeko eremuak dirudite, baina BOBn Eskaerak Prozesatzeko eta Bidalketa Sistemak egoera desberdinak dituzte. Esaterako, mezularitza-zerbitzu batzuek ez dituzte bitarteko egoerak bidaltzen, azkenak baizik: “entregatu” edo “galdu”. Beste batzuek, aitzitik, merkantzien mugimenduari buruzko xehetasun handiz ematen dute. Bakoitzak bere baliozkotze-arauak ditu: batzuentzat posta elektronikoa baliozkoa da, hau da, prozesatu egingo da; beste batzuentzat ez du balio, baina eskaera prozesatu egingo da, harremanetarako telefono zenbaki bat dagoelako, eta norbaitek esango du eskaera hori ez dela batere prozesatuko.
Datu-korrontea
Kafkaren kasuan, datu-fluxua antolatzearen auzia sortzen da. Zeregin honek hainbat puntutan oinarritutako estrategia bat hautatzea dakar; ikus ditzagun guztiak.
Gai batean ala besteetan?
Ekitaldiaren zehaztapena dugu. BOBen idazten dugu halako eta halako eskaera bat entregatu behar dela, eta adierazten dugu: eskaera-zenbakia, haren osaera, SKU eta barra-kode batzuk, etab. Salgaiak biltegira iristen direnean, bidalketak egoerak, denbora-zigiluak eta behar den guztia jaso ahal izango ditu. Baina gero datu hauei buruzko eguneraketak BOB-en jaso nahi ditugu. Entregatik datuak jasotzeko alderantzizko prozesua dugu. Gertaera bera al da? Edo bere gaia merezi duen elkartruke bereizia da hau?
Seguruenik, oso antzekoak izango dira, eta gai bat egiteko tentazioa ez da funtsik gabekoa, gai bereiziak kontsumitzaile bereiziak, konfigurazio bereiziak, guzti honen belaunaldi bereiziak esan nahi dituelako. Baina ez da egia.
Eremu berria ala ekitaldi berria?
Baina gertaera berdinak erabiltzen badituzu, beste arazo bat sortzen da. Esate baterako, entrega-sistema guztiek ezin dute BOBek sor dezakeen DTO mota sortu. Id-a bidaltzen diegu, baina ez dute gordetzen behar ez dutelako, eta ekitaldi-bus prozesua abiarazteko ikuspegitik, eremu hori beharrezkoa da.
Eremu hau beharrezkoa dela dioen gertaera-buserako arau bat sartzen badugu, BOBn edo hasierako gertaeren kudeatzailean baliozkotze-arau osagarriak ezartzera behartuta gaude. Balioztatzea zerbitzu osoan zabaltzen hasten da - hori ez da oso erosoa.
Beste arazo bat garapen inkrementalerako tentazioa da. Ekitaldiari zerbait gehitu behar zaiola esaten digute, eta agian, hausnartzen badugu, aparteko ekitaldi bat izan beharko luke. Baina gure eskeman, aparteko gertaera bat gai bereizia da. Gai aparteko bat goian deskribatu dudan prozesu osoa da. Garatzaileak JSON eskeman beste eremu bat gehitzeko eta birsortzeko tentazioa du.
Itzulketen kasuan, ekitaldien ekitaldira urte erdian iritsi ginen. Itzulketa eguneratzea izeneko meta-gertaera bat izan genuen, eguneratze hori benetan zer zen deskribatzen zuen mota-eremu bat zuena. Hori dela eta, etengailu "zoragarriak" izan genituen baliozkotzaileekin, gertaera hau mota honekin nola baliozkotu esan ziguten.
Gertaeren bertsioa
Kafkan mezuak balioztatzeko erabil dezakezu , baina berehala etzan behar zen eta Confluent erabiltzea. Gure kasuan, kontuz ibili behar dugu bertsioekin. Ez da beti posible izango erreplikazio-erregistroko mezuak berrirakurtzea, eredua "irten" delako. Funtsean, bertsioak eraikitzen ditu, eredua atzerantz bateragarria izan dadin: adibidez, eremu bat aldi baterako hautazkoa izan. Desberdintasunak oso indartsuak badira, gai berri batean idazten hasten gara, eta bezeroak transferitzen dizkiogu zaharra irakurtzen amaitzen dutenean.
Partizioen irakurketa-ordena bermatua
Kafkaren barruko gaiak partiziotan banatuta daude. Hau ez da oso garrantzitsua entitateak eta trukeak diseinatzen ari garen bitartean, baina garrantzitsua da nola kontsumitu eta eskalatu erabakitzeko orduan.
Ohiko kasuan, gai bat idazten duzu Kafkan. Lehenespenez, partizio bat erabiltzen da, eta gai honetako mezu guztiak bertara joaten dira. Eta kontsumitzaileak, ondorioz, mezu hauek sekuentzialki irakurtzen ditu. Demagun orain sistema zabaldu behar dugula, mezuak bi kontsumitzaile ezberdinek irakur ditzaten. Adibidez, SMSak bidaltzen ari bazara, orduan Kafkari esan diezaiokezu partizio gehigarri bat egiteko, eta Kafka mezuak bi zatitan banatzen hasiko da: erdia hemen, erdia hemen.
Nola banatzen ditu Kafkak? Mezu bakoitzak gorputz bat (JSON gordetzen dugu bertan) eta gako bat ditu. Tekla honi hash funtzio bat erantsi diezaiokezu, mezua zein partiziotan sartuko den zehaztuko duena.
Itzulketen kasuan, hau garrantzitsua da, bi partizio hartzen baditugu, orduan kontsumitzaile paralelo batek bigarren gertaera lehena baino lehen prozesatzeko aukera dago eta arazoak egongo dira. Hash funtzioak gako bera duten mezuak partizio berean amaitzen direla ziurtatzen du.
Gertaerak vs komandoak
Hau da aurkitu dugun beste arazo bat. Gertaera gertaera jakin bat da: nonbait zerbait gertatu dela esaten dugu (zerbait_gertatu da), adibidez, elementu bat bertan behera utzi dela edo itzulketa bat gertatu dela. Norbaitek gertaera hauek entzuten baditu, "ezeztatu den elementua"ren arabera, itzulketa-entitatea sortuko da eta "itzulketa gertatu da" konfigurazioetan nonbait idatziko da.
Baina normalean, gertaerak diseinatzen dituzunean, ez dituzu alferrik idatzi nahi - norbaitek irakurriko dituelakoan oinarritzen zara. Tentazio handia dago ez zerbait_gertatua (elementua_ezeztatua, itzulketa_itzultua) idazteko, baizik eta_zerbait_egin_behar_behar. Adibidez, elementua itzultzeko prest dago.
Batetik, ekitaldia nola erabiliko den iradokitzen du. Bestalde, gertaera-izen arrunt baten itxura askoz gutxiago dirudi. Gainera, hemendik ez dago do_something komandoa. Baina ez duzu ziurtasunik norbaitek gertaera hau irakurtzea; eta irakurtzen baduzu, ondo irakurtzen duzu; eta ondo irakurri baduzu, orduan zerbait egin duzu, eta zerbait arrakastatsua izan da. Gertaera bat egin_zerbait bihurtzen den momentuan, feedbacka beharrezkoa bihurtzen da, eta hori arazo bat da.
RabbitMQ-en truke asinkronoan, mezua irakurtzen duzunean, joan http-ra, erantzun bat daukazu, gutxienez mezua jaso zela. Kafkari idazten diozunean, bada Kafkari idatzi diozun mezu bat, baina ez dakizu ezer nola prozesatu den.
Hori dela eta, gure kasuan, erantzun-gertaera bat sartu eta monitorizazioa ezarri behar izan dugu, horrenbeste gertaera bidaliz gero, halako denboraren ostean erantzun-ekitaldi kopuru bera iritsiko zen. Hau gertatzen ez bada, badirudi zerbait gaizki joan dela. Adibidez, "item_ready_to_refund" gertaera bidali badugu, itzulketa bat sortuko dela espero dugu, dirua bezeroari itzuliko zaiola eta "money_refunded" gertaera bidaliko zaigula. Baina hori ez da ziur, beraz, monitorizazioa beharrezkoa da.
ñabardura
Arazo aski agerikoa da: gai batetik irakurtzen baduzu sekuentzialki, eta mezu txarren bat baduzu, kontsumitzailea erori egingo da, eta ez zara urrunago joango. Behar duzu kontsumitzaile guztiak geldiarazi, egin konpentsazioa gehiago irakurtzen jarraitzeko.
Bagenekien, kontatzen genuen, eta hala ere gertatu zen. Eta hau gertatu zen gertaera gertaerak-busaren ikuspuntutik baliozkoa zelako, gertaera baliozkoa zen aplikazioaren baliozkotzailearen ikuspuntutik, baina ez zuen balio PostgreSQLren ikuspuntutik, gure sistema bakarrean. MySQL UNSIGNED INT-rekin, eta idatzi berrian sistemak PostgreSQL zuen INT-rekin soilik. Bere tamaina apur bat txikiagoa da, eta Id-a ez zen egokitzen. Symfony salbuespen batekin hil zen. Guk, noski, salbuespena atzeman dugu horretan oinarritzen garelako eta desplazamendu hau konprometituko genuelako, baina aurretik arazoen kontagailua handitu nahi genuen, mezua arrakastarik gabe prozesatu baitzen. Proiektu honetako kontagailuak ere datu-basean daude, eta Symfony-k dagoeneko itxi du datu-basearekiko komunikazioa, eta bigarren salbuespenak prozesu osoa hil zuen offset egiteko aukerarik gabe.
Zerbitzua denbora pixka bat eten zen - zorionez, Kafkarekin hori ez da hain txarra, mezuak geratzen direlako. Lanak leheneratzen direnean, irakurtzen amai dezakezu. Erosoa da.
Kafkak erreminten bidez desplazamendu arbitrarioa ezartzeko gaitasuna du. Baina horretarako, kontsumitzaile guztiak gelditu behar dituzu - gure kasuan, prestatu aparteko oharra, non kontsumitzailerik egongo ez den, birmoldaketak. Ondoren, Kafkan desplazamendua tresnen bidez alda dezakezu eta mezua pasatuko da.
Beste ñabardura bat - erreplikazio-erregistroa vs rdkafka.so - gure proiektuaren berezitasunekin lotuta dago. PHP erabiltzen dugu, eta PHPn, normalean, liburutegi guztiak Kafkarekin komunikatzen dira rdkafka.so biltegiaren bidez, eta gero bilgarri moduko bat dago. Agian hauek dira gure zailtasun pertsonalak, baina ikusi zen jada irakurritakoaren zati bat berriro irakurtzea ez dela hain erraza. Oro har, software arazoak egon ziren.
Partizioekin lan egiteko zehaztasunetara itzuliz, dokumentazioan idatzita dago kontsumitzaileak >= gai-partizioak. Baina nahi baino askoz beranduago jakin nuen honen berri. Eskalatu eta bi kontsumitzaile izan nahi badituzu, gutxienez bi partizio behar dituzu. Hau da, 20 mila mezu pilatutako partizio bat bazenuen eta berri bat egin bazenuen, mezu kopurua ez da laster berdinduko. Hori dela eta, bi kontsumitzaile paralelo izateko, partizioei aurre egin behar diezu.
jarraipenaren
Uste dut haren jarraipena egiteko modua are argiagoa izango dela zein arazo dauden lehendik dagoen planteamenduan.
Adibidez, datu-baseko zenbat produktuk egoera aldatu berri duten kalkulatzen dugu, eta, horren arabera, aldaketa horien arabera gertatu behar ziren gertaerak, eta zenbaki hori gure monitorizazio sistemara bidaltzen dugu. Gero Kafkatik bigarren zenbakia lortzen dugu, zenbat gertaera benetan grabatu ziren. Jakina, bi zenbaki horien arteko aldea beti zero izan behar da.
Horrez gain, ekoizlea nola dagoen, gertaerak-busak mezuak jaso dituen ala ez eta kontsumitzailea nola dagoen kontrolatu behar duzu. Esate baterako, beheko zerrendetan, Itzulketa Tresna ondo ari da, baina BOB argi dago arazo batzuk (tontor urdinak).
Kontsumo taldearen atzerapena aipatu dut. Gutxi gorabehera, irakurri gabeko mezuen kopurua da. Oro har, gure kontsumitzaileek azkar lan egiten dute, beraz, atzerapena 0 izan ohi da, baina batzuetan epe laburreko gailurra egon daiteke. Kafkak hori kutxatik kanpo egin dezake, baina tarte jakin bat ezarri behar duzu.
Proiektu bat dago horrek Kafkari buruzko informazio gehiago emango dizu. Kontsumitzaile-taldeen APIa besterik ez du erabiltzen talde hau nola dagoen jakiteko. Ados eta Huts egiteaz gain, abisu bat dago, eta jakin dezakezu zure kontsumitzaileek ezin diotela ekoizpen-erritmoari aurre egin; ez dute idatzitakoa zuzentzeko astirik. Sistema nahiko adimentsu eta erabiltzeko erraza da.
Hau da APIaren erantzunaren itxura. Hona hemen bob-live-fifa taldea, partizioa refund.update.v1, egoera OK, lag 0 - azken azken konpentsazioa halakoa.
jarraipenaren SLA-n eguneratua (trabatuta) Lehen aipatu dut. Adibidez, produktua itzultzeko prest dagoen egoerara aldatu da. Cron instalatzen dugu, eta horrek esaten du 5 minututan objektu hau ez bada itzultzera joan (dirua oso azkar itzultzen dugu ordainketa-sistemen bidez), orduan zerbait gaizki joan da, eta hau laguntza kasu bat da. Hori dela eta, horrelako gauzak irakurtzen dituen Cron hartzen dugu, eta 0 baino handiagoak badira, alerta bat bidaltzen du.
Laburbilduz, gertaerak erabiltzea komeni da noiz:
- informazioa hainbat sistemak behar dute;
- prozesamenduaren emaitza ez da garrantzitsua;
- ekitaldi gutxi edo ekitaldi txikiak daude.
Badirudi artikuluak oso gai zehatz bat duela - Kafka-ko API asinkronoa, baina horrekin lotuta gauza asko gomendatuko nituzke aldi berean.
Lehenengoa, hurrengoa azarora arte itxaron behar dugu;apirilean San Petersburgoko bertsioa izango da, eta ekainean Novosibirsken karga handiei buruz hitz egingo dugu.
Bigarrenik, txostenaren egilea, Sergei Zaika, ezagutzaren kudeaketari buruzko gure biltzar berriko Programa Batzordeko kidea da. . Jardunaldia egun batekoa da, apirilaren 26an izango da, baina bere egitaraua oso bizia da.
Eta maiatzean izango da и (DevOpsConf barne) - zure gaia ere proposa dezakezu bertan, zure esperientziaz hitz egin eta zure kono beteez kexatu.
Iturria: www.habr.com