Reynsla af þróun endurgreiðslutólsþjónustunnar með ósamstilltu API á Kafka

Hvað gæti neytt svo stórt fyrirtæki eins og Lamoda, með straumlínulagað ferli og heilmikið af samtengdri þjónustu, til að breyta umtalsvert um nálgun sína? Hvatning getur verið allt önnur: allt frá löggjafarvaldi til löngun til að gera tilraunir sem felst í öllum forriturum.

En þetta þýðir ekki að þú getir ekki treyst á viðbótarbætur. Sergey Zaika mun segja þér hvað nákvæmlega þú getur unnið ef þú innleiðir viðburðadrifna API á Kafka (fáald). Það verður líka örugglega talað um stór skot og áhugaverðar uppgötvanir - tilraunin getur ekki verið án þeirra.

Fyrirvari: Þessi grein er byggð á efni frá fundi sem Sergey hélt í nóvember 2018 á HighLoad++. Lifandi reynsla Lamoda af samstarfi við Kafka laðaði að sér hlustendur ekki síður en aðrar skýrslur á dagskránni. Okkur finnst þetta frábært dæmi um það að þú getur og ætti alltaf að finna fólk með sama hugarfar og skipuleggjendur HighLoad++ munu halda áfram að reyna að skapa andrúmsloft sem stuðlar að því.

Um ferlið

Lamoda er stór e-verslunarvettvangur sem hefur sína eigin tengiliðamiðstöð, afhendingarþjónustu (og mörg hlutdeildarfélög), ljósmyndastofu, risastórt vöruhús og allt þetta keyrir á eigin hugbúnaði. Það eru tugir greiðslumáta, b2b samstarfsaðila sem kunna að nota suma eða alla þessa þjónustu og vilja vita uppfærðar upplýsingar um vörur sínar. Að auki starfar Lamoda í þremur löndum fyrir utan Rússland og þar er allt aðeins öðruvísi. Alls eru líklega meira en hundrað leiðir til að stilla nýja pöntun, sem þarf að afgreiða á sinn hátt. Allt þetta virkar með hjálp tugum þjónustu sem stundum hafa samskipti á óaugljósan hátt. Einnig er til miðlægt kerfi þar sem meginábyrgð er pöntunarstaða. Við köllum hana BOB, ég vinn með henni.

Endurgreiðslutól með viðburðadrifnu API

Orðið atburðadrifið er frekar brjálað; aðeins nánar munum við skilgreina nánar hvað átt er við með þessu. Ég byrja á samhenginu þar sem við ákváðum að prófa atburðadrifna API nálgunina í Kafka.

Í hvaða verslun sem er, auk pantana sem viðskiptavinir greiða fyrir, eru tímar þar sem versluninni er skylt að skila peningum vegna þess að varan hentaði ekki viðskiptavininum. Þetta er tiltölulega stutt ferli: við skýrum upplýsingarnar, ef þörf krefur, og flytjum peningana.

En skilin urðu flóknari vegna lagabreytinga og við þurftum að innleiða sérstaka örþjónustu fyrir hana.

Hvatning okkar:

1. Lög FZ-54 - í stuttu máli segja lögin að tilkynna til skattstofunnar um öll peningaviðskipti, hvort sem það er skil eða kvittun, innan nokkuð stutts SLA frá nokkrum mínútum. Við, sem rafræn viðskipti, stundum töluvert mikið af rekstri. Tæknilega séð þýðir þetta nýja ábyrgð (og þar af leiðandi ný þjónusta) og endurbætur á öllum kerfum sem málið varðar.
2. BOB skipt er innra verkefni félagsins til að losa BOB undan miklum fjölda ókjarnaskyldna og draga úr heildarflækju þess.

Þessi skýringarmynd sýnir helstu Lamoda kerfin. Nú eru flestir fleiri stjörnumerki 5-10 örþjónustur í kringum minnkandi einlita. Þeir stækka hægt og rólega, en við erum að reyna að minnka þá, því það er skelfilegt að dreifa brotinu sem valið er í miðjunni - við getum ekki leyft því að detta. Við neyðumst til að panta öll skipti (örvar) og taka tillit til þess að einhver þeirra gæti reynst ófáanleg.

BOB er líka með töluvert af kauphöllum: greiðslukerfi, afhendingarkerfi, tilkynningakerfi osfrv.

Tæknilega BOB er:

• ~150k línur af kóða + ~100k línur af prófum;
• php7.2 + Zend 1 & Symfony Components 3;
• >100 API & ~50 samþættingar á útleið;
• 4 lönd með eigin viðskiptafræði.

Að dreifa BOB er dýrt og sársaukafullt, magn kóða og vandamála sem það leysir er slíkt að enginn getur sett allt í hausinn á sér. Almennt séð eru margar ástæður til að einfalda það.

Skilaferli

Í upphafi taka tvö kerfi þátt í ferlinu: BOB og greiðsla. Nú birtast tveir í viðbót:

• Fjármálaþjónusta, sem mun sinna vandamálum við fjármögnun og samskipti við utanaðkomandi þjónustu.
• Endurgreiðslutól, sem einfaldlega inniheldur ný skipti til að blása ekki upp BOB.

Nú lítur ferlið svona út:

1. BOB fær beiðni um endurgreiðslu.
2. BOB talar um þetta endurgreiðslutól.
3. Endurgreiðslutólið segir við greiðslu: "Skiltu peningunum."
4. Greiðsla skilar peningunum.
5. Endurgreiðslutól og BOB samstilla stöður sín á milli, því í bili þurfa þau bæði á því að halda. Við erum ekki enn tilbúin að skipta alveg yfir í endurgreiðslutólið, þar sem BOB er með notendaviðmót, skýrslur fyrir bókhald og almennt mikið af gögnum sem ekki er hægt að flytja svo auðveldlega. Þú verður að sitja á tveimur stólum.
6. Beiðnin um fjárheimild fellur niður.

Í kjölfarið gerðum við einskonar viðburðarrútu á Kafka - viðburðarrútu, sem allt byrjaði á. Húrra, nú erum við með einn bilunarpunkt (kaldhæðni).

Kostir og gallar eru nokkuð augljósir. Við gerðum strætó sem þýðir að nú er öll þjónusta háð henni. Þetta einfaldar hönnunina en kynnir einn bilunarpunkt inn í kerfið. Kafka mun hrynja, ferlið mun stöðvast.

Hvað er atburðadrifið API

Gott svar við þessari spurningu er í skýrslu Martin Fowler (GOTO 2017) „Margar merkingar atburðadrifinnar byggingarlistar“.

Í stuttu máli hvað við gerðum:

1. Lokaðu öllum ósamstilltum skiptum í gegnum geymsla viðburða. Í stað þess að upplýsa alla áhugasama neytendur um stöðubreytingar á netinu, skrifum við viðburð um stöðubreytingu í miðlæga geymslu og neytendur sem hafa áhuga á efninu lesa allt sem þar kemur fram.
2. Atburðurinn í þessu tilviki er tilkynning (tilkynningar) að eitthvað hafi breyst einhvers staðar. Til dæmis hefur pöntunarstaðan breyst. Neytandi sem hefur áhuga á einhverjum gögnum sem fylgja stöðubreytingunni og eru ekki innifalin í tilkynningunni getur sjálfur fundið út stöðu þeirra.
3. Hámarksvalkosturinn er fullgild uppspretta viðburða, ríkisflutningur, í hvaða tilviki inniheldur allar nauðsynlegar upplýsingar til vinnslu: hvaðan þær komu og hvaða stöðu þær fóru í, hvernig nákvæmlega gögnin breyttust o.s.frv. Eina spurningin er hagkvæmni og magn upplýsinga sem þú hefur efni á að geyma.

Sem hluti af kynningu á endurgreiðslutólinu notuðum við þriðja valkostinn. Þetta einfaldaði vinnslu atburða þar sem engin þörf var á að draga út nákvæmar upplýsingar, auk þess sem hún útilokaði atburðarásina þar sem hver nýr atburður myndar hraða skýringarbeiðna um að fá frá neytendum.

Þjónusta endurgreiðsluverkfæra ekki hlaðið, svo Kafka er meira bragð af pennanum en nauðsyn. Ég held ekki að ef endurgreiðsluþjónustan yrði mikið álagsverkefni myndu fyrirtækin vera ánægð.

Ósamstillt skipti eins og það er

Fyrir ósamstillt skipti notar PHP deildin venjulega RabbitMQ. Við söfnuðum gögnum fyrir beiðnina, settum þau í biðröð og neytandi sömu þjónustu las þau og sendi (eða sendi hana ekki). Fyrir API sjálft notar Lamoda Swagger virkan. Við hönnum API, lýsum því í Swagger og búum til kóða viðskiptavinar og netþjóns. Við notum einnig aðeins endurbætt JSON RPC 2.0.

Sums staðar eru ESB rútur notaðar, sumir búa á activeMQ, en almennt, RabbitMQ - staðall.

Ósamstilltur skipti TO BE

Þegar verið er að hanna skipti í gegnum viðburða-strætó má rekja hliðstæðu. Við lýsum á sama hátt framtíðargagnaskiptum með lýsingum á uppbyggingu atburða. Yaml sniðið, við þurftum að gera kóðagerðina sjálf, rafallinn býr til DTO í samræmi við forskriftina og kennir viðskiptavinum og netþjónum að vinna með þá. Kynslóð fer í tvö tungumál - golang og php. Þetta hjálpar til við að halda bókasöfnum stöðugum. Rafallinn er skrifaður í golang, þess vegna fékk hann nafnið gogi.

Atburðauppspretta á Kafka er dæmigerður hlutur. Það er til lausn frá helstu fyrirtækjaútgáfu Kafka Confluent, það er nakadi, lausn frá lénsbræðrum okkar Zalando. Okkar hvatning til að byrja með vanillu Kafka - þetta þýðir að skilja lausnina eftir frjálsa þar til við loksins ákveðum hvort við munum nota hana alls staðar, og einnig að gefa okkur svigrúm fyrir svigrúm og umbætur: við viljum stuðning við okkar JSON RPC 2.0, rafala fyrir tvö tungumál og við skulum sjá hvað annað.

Það er kaldhæðnislegt að jafnvel í svona ánægjulegu tilviki, þegar það er nokkurn veginn svipað fyrirtæki, Zalando, sem gerði nokkurn veginn svipaða lausn, getum við ekki notað það á áhrifaríkan hátt.

Byggingarmynstrið við kynningu er sem hér segir: við lesum beint úr Kafka, en skrifum aðeins í gegnum viðburða-strætó. Það er margt tilbúið til lestrar í Kafka: miðlari, jafnvægismenn, og það er meira og minna tilbúið fyrir lárétta skala, ég vildi halda þessu. Við vildum klára upptökuna í gegnum einn Gateway aka Events-bus, og hér er ástæðan.

Viðburðir-rúta

Eða viðburðarrúta. Þetta er einfaldlega ríkisfangslaus http gátt sem tekur að sér nokkur mikilvæg hlutverk:

• Framleiðir staðfestingu — við athugum hvort viðburðirnir standist forskriftir okkar.
• Atburðameistarakerfi, það er að segja, þetta er helsta og eina kerfið í fyrirtækinu sem svarar spurningunni um hvaða atburðir með hvaða mannvirki teljast gildar. Staðfesting felur einfaldlega í sér gagnategundir og upptalningar til að tilgreina efni nákvæmlega.
• Hash virka fyrir klippingu - Kafka skilaboðaskipan er lykilgildi og með því að nota kjötkássa lykilsins er reiknað út hvar á að setja það.

Hvers

Við vinnum í stóru fyrirtæki með straumlínulagað ferli. Af hverju að breyta einhverju? Þetta er tilraun, og við gerum ráð fyrir að uppskera ýmsa kosti.

1:n+1 skipti (eitt á móti mörgum)

Kafka gerir það mjög auðvelt að tengja nýja neytendur við API.

Segjum að þú sért með möppu sem þú þarft að halda uppfærðri í nokkrum kerfum í einu (og í sumum nýjum). Áður fundum við upp búnt sem innleiddi set-API og aðalkerfið var upplýst um heimilisföng neytenda. Nú sendir meistarakerfið uppfærslur á efnið og allir sem hafa áhuga lesa það. Nýtt kerfi hefur litið dagsins ljós - við skráðum það undir efnið. Já, líka búnt, en einfaldara.

Þegar um er að ræða endurgreiðslutól, sem er hluti af BOB, er þægilegt fyrir okkur að halda þeim samstilltum í gegnum Kafka. Greiðsla segir að peningarnir hafi verið skilaðir: BOB, RT komst að þessu, breytti stöðunum sínum, Fiscalization Service komst að þessu og gaf út ávísun.

Við höfum áform um að búa til sameinaða tilkynningaþjónustu sem myndi láta viðskiptavininn vita um fréttir varðandi pöntun hans/skilaboð. Nú er þessi ábyrgð dreifð á milli kerfa. Það mun nægja fyrir okkur að kenna tilkynningaþjónustunni að ná viðeigandi upplýsingum frá Kafka og svara þeim (og slökkva á þessum tilkynningum í öðrum kerfum). Engin ný bein skipti verða nauðsynleg.

Gagnastýrð heilbrigðisþjónusta

Upplýsingar á milli kerfa verða gagnsæjar - sama hvaða „blóðugt fyrirtæki“ þú ert með og sama hversu stórt eftirbátur þinn er. Lamoda er með gagnagreiningardeild sem safnar gögnum úr kerfum og setur þau í endurnýtanlegt form, bæði fyrir fyrirtæki og fyrir greindarkerfi. Kafka gerir þér kleift að gefa þeim mikið af gögnum á fljótlegan hátt og halda því upplýsingaflæði uppfærðu.

Afritunarskrá

Skilaboð hverfa ekki eftir að þau eru lesin, eins og í RabbitMQ. Þegar atburður inniheldur nægar upplýsingar til vinnslu höfum við sögu um nýlegar breytingar á hlutnum og, ef þess er óskað, getu til að beita þessum breytingum.

Geymslutími afritunarskrárinnar fer eftir því hversu mikið er skrifað í þetta efni; Kafka gerir þér kleift að setja sveigjanlega takmarkanir á geymslutíma og gagnamagni. Fyrir ákafur efni er mikilvægt að allir neytendur hafi tíma til að lesa upplýsingarnar áður en þær hverfa, jafnvel ef um skammtíma óvirkni er að ræða. Venjulega er hægt að geyma gögn fyrir dageiningar, sem er alveg nóg til stuðnings.

Næst, smá endursögn af skjölunum, fyrir þá sem ekki þekkja Kafka (myndin er líka úr skjölunum)

AMQP er með biðraðir: við skrifum skilaboð í biðröð fyrir neytandann. Venjulega er ein biðröð unnin af einu kerfi með sömu viðskiptarökfræði. Ef þú þarft að tilkynna nokkrum kerfum geturðu kennt forritinu að skrifa í nokkrar biðraðir eða stilla skipti með fanout vélbúnaðinum, sem klónar þau sjálf.

Kafka hefur svipaða abstrakt spjallþráð, þar sem þú skrifar skilaboð, en þau hverfa ekki eftir lestur. Sjálfgefið er að þegar þú tengist Kafka færðu öll skilaboð og hefur möguleika á að vista þar sem frá var horfið. Það er, þú lest í röð, þú mátt ekki merkja skilaboðin sem lesin, heldur vista auðkennið sem þú getur síðan haldið áfram að lesa úr. Auðkennið sem þú settir þig á er kallað offset og vélbúnaðurinn er commit offset.

Í samræmi við það er hægt að útfæra mismunandi rökfræði. Til dæmis höfum við BOB í 4 tilfellum fyrir mismunandi lönd - Lamoda er í Rússlandi, Kasakstan, Úkraínu, Hvíta-Rússlandi. Þar sem þeir eru notaðir sérstaklega hafa þeir aðeins mismunandi stillingar og sína eigin viðskiptarökfræði. Við tilgreinum í skilaboðunum til hvaða lands það er átt. Hver BOB neytandi í hverju landi les með öðru groupId og ef skilaboðin eiga ekki við þá sleppa þeir því, þ.e. skuldbindur strax offset +1. Ef sama efni er lesið af greiðsluþjónustunni okkar, þá gerir það það með sérstökum hópi og því skerast jöfnun ekki.

Kröfur um viðburð:

• Fullkomin gögn. Ég vil að viðburðurinn hafi næg gögn svo hægt sé að vinna úr þeim.

• Heiðarleiki. Við felum Events-bus staðfestingu á því að viðburðurinn sé í samræmi og hann geti unnið úr því.
• Röðin er mikilvæg. Ef um endurkomu er að ræða neyðumst við til að vinna með söguna. Með tilkynningum skiptir pöntunin ekki máli, ef um einsleitar tilkynningar er að ræða verður tölvupósturinn sá sami óháð því hvaða pöntun kom fyrst. Þegar um endurgreiðslu er að ræða er skýrt ferli; ef við breytum pöntuninni koma upp undantekningar, endurgreiðslan verður ekki búin til eða afgreidd - við endum í annarri stöðu.
• Samræmi. Við erum með verslun og nú búum við til viðburði í stað API. Okkur vantar leið til að senda upplýsingar um nýja viðburði og breytingar á þeim sem fyrir eru á fljótlegan og ódýran hátt í þjónustu okkar. Þetta er náð með sameiginlegri forskrift í sérstakri git geymslu og kóðara. Þess vegna eru viðskiptavinir og netþjónar í mismunandi þjónustu samræmdir.

Kafka í Lamoda

Við erum með þrjár Kafka innsetningar:

1. Logs;
2. R&D;
3. Viðburðir-rúta.

Í dag erum við aðeins að tala um síðasta atriðið. Hjá events-bus erum við ekki með mjög stórar uppsetningar - 3 miðlarar (miðlarar) og aðeins 27 efni. Að jafnaði er eitt efni eitt ferli. En þetta er lúmskur punktur og við munum koma inn á það núna.

Hér að ofan er rps grafið. Endurgreiðsluferlið er merkt með grænblárri línu (já, sú á X-ásnum) og bleika línan er efnisuppfærsluferlið.

Lamoda vörulistinn inniheldur milljónir vara og gögnin eru uppfærð allan tímann. Sum söfn fara úr tísku, ný eru gefin út í stað þeirra og nýjar gerðir birtast stöðugt í vörulistanum. Við reynum að spá fyrir um hvað verður áhugavert fyrir viðskiptavini okkar á morgun, svo við kaupum stöðugt nýja hluti, myndum þá og uppfærum sýningarskápinn.

Bleikir tindar eru vöruuppfærslur, það er breytingar á vörum. Það má sjá að strákarnir tóku myndir, tóku myndir og svo aftur! - hlaðið pakka af atburðum.

Notkunartilvik Lamoda Events

Við notum smíðaðan arkitektúr fyrir eftirfarandi aðgerðir:

• Skilastöðumæling: ákall til aðgerða og stöðurakningu frá öllum kerfum sem málið varðar. Greiðsla, stöður, fjármögnun, tilkynningar. Hér prófuðum við nálgunina, gerðum verkfæri, söfnuðum öllum villum, skrifuðum skjöl og sögðum samstarfsfólki okkar hvernig ætti að nota það.
• Uppfærsla vörukorta: stillingar, meta-gögn, eiginleikar. Eitt kerfi les (sem sýnir) og nokkur skrifa.
• Tölvupóstur, ýttur og sms: pöntunin hefur verið sótt, pöntunin komin, skilað hefur verið samþykkt o.s.frv., það er fullt af þeim.
• Lager, endurnýjun vöruhúss — Magnbundin uppfærsla á hlutum, bara tölur: komu á lager, skil. Nauðsynlegt er að öll kerfi sem tengjast vörupöntun starfi með nýjustu gögnum. Eins og er er hlutabréfauppfærslukerfið nokkuð flókið; Kafka mun einfalda það.
• Data Analysis (R&D deild), ML verkfæri, greiningar, tölfræði. Við viljum að upplýsingar séu gagnsæjar – Kafka hentar vel til þess.

Nú er áhugaverðari hlutinn um stóru höggin og áhugaverðar uppgötvanir sem hafa átt sér stað síðastliðna sex mánuði.

Hönnunarvandamál

Segjum að við viljum gera eitthvað nýtt - til dæmis flytja allt afhendingarferlið til Kafka. Nú er hluti af ferlinu innleiddur í Order Processing í BOB. Það er stöðulíkan á bak við flutning pöntunar í afhendingarþjónustu, flutning í millilager o.s.frv. Það er heill einlitur, jafnvel tveir, auk fullt af API sem eru tileinkuð afhendingu. Þeir vita miklu meira um afhendingu.

Þetta virðast vera svipuð svæði, en pöntunarvinnsla í BOB og sendingarkerfinu hafa mismunandi stöðu. Til dæmis senda sumar hraðboðaþjónustur ekki millistöður, heldur aðeins þær síðustu: „afhent“ eða „týnt“. Aðrir, þvert á móti, segja mjög ítarlega frá vöruflutningum. Allir hafa sínar eigin löggildingarreglur: fyrir suma er tölvupósturinn gildur, sem þýðir að hann verður afgreiddur; fyrir aðra er það ekki gilt, en pöntunin verður samt afgreidd vegna þess að það er símanúmer til að hafa samband og einhver mun segja að slík pöntun verði alls ekki afgreidd.

Gagnastraumur

Í tilfelli Kafka vaknar spurningin um að skipuleggja gagnaflæðið. Þetta verkefni felur í sér að velja stefnu byggða á nokkrum atriðum; við skulum fara í gegnum þá alla.

Í einu efni eða í mismunandi?

Við erum með viðburðalýsingu. Í BOB skrifum við að slíka og slíka pöntun þurfi að afhenda, og tilgreinum: pöntunarnúmerið, samsetningu þess, nokkur vörunúmer og strikamerki o.s.frv. Þegar vörurnar eru komnar á lager mun sendingin geta fengið stöður, tímastimpla og allt sem þarf. En svo viljum við fá uppfærslur á þessum gögnum í BOB. Við höfum öfugt ferli við að taka á móti gögnum frá afhendingu. Er þetta sami atburðurinn? Eða er þetta sérstakt orðaskipti sem verðskulda sitt eigið umræðuefni?

Líklegast munu þeir vera mjög líkir og freistingin að búa til eitt umræðuefni er ekki ástæðulaus, því að sérstakt efni þýðir aðskildir neytendur, aðskildar stillingar, sérstaka kynslóð af öllu þessu. En ekki staðreynd.

Nýtt svið eða nýr viðburður?

En ef þú notar sömu atburði, þá kemur annað vandamál upp. Til dæmis geta ekki öll afhendingarkerfi búið til þá tegund af DTO sem BOB getur búið til. Við sendum þeim auðkennið, en þeir vista það ekki vegna þess að þeir þurfa það ekki, og frá því sjónarmiði að hefja viðburðarrútuferlið er þetta reit áskilið.

Ef við kynnum reglu fyrir atburðarrútu um að þessi reit sé nauðsynlegur, þá neyðumst við til að setja frekari löggildingarreglur í BOB eða í byrjunarviðburðastjórnun. Staðfesting byrjar að dreifast um alla þjónustuna - þetta er ekki mjög þægilegt.

Annað vandamál er freistingin til stigvaxandi þróunar. Okkur er sagt að það þurfi að bæta einhverju við viðburðinn og kannski, ef við hugsum um það, hefði þetta átt að vera sérstakur viðburður. En í kerfinu okkar er sérstakur atburður sérstakt umræðuefni. Sérstakt efni er allt ferlið sem ég lýsti hér að ofan. Framkvæmdaraðilinn freistast til að einfaldlega bæta öðru sviði við JSON stefið og endurskapa það.

Í tilviki endurgreiðslna komum við að atburðum á hálfu ári. Við vorum með einn meta-viðburð sem kallast endurgreiðsluuppfærsla, sem var með tegundarreit sem lýsti því hvað þessi uppfærsla var í raun og veru. Vegna þessa áttum við „dásamlega“ rofa með sannprófunaraðilum sem sögðu okkur hvernig ætti að staðfesta þennan atburð með þessari tegund.

Útgáfa viðburða

Til að staðfesta skilaboð í Kafka geturðu notað evru, en það var nauðsynlegt að leggja strax á það og nota Confluent. Í okkar tilviki verðum við að vera varkár með útgáfu. Það verður ekki alltaf hægt að endurlesa skilaboð úr afritunarskránni vegna þess að líkanið hefur „farið“. Í grundvallaratriðum, það kemur í ljós að smíða útgáfur þannig að líkanið er afturábak samhæft: til dæmis, gerðu reit tímabundið valfrjálst. Ef munurinn er of mikill byrjum við að skrifa í nýtt efni og flytjum viðskiptavini þegar þeir eru búnir að lesa það gamla.

Ábyrgð lestrarröð skiptinga

Efni innan Kafka er skipt í skipting. Þetta er ekki mjög mikilvægt á meðan við erum að hanna einingar og kauphallir, en það er mikilvægt þegar ákveðið er hvernig á að neyta og skala það.

Í venjulegu tilfelli skrifar þú eitt efni í Kafka. Sjálfgefið er að ein skipting sé notuð og öll skilaboð í þessu efni fara í það. Og neytandinn les þar af leiðandi þessi skilaboð í röð. Segjum nú að við þurfum að stækka kerfið þannig að skilaboð séu lesin af tveimur mismunandi neytendum. Ef þú ert til dæmis að senda SMS, þá geturðu sagt Kafka að búa til viðbótar skipting og Kafka mun byrja að skipta skilaboðunum í tvo hluta - hálft hér, hálft hér.

Hvernig skiptir Kafka þeim? Hver skilaboð hafa meginmál (þar sem við geymum JSON) og lykil. Þú getur tengt kjötkássaaðgerð við þennan lykil, sem mun ákvarða í hvaða skipting skilaboðin fara.

Í okkar tilviki með endurgreiðslur er þetta mikilvægt, ef við tökum tvö skipting, þá er möguleiki á að samhliða neytandi afgreiði seinni atburðinn á undan þeim fyrsta og það verði vandræði. Hash aðgerðin tryggir að skilaboð með sama lykli lendi í sama skiptingunni.

Atburðir vs skipanir

Þetta er annað vandamál sem við lentum í. Atburður er ákveðinn atburður: við segjum að eitthvað hafi gerst einhvers staðar (eitthvað_gerist), til dæmis hafi hlut verið hætt eða endurgreiðsla hafi átt sér stað. Ef einhver hlustar á þessa atburði, þá verður endurgreiðslueiningin búin til, samkvæmt „hlutur aflýst“, og „endurgreiðsla átti sér stað“ verður skrifað einhvers staðar í uppsetningunum.

En venjulega, þegar þú hannar viðburði, vilt þú ekki skrifa þá til einskis - þú treystir á þá staðreynd að einhver lesi þá. Það er mikil freisting að skrifa ekki eitthvað_gerist (vara_hætt, endurgreitt_endurgreitt), heldur eitthvað_ætti_gerast. Til dæmis er hluturinn tilbúinn til að vera skilað.

Annars vegar gefur það til kynna hvernig viðburðurinn verður notaður. Aftur á móti hljómar það mun minna eins og venjulegt atburðarheiti. Að auki, það er ekki langt héðan í do_something skipunina. En þú hefur enga tryggingu fyrir því að einhver lesi þennan atburð; og ef þú lest það, þá lestu það með góðum árangri; og ef þú lest það með góðum árangri, þá gerðirðu eitthvað, og það var árangursríkt. Um leið og atburður verður að gera_eitthvað verður endurgjöf nauðsynleg og það er vandamál.

Í ósamstilltum samskiptum í RabbitMQ, þegar þú lest skilaboðin, farðu á http, þú hefur svar - að minnsta kosti að skilaboðin hafi verið móttekin. Þegar þú skrifar til Kafka kemur skilaboð sem þú skrifaðir til Kafka en þú veist ekkert um hvernig það var unnið.

Þess vegna þurftum við í okkar tilviki að taka upp viðbragðsatburði og setja upp vöktun þannig að ef svo margir atburðir væru sendir þá ættu jafnmargir viðbragðsviðburðir að koma eftir þann og þann tíma. Ef þetta gerist ekki þá virðist eitthvað hafa farið úrskeiðis. Til dæmis, ef við sendum „item_ready_to_refund“ viðburðinn, gerum við ráð fyrir að endurgreiðsla verði búin til, peningarnir verði skilaðir til viðskiptavinarins og „money_refunded“ viðburðurinn verður sendur til okkar. En þetta er ekki víst og því þarf eftirlit.

Blæbrigði

Það er nokkuð augljóst vandamál: Ef þú lest úr efni í röð og þú hefur einhver slæm skilaboð, mun neytandinn falla og þú ferð ekki lengra. Þú þarft stöðva alla neytendur, skuldbinda sig frekar til að halda áfram að lesa.

Við vissum af því, við treystum á það, og samt gerðist það. Og þetta gerðist vegna þess að atburðurinn var gildur frá sjónarhóli atburða-bus, atburðurinn var gildur frá sjónarhóli umsóknarprófunaraðila, en hann var ekki gildur frá sjónarhóli PostgreSQL, vegna þess að í kerfinu okkar MySQL með UNSIGNED INT var kerfið með PostgreSQL bara með INT. Stærðin hans er aðeins minni og auðkennið passaði ekki. Symfony lést með undantekningu. Við náðum að sjálfsögðu undantekningunni vegna þess að við treystum á hana og ætluðum að gera þetta mótvægi, en áður vildum við hækka vandamálateljarann, þar sem skilaboðin voru unnin án árangurs. Teljararnir í þessu verkefni eru einnig í gagnagrunninum og Symfony hefur þegar lokað fyrir samskipti við gagnagrunninn og önnur undantekningin drap allt ferlið án möguleika á að skuldbinda sig.

Þjónustan lá niðri í nokkurn tíma - sem betur fer er þetta ekki svo slæmt hjá Kafka, því skilaboðin eru eftir. Þegar vinna er endurheimt geturðu lokið lestri þeirra. Það er þægilegt.

Kafka hefur getu til að stilla handahófskenndan mótvægi með verkfærum. En til að gera þetta þarftu að stöðva alla neytendur - í okkar tilviki, undirbúa sérstaka útgáfu þar sem engir neytendur verða, endurskipulagningar. Síðan í Kafka geturðu fært offsetið í gegnum verkfæri og skilaboðin munu fara í gegn.

Annar blæbrigði - afritunarskrá á móti rdkafka.so - tengist sérstöðu verkefnisins okkar. Við notum PHP og í PHP eiga öll bókasöfn að jafnaði samskipti við Kafka í gegnum rdkafka.so geymsluna og svo er einhvers konar umbúðir. Kannski eru þetta persónulegir erfiðleikar okkar, en það kom í ljós að það er ekki svo auðvelt að endurlesa hluta af því sem við höfðum þegar lesið. Almennt séð voru hugbúnaðarvandamál.

Þegar farið er aftur í upplýsingarnar um að vinna með skipting, það er skrifað rétt í skjölunum neytendur >= efnisskil. En ég komst að þessu miklu seinna en ég hefði viljað. Ef þú vilt skala og hafa tvo neytendur þarftu að minnsta kosti tvö skipting. Það er að segja, ef þú varst með eitt skipting þar sem 20 þúsund skeyti höfðu safnast saman og þú gerðir nýtt, mun fjöldi skeyta ekki jafnast fljótlega. Þess vegna, til þess að hafa tvo samhliða neytendur, þarftu að takast á við skipting.

Eftirlit

Ég held að það verði enn skýrara hvernig við fylgjumst með því hvaða vandamál eru í núverandi nálgun.

Við reiknum til dæmis út hversu margar vörur í gagnagrunninum hafa nýlega breytt stöðu sinni og í samræmi við það ættu atburðir að hafa átt sér stað miðað við þessar breytingar og sendum þessa tölu í eftirlitskerfið okkar. Síðan fáum við frá Kafka seinni töluna, hversu margir atburðir voru í raun skráðir. Augljóslega ætti munurinn á þessum tveimur tölum alltaf að vera núll.

Að auki þarftu að fylgjast með því hvernig framleiðandinn hefur það, hvort viðburðir-strætó fékk skilaboð og hvernig neytandinn hefur það. Til dæmis, í töflunum hér að neðan, gengur Refund Tool vel, en BOB hefur greinilega einhver vandamál (bláir tindar).

Ég minntist þegar á töf neytendahópa. Í grófum dráttum er þetta fjöldi ólesinna skeyta. Almennt séð vinna neytendur okkar hratt, þannig að töfin er yfirleitt 0, en stundum getur verið skammtímahámark. Kafka getur gert þetta út úr kassanum, en þú þarft að stilla ákveðið bil.

Það er verkefni Gröfsem mun gefa þér frekari upplýsingar um Kafka. Það notar einfaldlega API neytendahópa til að gefa upp stöðuna á því hvernig þessum hópi gengur. Til viðbótar við OK og Failed er viðvörun og þú getur komist að því að neytendur þínir ráða ekki við framleiðsluhraða - þeir hafa ekki tíma til að prófarkalesa það sem skrifað er. Kerfið er nokkuð snjallt og auðvelt í notkun.

Svona lítur API svarið út. Hér er hópurinn bob-live-fifa, partition refund.update.v1, status OK, töf 0 - síðasta lokajöfnun svo og svo.

Eftirlit uppfært_á SLA (fastur) Ég nefndi þegar. Varan hefur til dæmis breyst í þá stöðu að hún sé tilbúin til skila. Við setjum upp Cron, sem segir að ef eftir 5 mínútur hefur þessi hlutur ekki farið til endurgreiðslu (við skilum peningum í gegnum greiðslukerfi mjög fljótt), þá hefur eitthvað örugglega farið úrskeiðis og þetta á örugglega við um stuðning. Þess vegna tökum við einfaldlega Cron, sem les slíka hluti, og ef þeir eru stærri en 0, þá sendir það viðvörun.

Til að draga saman, það er þægilegt að nota atburði þegar:

• upplýsingar eru nauðsynlegar af nokkrum kerfum;
• niðurstaða vinnslu er ekki mikilvæg;
• það eru fáir atburðir eða smáviðburðir.

Það virðist sem greinin hafi mjög ákveðið efni - ósamstilltur API á Kafka, en í tengslum við það vil ég mæla með mörgum hlutum í einu.
Fyrst, næst HighLoad++ við þurfum að bíða þangað til í nóvember, í apríl verður útgáfa frá Sankti Pétursborg og í júní ræðum við mikið álag í Novosibirsk.
Í öðru lagi er höfundur skýrslunnar, Sergei Zaika, meðlimur í dagskrárnefnd nýrrar ráðstefnu okkar um þekkingarstjórnun. KnowledgeConf. Ráðstefnan er eins dags, fer fram 26. apríl en dagskrá hennar er mjög mikil.
Og það verður í maí PHP Rússland и RIT++ (með DevOpsConf innifalið) - þú getur líka stungið upp á efninu þínu þar, talað um reynslu þína og kvartað yfir uppstoppuðu keilunum þínum.

Heimild: www.habr.com