Beth allai orfodi cwmni mor fawr â Lamoda, gyda phroses symlach a dwsinau o wasanaethau rhyng-gysylltiedig, i newid ei ddull gweithredu yn sylweddol? Gall cymhelliant fod yn gwbl wahanol: o ddeddfwriaethol i'r awydd i arbrofi sy'n gynhenid ym mhob rhaglennydd.
Ond nid yw hyn yn golygu na allwch ddibynnu ar fudd-daliadau ychwanegol. Bydd Sergey Zaika yn dweud wrthych beth yn union y gallwch chi ei ennill os byddwch chi'n gweithredu'r API sy'n cael ei yrru gan ddigwyddiadau ar Kafka (). Bydd sôn yn bendant am ergydion mawr a darganfyddiadau diddorol hefyd - ni all yr arbrawf wneud hebddynt.
Ymwadiad: Mae'r erthygl hon yn seiliedig ar ddeunyddiau o gyfarfod a gynhaliodd Sergey ym mis Tachwedd 2018 ar HighLoad ++. Denodd profiad byw Lamoda o weithio gyda Kafka wrandawyr ddim llai nag adroddiadau eraill ar yr amserlen. Credwn fod hon yn enghraifft wych o'r ffaith y gallwch ac y dylech bob amser ddod o hyd i bobl o'r un anian, a bydd trefnwyr HighLoad++ yn parhau i geisio creu awyrgylch sy'n ffafriol i hyn.
Ynglŷn â'r broses
Mae Lamoda yn blatfform e-fasnach fawr sydd â'i ganolfan gyswllt ei hun, gwasanaeth dosbarthu (a llawer o gysylltiadau), stiwdio ffotograffau, warws enfawr, ac mae hyn i gyd yn rhedeg ar ei feddalwedd ei hun. Mae yna ddwsinau o ddulliau talu, partneriaid b2b a all ddefnyddio rhai neu bob un o'r gwasanaethau hyn ac sydd eisiau gwybod y wybodaeth ddiweddaraf am eu cynhyrchion. Yn ogystal, mae Lamoda yn gweithredu mewn tair gwlad ar wahân i Ffederasiwn Rwsia ac mae popeth ychydig yn wahanol yno. Yn gyfan gwbl, mae'n debyg bod mwy na chant o ffyrdd i ffurfweddu gorchymyn newydd, y mae'n rhaid ei brosesu yn ei ffordd ei hun. Mae hyn i gyd yn gweithio gyda chymorth dwsinau o wasanaethau sydd weithiau'n cyfathrebu mewn ffyrdd nad ydynt yn amlwg. Mae yna hefyd system ganolog sy'n bennaf gyfrifol am statws trefn. Rydyn ni'n ei galw hi'n BOB, rydw i'n gweithio gyda hi.
Offeryn Ad-daliad gydag API sy'n cael ei yrru gan ddigwyddiadau
Mae’r gair a yrrir gan ddigwyddiadau yn eithaf hacni; ychydig ymhellach byddwn yn diffinio’n fanylach beth a olygir gan hyn. Dechreuaf gyda'r cyd-destun y gwnaethom benderfynu rhoi cynnig ar y dull API sy'n cael ei yrru gan ddigwyddiadau yn Kafka.
Mewn unrhyw siop, yn ogystal ag archebion y mae cwsmeriaid yn talu amdanynt, mae yna adegau pan fydd yn ofynnol i'r siop ddychwelyd arian oherwydd nad oedd y cynnyrch yn addas i'r cwsmer. Mae hon yn broses gymharol fyr: rydym yn egluro’r wybodaeth, os oes angen, ac yn trosglwyddo’r arian.
Ond daeth y dychweliad yn fwy cymhleth oherwydd newidiadau mewn deddfwriaeth, a bu’n rhaid inni weithredu microwasanaeth ar wahân ar ei gyfer.
Ein cymhelliant:
- Cyfraith FZ-54 - yn fyr, mae'r gyfraith yn ei gwneud yn ofynnol i adrodd i'r swyddfa dreth am bob trafodiad ariannol, boed yn ffurflen neu dderbynneb, o fewn CLG gweddol fyr o ychydig funudau. Rydym ni, fel cwmni e-fasnach, yn cyflawni cryn dipyn o weithrediadau. Yn dechnegol, mae hyn yn golygu cyfrifoldeb newydd (ac felly gwasanaeth newydd) a gwelliannau ym mhob system dan sylw.
- hollti BOB yn brosiect mewnol y cwmni i ryddhau BOB o nifer fawr o gyfrifoldebau nad ydynt yn rhai craidd a lleihau ei gymhlethdod cyffredinol.
Mae'r diagram hwn yn dangos y prif systemau Lamoda. Nawr mae'r rhan fwyaf ohonyn nhw'n fwy cytser o 5-10 microwasanaeth o amgylch monolith sy'n crebachu. Maent yn tyfu'n araf, ond rydym yn ceisio eu gwneud yn llai, oherwydd mae gosod y darn a ddewiswyd yn y canol yn frawychus - ni allwn ganiatáu iddo ddisgyn. Rydym yn cael ein gorfodi i gadw pob cyfnewid (saethau) ac yn cymryd i ystyriaeth y ffaith y gall unrhyw un ohonynt yn troi allan i fod ar gael.
Mae gan BOB hefyd lawer o gyfnewidiadau: systemau talu, systemau dosbarthu, systemau hysbysu, ac ati.
Yn dechnegol mae BOB yn:
- ~150k llinellau cod + ~100k llinellau o brofion;
- php7.2 + Zend 1 & Cydrannau Symfony 3;
- >100 API a ~50 integreiddiadau allanol;
- 4 gwlad gyda'u rhesymeg busnes eu hunain.
Mae defnyddio BOB yn ddrud ac yn boenus, ac mae maint y cod a'r problemau y mae'n eu datrys yn golygu na all neb roi'r cyfan yn eu pen. Yn gyffredinol, mae yna lawer o resymau i'w symleiddio.
Proses Dychwelyd
I ddechrau, mae dwy system yn rhan o'r broses: BOB a Thaliad. Nawr mae dau arall yn ymddangos:
- Gwasanaeth Cyllido, a fydd yn gofalu am broblemau gyda chyllido a chyfathrebu â gwasanaethau allanol.
- Offeryn Ad-daliad, sydd yn syml yn cynnwys cyfnewidfeydd newydd er mwyn peidio â chwyddo'r BOB.
Nawr mae'r broses yn edrych fel hyn:
- Mae BOB yn derbyn cais am ad-daliad.
- Mae BOB yn siarad am yr Offeryn Ad-daliad hwn.
- Mae’r Ad-daliad yn dweud wrth Daliad: “Dychwelyd yr arian.”
- Taliad yn dychwelyd yr arian.
- Mae Offeryn Ad-daliad a BOB yn cydamseru statws â'i gilydd, oherwydd am y tro mae ei angen ar y ddau ohonyn nhw. Nid ydym eto'n barod i newid yn llwyr i'r Offeryn Ad-dalu, gan fod gan BOB UI, adroddiadau ar gyfer cyfrifyddu, ac yn gyffredinol llawer o ddata na ellir ei drosglwyddo mor hawdd. Mae'n rhaid i chi eistedd ar ddwy gadair.
- Mae'r cais am gyllid yn mynd i ffwrdd.
O ganlyniad, gwnaethom fath o fws digwyddiad ar Kafka - bws digwyddiad, y dechreuodd popeth arno. Hurray, nawr mae gennym un pwynt o fethiant (coegni).
Mae'r manteision a'r anfanteision yn eithaf amlwg. Gwnaethom fws, sy'n golygu bod yr holl wasanaethau bellach yn dibynnu arno. Mae hyn yn symleiddio'r dyluniad, ond yn cyflwyno un pwynt methiant i'r system. Bydd Kafka yn chwalu, bydd y broses yn dod i ben.
Beth yw API sy'n cael ei yrru gan ddigwyddiadau
Mae ateb da i'r cwestiwn hwn yn yr adroddiad gan Martin Fowler (GOTO 2017) .
Yn gryno, yr hyn a wnaethom:
- Lapiwch bob cyfnewidiad asyncronaidd trwy storfa digwyddiadau. Yn hytrach na hysbysu pob defnyddiwr â diddordeb am newid statws dros y rhwydwaith, rydym yn ysgrifennu digwyddiad am newid statws i storfa ganolog, ac mae defnyddwyr sydd â diddordeb yn y pwnc yn darllen popeth sy'n ymddangos oddi yno.
- Hysbysiad yw'r digwyddiad yn yr achos hwn (hysbysiadau) bod rhywbeth wedi newid yn rhywle. Er enghraifft, mae statws y gorchymyn wedi newid. Gall defnyddiwr sydd â diddordeb mewn rhywfaint o ddata sy'n cyd-fynd â'r newid statws nad yw wedi'i gynnwys yn yr hysbysiad ddarganfod ei statws ei hun.
- Yr opsiwn mwyaf yw cyrchu digwyddiadau llawn, trosglwyddiad y wladwriaeth, lle mae digwyddiad yn cynnwys yr holl wybodaeth angenrheidiol ar gyfer prosesu: o ble y daeth a pha statws yr aeth, sut yn union y newidiodd y data, ac ati Yr unig gwestiwn yw dichonoldeb a faint o wybodaeth y gallwch fforddio ei storio.
Fel rhan o lansiad yr Offeryn Ad-dalu, gwnaethom ddefnyddio'r trydydd opsiwn. Roedd hyn yn symleiddio prosesu digwyddiadau gan nad oedd angen echdynnu gwybodaeth fanwl, ac roedd hefyd yn dileu'r senario lle mae pob digwyddiad newydd yn cynhyrchu byrstio o egluro ceisiadau gan ddefnyddwyr.
Gwasanaeth Offeryn Ad-daliad heb ei lwytho, felly Kafka mae mwy o flas ar y gorlan nag o angenrheidrwydd. Nid wyf yn credu pe bai'r gwasanaeth ad-daliad yn dod yn brosiect llwyth uchel, byddai busnes yn hapus.
Cyfnewid async FEL Y MAE
Ar gyfer cyfnewidfeydd asyncronig, mae'r adran PHP fel arfer yn defnyddio RabbitMQ. Casglwyd y data ar gyfer y cais, ei roi mewn ciw, a darllenodd defnyddiwr yr un gwasanaeth ef a'i anfon (neu ni anfonodd). Ar gyfer yr API ei hun, mae Lamoda yn defnyddio Swagger yn weithredol. Rydym yn dylunio API, yn ei ddisgrifio yn Swagger, ac yn cynhyrchu cod cleient a gweinydd. Rydym hefyd yn defnyddio JSON RPC 2.0 wedi'i wella ychydig.
Mewn rhai mannau defnyddir bysiau ESB, mae rhai yn byw ar activeMQ, ond, yn gyffredinol, RabbitMQ - safonol.
Cyfnewid async I FOD
Wrth ddylunio cyfnewid trwy fws digwyddiadau, gellir olrhain cyfatebiaeth. Yn yr un modd, rydym yn disgrifio cyfnewid data yn y dyfodol trwy ddisgrifiadau o strwythur digwyddiadau. Y fformat yaml, roedd yn rhaid i ni gynhyrchu'r cod ein hunain, mae'r generadur yn creu DTOs yn unol â'r fanyleb ac yn dysgu cleientiaid a gweinyddwyr i weithio gyda nhw. Mae cenhedlaeth yn mynd i ddwy iaith - golang a php. Mae hyn yn helpu i gadw llyfrgelloedd yn gyson. Mae'r generadur wedi'i ysgrifennu mewn golang, a dyna pam y cafodd yr enw gogi.
Mae cyrchu digwyddiadau ar Kafka yn beth arferol. Mae yna ateb o'r fersiwn prif fenter o Kafka Confluent, mae yna , ateb gan ein brodyr parth Zalando. Ein cymhelliant i ddechrau gyda Kafka fanila - mae hyn yn golygu gadael y datrysiad yn rhydd nes i ni benderfynu o'r diwedd a fyddwn ni'n ei ddefnyddio ym mhobman, a hefyd gadael lle i ni'n hunain symud a gwelliannau: rydyn ni eisiau cefnogaeth i'n JSON RPC 2.0, generaduron ar gyfer dwy iaith a gadewch i ni weld beth arall.
Mae'n eironig, hyd yn oed mewn achos mor hapus, pan fo busnes tebyg yn fras, Zalando, a wnaeth ateb eithaf tebyg, ni allwn ei ddefnyddio'n effeithiol.
Mae'r patrwm pensaernïol yn y lansiad fel a ganlyn: rydym yn darllen yn uniongyrchol o Kafka, ond yn ysgrifennu trwy ddigwyddiadau-bws yn unig. Mae llawer yn barod i'w ddarllen yn Kafka: broceriaid, balanswyr, ac mae'n fwy neu lai yn barod ar gyfer graddio llorweddol, roeddwn i eisiau cadw hyn. Roedden ni eisiau cwblhau'r recordiad trwy un Gateway aka Events-bus, a dyma pam.
Digwyddiadau-bws
Neu fws digwyddiad. Yn syml, porth http di-wladwriaeth yw hwn, sy'n cymryd sawl rôl bwysig:
- Cynhyrchu Dilysu — rydym yn gwirio bod y digwyddiadau yn bodloni ein manylebau.
- System meistr digwyddiad, hynny yw, dyma'r brif system a'r unig system yn y cwmni sy'n ateb y cwestiwn o ba ddigwyddiadau y mae strwythurau yn cael eu hystyried yn ddilys. Yn syml, mae dilysu'n ymwneud â mathau o ddata ac enums i nodi cynnwys yn llym.
- Swyddogaeth hash ar gyfer darnio - mae strwythur neges Kafka yn werth allwedd a chan ddefnyddio'r stwnsh allwedd mae'n cael ei gyfrifo ble i'w roi.
Pam
Rydym yn gweithio mewn cwmni mawr gyda phroses symlach. Pam newid unrhyw beth? Arbrawf yw hwn, a disgwyliwn fedi sawl mantais.
1:n+1 cyfnewid (un i lawer)
Mae Kafka yn ei gwneud hi'n hawdd iawn cysylltu defnyddwyr newydd â'r API.
Gadewch i ni ddweud bod gennych gyfeiriadur y mae angen i chi ei gadw'n gyfredol mewn sawl system ar unwaith (ac mewn rhai rhai newydd). Yn flaenorol, fe wnaethom ddyfeisio bwndel a oedd yn gweithredu set-API, a hysbyswyd y brif system am gyfeiriadau defnyddwyr. Nawr mae'r system feistr yn anfon diweddariadau i'r pwnc, ac mae pawb sydd â diddordeb yn ei ddarllen. Mae system newydd wedi ymddangos - rydym wedi arwyddo ar gyfer y pwnc. Ie, hefyd bwndel, ond yn symlach.
Yn achos ad-daliad-offeryn, sef darn o BOB, mae'n gyfleus i ni eu cadw cysoni drwy Kafka. Mae'r taliad yn dweud bod yr arian wedi'i ddychwelyd: daeth BOB, RT i wybod am hyn, newidiodd eu statws, daeth y Gwasanaeth Cyllido i wybod am hyn a chyhoeddodd siec.
Mae gennym gynlluniau i greu Gwasanaeth Hysbysu unedig a fyddai'n hysbysu'r cleient am newyddion ynglŷn â'i archeb / dychweliadau. Nawr mae'r cyfrifoldeb hwn wedi'i ledaenu rhwng systemau. Bydd yn ddigon inni ddysgu’r Gwasanaeth Hysbysiadau i ddal gwybodaeth berthnasol o Kafka ac ymateb iddi (ac analluogi’r hysbysiadau hyn mewn systemau eraill). Ni fydd angen cyfnewidiadau uniongyrchol newydd.
Wedi'i yrru gan ddata
Mae gwybodaeth rhwng systemau yn dod yn dryloyw - ni waeth pa “fenter waedlyd” sydd gennych ac ni waeth pa mor drwm yw eich ôl-groniad. Mae gan Lamoda adran Dadansoddeg Data sy'n casglu data o systemau ac yn ei roi ar ffurf y gellir ei hailddefnyddio, ar gyfer busnes ac ar gyfer systemau deallus. Mae Kafka yn caniatáu ichi roi llawer o ddata iddynt yn gyflym a chadw'r llif gwybodaeth hwnnw'n gyfredol.
Log atgynhyrchu
Nid yw negeseuon yn diflannu ar ôl cael eu darllen, fel yn RabbitMQ. Pan fydd digwyddiad yn cynnwys digon o wybodaeth i'w phrosesu, mae gennym hanes o newidiadau diweddar i'r gwrthrych, ac, os dymunir, y gallu i gymhwyso'r newidiadau hyn.
Mae cyfnod storio'r log atgynhyrchu yn dibynnu ar ddwyster yr ysgrifennu i'r pwnc hwn; Mae Kafka yn caniatáu ichi osod cyfyngiadau hyblyg ar amser storio a chyfaint data. Ar gyfer pynciau dwys, mae'n bwysig bod pob defnyddiwr yn cael amser i ddarllen y wybodaeth cyn iddi ddiflannu, hyd yn oed yn achos anweithredoldeb tymor byr. Fel arfer mae modd storio data ar gyfer unedau o ddyddiau, sy'n ddigon ar gyfer cefnogaeth.
Nesaf, ychydig o ailadrodd y ddogfennaeth, i'r rhai nad ydynt yn gyfarwydd â Kafka (mae'r llun hefyd o'r ddogfennaeth)
Mae gan AMQP giwiau: rydym yn ysgrifennu negeseuon i giw ar gyfer y defnyddiwr. Yn nodweddiadol, mae un ciw yn cael ei brosesu gan un system gyda'r un rhesymeg busnes. Os oes angen i chi hysbysu sawl system, gallwch ddysgu'r cais i ysgrifennu at sawl ciw neu ffurfweddu cyfnewid gyda'r mecanwaith gwyntyll, sy'n eu clonio ei hun.
Mae gan Kafka dyniad tebyg pwnc, lle rydych chi'n ysgrifennu negeseuon, ond nid ydyn nhw'n diflannu ar ôl eu darllen. Yn ddiofyn, pan fyddwch chi'n cysylltu â Kafka, rydych chi'n derbyn pob neges ac mae gennych chi'r opsiwn i gadw lle gwnaethoch chi adael. Hynny yw, rydych chi'n darllen yn olynol, efallai na fyddwch chi'n marcio'r neges wedi'i darllen, ond yn cadw'r id y gallwch chi wedyn barhau i ddarllen ohono. Mae'r ID y gwnaethoch setlo arno yn cael ei alw'n wrthbwyso, a'r mecanwaith yw cyflawni gwrthbwyso.
Yn unol â hynny, gellir gweithredu rhesymeg wahanol. Er enghraifft, mae gennym BOB mewn 4 achos ar gyfer gwahanol wledydd - mae Lamoda yn Rwsia, Kazakhstan, Wcráin, Belarus. Gan eu bod yn cael eu defnyddio ar wahân, mae ganddyn nhw gyfluniadau ychydig yn wahanol a'u rhesymeg busnes eu hunain. Nodwn yn y neges at ba wlad y mae'n cyfeirio. Mae pob defnyddiwr BOB ym mhob gwlad yn darllen gyda groupId gwahanol, ac os nad yw'r neges yn berthnasol iddyn nhw, maen nhw'n ei hepgor, h.y. yn cyflawni gwrthbwyso ar unwaith +1. Os yw ein Gwasanaeth Talu yn darllen yr un pwnc, yna mae'n gwneud hynny gyda grŵp ar wahân, ac felly nid yw gwrthbwyso yn croestorri.
Gofynion y digwyddiad:
- Cyflawnder data. Hoffwn i'r digwyddiad gael digon o ddata fel y gellir ei brosesu.
- Uniondeb. Rydym yn dirprwyo i Events-bus y cadarnhad bod y digwyddiad yn gyson ac y gall ei brosesu.
- Mae'r drefn yn bwysig. Yn achos dychwelyd, rydym yn cael ein gorfodi i weithio gyda hanes. Gyda hysbysiadau, nid yw'r gorchymyn yn bwysig, os ydynt yn hysbysiadau homogenaidd, bydd yr e-bost yr un fath waeth pa orchymyn a gyrhaeddodd gyntaf. Yn achos ad-daliad, mae proses glir; os byddwn yn newid y gorchymyn, bydd eithriadau'n codi, ni fydd yr ad-daliad yn cael ei greu na'i brosesu - byddwn yn y pen draw mewn statws gwahanol.
- Cysondeb. Mae gennym ni storfa, a nawr rydyn ni'n creu digwyddiadau yn lle API. Mae arnom angen ffordd o drosglwyddo gwybodaeth am ddigwyddiadau newydd a newidiadau i rai presennol i'n gwasanaethau yn gyflym ac yn rhad. Cyflawnir hyn trwy fanyleb gyffredin mewn ystorfa git ar wahân a generaduron cod. Felly, mae cleientiaid a gweinyddwyr mewn gwahanol wasanaethau yn cael eu cydlynu.
Kafka yn Lamoda
Mae gennym dri gosodiad Kafka:
- Logiau;
- Ymchwil a Datblygu;
- Digwyddiadau-bws.
Heddiw rydym yn sôn am y pwynt olaf yn unig. Mewn digwyddiadau-bws, nid oes gennym osodiadau mawr iawn - 3 broceriaid (gweinyddwyr) a dim ond 27 o bynciau. Fel rheol, un pwnc yw un broses. Ond pwynt cynnil yw hwn, a byddwn yn cyffwrdd ag ef yn awr.
Uchod mae'r graff rps. Mae'r broses ad-daliadau wedi'i marcio â llinell turquoise (ie, yr un ar yr echelin X), a'r llinell binc yw'r broses diweddaru cynnwys.
Mae catalog Lamoda yn cynnwys miliynau o gynhyrchion, ac mae'r data'n cael ei ddiweddaru drwy'r amser. Mae rhai casgliadau yn mynd allan o ffasiwn, mae rhai newydd yn cael eu rhyddhau i gymryd eu lle, ac mae modelau newydd yn ymddangos yn gyson yn y catalog. Rydyn ni'n ceisio rhagweld beth fydd yn ddiddorol i'n cwsmeriaid yfory, felly rydyn ni'n prynu pethau newydd yn gyson, yn tynnu lluniau ohonyn nhw ac yn diweddaru'r cas arddangos.
Mae copaon pinc yn ddiweddariadau cynnyrch, hynny yw, newidiadau mewn cynhyrchion. Gellir gweld bod y bois wedi cymryd lluniau, tynnu lluniau, ac yna eto! — llwytho pecyn o ddigwyddiadau.
Mae Lamoda Events yn defnyddio casys
Rydym yn defnyddio'r bensaernïaeth adeiledig ar gyfer y gweithrediadau canlynol:
- Dychwelyd olrhain statws: galw-i-weithredu ac olrhain statws o'r holl systemau cysylltiedig. Taliad, statws, cyllid, hysbysiadau. Yma fe wnaethon ni brofi'r dull, gwneud offer, casglu'r holl fygiau, ysgrifennu dogfennaeth a dweud wrth ein cydweithwyr sut i'w ddefnyddio.
- Diweddaru cardiau cynnyrch: cyfluniad, meta-ddata, nodweddion. Mae un system yn darllen (sy'n dangos), ac mae sawl un yn ysgrifennu.
- E-bost, gwthio a sms: mae'r gorchymyn wedi'i gasglu, mae'r gorchymyn wedi cyrraedd, mae'r dychweliad wedi'i dderbyn, ac ati, mae yna lawer ohonynt.
- Stoc, adnewyddu warws — diweddariad meintiol o eitemau, niferoedd yn unig: cyrraedd y warws, dychwelyd. Mae'n angenrheidiol bod yr holl systemau sy'n gysylltiedig â chadw nwyddau yn gweithredu gyda'r data mwyaf cyfredol. Ar hyn o bryd, mae'r system diweddaru stoc yn eithaf cymhleth; bydd Kafka yn ei symleiddio.
- Data Dadansoddi (Adran Ymchwil a Datblygu), offer ML, dadansoddeg, ystadegau. Rydym am i wybodaeth fod yn dryloyw - mae Kafka yn addas iawn ar gyfer hyn.
Nawr y rhan fwyaf diddorol am y bumps mawr a'r darganfyddiadau diddorol sydd wedi digwydd dros y chwe mis diwethaf.
Problemau dylunio
Gadewch i ni ddweud ein bod am wneud peth newydd - er enghraifft, trosglwyddo'r broses ddosbarthu gyfan i Kafka. Nawr mae rhan o'r broses yn cael ei gweithredu yn Prosesu Archeb yn BOB. Mae model statws y tu ôl i drosglwyddo archeb i'r gwasanaeth dosbarthu, symud i warws canolradd, ac ati. Mae monolith cyfan, hyd yn oed dau, ynghyd â chriw o APIs sy'n ymroddedig i gyflwyno. Maent yn gwybod llawer mwy am gyflwyno.
Mae'n ymddangos bod y rhain yn feysydd tebyg, ond mae gan y Prosesu Archeb yn BOB a'r System Llongau statws gwahanol. Er enghraifft, nid yw rhai gwasanaethau negesydd yn anfon statws canolraddol, ond dim ond y rhai terfynol: “cyflawnwyd” neu “colli”. Mae eraill, i'r gwrthwyneb, yn adrodd yn fanwl iawn am symud nwyddau. Mae gan bawb eu rheolau dilysu eu hunain: i rai, mae'r e-bost yn ddilys, sy'n golygu y bydd yn cael ei brosesu; i eraill nid yw'n ddilys, ond bydd y gorchymyn yn dal i gael ei brosesu oherwydd bod rhif ffôn ar gyfer cyswllt, a bydd rhywun yn dweud na fydd gorchymyn o'r fath yn cael ei brosesu o gwbl.
Ffrwd data
Yn achos Kafka, mae'r cwestiwn o drefnu'r llif data yn codi. Mae'r dasg hon yn cynnwys dewis strategaeth yn seiliedig ar sawl pwynt; gadewch i ni fynd drwyddynt i gyd.
Mewn un pwnc neu mewn rhai gwahanol?
Mae gennym fanyleb digwyddiad. Yn BOB rydym yn ysgrifennu bod angen cyflwyno archeb o'r fath a'r fath, a nodi: rhif y gorchymyn, ei gyfansoddiad, rhai SKUs a chodau bar, ac ati. Pan fydd y nwyddau'n cyrraedd y warws, bydd y danfoniad yn gallu derbyn statws, stampiau amser a phopeth sydd ei angen. Ond yna rydym am dderbyn diweddariadau ar y data hwn yn BOB. Mae gennym broses o'r chwith i dderbyn data o gyflenwi. Ai'r un digwyddiad yw hwn? Neu a yw hwn yn gyfnewidiad ar wahân sy'n haeddu ei bwnc ei hun?
Yn fwyaf tebygol, byddant yn debyg iawn, ac nid yw'r demtasiwn i wneud un pwnc yn ddi-sail, oherwydd mae pwnc ar wahân yn golygu defnyddwyr ar wahân, cyfluniadau ar wahân, cenhedlaeth ar wahân o hyn i gyd. Ond nid ffaith.
Maes newydd neu ddigwyddiad newydd?
Ond os ydych chi'n defnyddio'r un digwyddiadau, yna mae problem arall yn codi. Er enghraifft, ni all pob system ddosbarthu gynhyrchu'r math o DTO y gall BOB ei gynhyrchu. Rydyn ni'n anfon yr id atynt, ond nid ydyn nhw'n ei arbed oherwydd nad oes ei angen arnyn nhw, ac o safbwynt cychwyn y broses digwyddiad-bws, mae angen y maes hwn.
Os byddwn yn cyflwyno rheol ar gyfer digwyddiad-bws bod angen y maes hwn, yna rydym yn cael eu gorfodi i osod rheolau dilysu ychwanegol yn y BOB neu yn y triniwr digwyddiad cychwyn. Mae dilysu'n dechrau lledaenu drwy'r gwasanaeth cyfan - nid yw hyn yn gyfleus iawn.
Problem arall yw'r demtasiwn i ddatblygiad cynyddol. Dywedir wrthym fod angen ychwanegu rhywbeth at y digwyddiad, ac efallai, os meddyliwn amdano, y dylai fod wedi bod yn ddigwyddiad ar wahân. Ond yn ein cynllun ni, mae digwyddiad ar wahân yn bwnc ar wahân. Pwnc ar wahân yw'r broses gyfan a ddisgrifiais uchod. Mae'r datblygwr yn cael ei demtio i ychwanegu maes arall at sgema JSON a'i adfywio.
Yn achos ad-daliadau, fe wnaethom gyrraedd y digwyddiad o ddigwyddiadau mewn hanner blwyddyn. Cawsom un meta-ddigwyddiad o'r enw diweddariad ad-daliad, a oedd â maes math yn disgrifio beth oedd y diweddariad hwn mewn gwirionedd. Oherwydd hyn, cawsom switshis “rhyfeddol” gyda dilyswyr a ddywedodd wrthym sut i ddilysu'r digwyddiad hwn gyda'r math hwn.
Fersiynau digwyddiad
I ddilysu negeseuon yn Kafka gallwch eu defnyddio , ond bu raid gosod arno ar unwaith a defnyddio Confluent. Yn ein hachos ni, mae'n rhaid i ni fod yn ofalus wrth fersiynu. Ni fydd bob amser yn bosibl ailddarllen negeseuon o'r log atgynhyrchu oherwydd bod y model wedi “gadael”. Yn y bôn, mae'n troi allan i adeiladu fersiynau fel bod y model yn gydnaws yn ôl: er enghraifft, gwnewch faes yn ddewisol dros dro. Os yw'r gwahaniaethau'n rhy gryf, rydym yn dechrau ysgrifennu mewn pwnc newydd, ac yn trosglwyddo cleientiaid pan fyddant yn gorffen darllen yr hen un.
Trefn darllen gwarantedig rhaniadau
Mae pynciau y tu mewn i Kafka wedi'u rhannu'n rhaniadau. Nid yw hyn yn bwysig iawn tra ein bod yn dylunio endidau a chyfnewidfeydd, ond mae'n bwysig wrth benderfynu sut i'w ddefnyddio a'i raddfa.
Yn yr achos arferol, rydych chi'n ysgrifennu un pwnc yn Kafka. Yn ddiofyn, defnyddir un rhaniad, ac mae pob neges yn y pwnc hwn yn mynd iddo. Ac o ganlyniad mae'r defnyddiwr yn darllen y negeseuon hyn yn olynol. Gadewch i ni ddweud nawr bod angen i ni ehangu'r system fel bod negeseuon yn cael eu darllen gan ddau ddefnyddiwr gwahanol. Os, er enghraifft, rydych chi'n anfon SMS, yna gallwch chi ddweud wrth Kafka am wneud rhaniad ychwanegol, a bydd Kafka yn dechrau rhannu'r negeseuon yn ddwy ran - hanner yma, hanner yma.
Sut mae Kafka yn eu rhannu? Mae gan bob neges gorff (lle rydym yn storio JSON) ac allwedd. Gallwch atodi swyddogaeth hash i'r allwedd hon, a fydd yn pennu pa raniad y bydd y neges yn mynd iddo.
Yn ein hachos ni gydag ad-daliadau, mae hyn yn bwysig, os cymerwn ddau raniad, yna mae siawns y bydd defnyddiwr cyfochrog yn prosesu'r ail ddigwyddiad cyn y cyntaf a bydd trafferth. Mae'r swyddogaeth hash yn sicrhau bod negeseuon gyda'r un allwedd yn dod i ben yn yr un rhaniad.
Digwyddiadau yn erbyn gorchmynion
Mae hon yn broblem arall y daethom ar ei thraws. Mae digwyddiad yn ddigwyddiad penodol: rydyn ni'n dweud bod rhywbeth wedi digwydd yn rhywle (something_happened), er enghraifft, cafodd eitem ei chanslo neu fe ddigwyddodd ad-daliad. Os bydd rhywun yn gwrando ar y digwyddiadau hyn, yna yn ôl “canslo eitem,” bydd yr endid ad-daliad yn cael ei greu, a bydd “ad-daliad wedi digwydd” yn cael ei ysgrifennu yn rhywle yn y gosodiadau.
Ond fel arfer, pan fyddwch chi'n dylunio digwyddiadau, nid ydych chi eisiau eu hysgrifennu yn ofer - rydych chi'n dibynnu ar y ffaith y bydd rhywun yn eu darllen. Mae temtasiwn mawr i ysgrifennu nid rhywbeth_digwyddodd (item_canceled, refund_refunded), ond something_should_be_done. Er enghraifft, mae'r eitem yn barod i'w dychwelyd.
Ar y naill law, mae'n awgrymu sut y bydd y digwyddiad yn cael ei ddefnyddio. Ar y llaw arall, mae'n swnio'n llawer llai fel enw digwyddiad arferol. Ar ben hynny, nid yw'n bell o'r fan hon i'r gorchymyn do_something. Ond nid oes gennych unrhyw sicrwydd bod rhywun yn darllen y digwyddiad hwn; ac os darllenwch ef, yna yr ydych yn ei ddarllen yn llwyddiannus; ac os darllenasoch ef yn llwyddianus, yna gwnaethoch rywbeth, a bu rhywbeth llwyddiannus. Y foment y daw digwyddiad yn do_something, daw adborth yn angenrheidiol, ac mae hynny'n broblem.
Mewn cyfnewid asyncronaidd yn RabbitMQ, pan fyddwch chi'n darllen y neges, ewch i http, mae gennych chi ymateb - o leiaf bod y neges wedi'i derbyn. Pan fyddwch chi'n ysgrifennu at Kafka, mae neges y gwnaethoch chi ei hysgrifennu at Kafka, ond nid ydych chi'n gwybod dim am sut y cafodd ei phrosesu.
Felly, yn ein hachos ni, bu'n rhaid i ni gyflwyno digwyddiad ymateb a sefydlu monitro fel pe bai cymaint o ddigwyddiadau'n cael eu hanfon, ar ôl amser o'r fath, dylai'r un nifer o ddigwyddiadau ymateb gyrraedd. Os na fydd hyn yn digwydd, yna mae'n ymddangos bod rhywbeth wedi mynd o'i le. Er enghraifft, pe baem yn anfon y digwyddiad “item_ready_to_refund”, rydym yn disgwyl y bydd ad-daliad yn cael ei greu, bydd yr arian yn cael ei ddychwelyd i'r cleient, a bydd y digwyddiad “money_refunded” yn cael ei anfon atom. Ond nid yw hyn yn sicr, felly mae angen monitro.
Nuances
Mae yna broblem eithaf amlwg: os ydych chi'n darllen o bwnc yn ddilyniannol, a bod gennych chi rywfaint o neges wael, bydd y defnyddiwr yn cwympo, ac ni fyddwch chi'n mynd ymhellach. Mae angen atal pob defnyddiwr, ymrwymo gwrthbwyso ymhellach i barhau i ddarllen.
Roeddem yn gwybod amdano, rydym yn cyfrif arno, ac eto fe ddigwyddodd. A digwyddodd hyn oherwydd bod y digwyddiad yn ddilys o safbwynt digwyddiadau-bws, roedd y digwyddiad yn ddilys o safbwynt dilysydd y cais, ond nid oedd yn ddilys o safbwynt PostgreSQL, oherwydd yn ein un system MySQL gyda UNSIGNED INT, ac yn y newydd ei ysgrifennu roedd gan y system PostgreSQL gyda INT yn unig. Mae ei faintioli ychydig yn llai, ac nid oedd yr Id yn ffitio. Bu farw Symfony gydag eithriad. Roeddem ni, wrth gwrs, wedi dal yr eithriad oherwydd ein bod yn dibynnu arno, ac yn mynd i gyflawni'r gwrthbwyso hwn, ond cyn hynny roeddem am gynyddu'r atebydd problem, gan i'r neges gael ei phrosesu'n aflwyddiannus. Mae'r cownteri yn y prosiect hwn hefyd yn y gronfa ddata, ac mae Symfony eisoes wedi cau cyfathrebu â'r gronfa ddata, a lladdodd yr ail eithriad y broses gyfan heb gyfle i gyflawni gwrthbwyso.
Bu'r gwasanaeth yn gorwedd am beth amser - yn ffodus, gyda Kafka nid yw hyn mor ddrwg, oherwydd erys y negeseuon. Pan fydd gwaith yn cael ei adfer, gallwch orffen eu darllen. Mae'n gyfforddus.
Mae gan Kafka y gallu i osod gwrthbwyso mympwyol trwy offer. Ond i wneud hyn, mae angen i chi atal yr holl ddefnyddwyr - yn ein hachos ni, paratoi datganiad ar wahân lle na fydd unrhyw ddefnyddwyr, adleoli. Yna yn Kafka gallwch chi symud y gwrthbwyso trwy offer, a bydd y neges yn mynd drwodd.
Naws arall - log atgynhyrchu vs rdkafka.so - yn gysylltiedig â manylion ein prosiect. Rydym yn defnyddio PHP, ac yn PHP, fel rheol, mae pob llyfrgell yn cyfathrebu â Kafka trwy'r ystorfa rdkafka.so, ac yna mae rhyw fath o ddeunydd lapio. Efallai mai dyma ein hanawsterau personol, ond daeth yn amlwg nad yw ail-ddarllen darn o'r hyn yr oeddem wedi'i ddarllen eisoes mor hawdd. Yn gyffredinol, roedd problemau meddalwedd.
Gan ddychwelyd at fanylion gweithio gyda pharwydydd, mae wedi'i ysgrifennu'n gywir yn y ddogfennaeth defnyddwyr >= rhaniadau pwnc. Ond cefais wybod am hyn lawer yn hwyrach nag y byddwn wedi hoffi. Os ydych chi eisiau graddio a chael dau ddefnyddiwr, mae angen o leiaf ddau raniad arnoch chi. Hynny yw, pe bai gennych un rhaniad lle'r oedd 20 mil o negeseuon wedi cronni, a'ch bod wedi gwneud un newydd, ni fydd nifer y negeseuon yn cael eu cydraddoli'n fuan. Felly, er mwyn cael dau ddefnyddiwr cyfochrog, mae angen i chi ddelio â rhaniadau.
Monitro
Rwy'n meddwl y bydd y ffordd yr ydym yn ei fonitro yn gliriach fyth pa broblemau sydd yn y dull presennol.
Er enghraifft, rydym yn cyfrifo faint o gynhyrchion yn y gronfa ddata sydd wedi newid eu statws yn ddiweddar, ac, yn unol â hynny, dylai digwyddiadau fod wedi digwydd yn seiliedig ar y newidiadau hyn, ac rydym yn anfon y rhif hwn i'n system fonitro. Yna o Kafka cawn yr ail rif, faint o ddigwyddiadau a gofnodwyd mewn gwirionedd. Yn amlwg, dylai'r gwahaniaeth rhwng y ddau rif hyn fod yn sero bob amser.
Yn ogystal, mae angen i chi fonitro sut mae'r cynhyrchydd yn ei wneud, a yw digwyddiadau-bws wedi derbyn negeseuon, a sut mae'r defnyddiwr yn gwneud. Er enghraifft, yn y siartiau isod, mae Ad-daliad Offeryn yn gwneud yn dda, ond mae'n amlwg bod gan BOB rai problemau (copaon glas).
Soniais eisoes am oedi grŵp defnyddwyr. Yn fras, dyma nifer y negeseuon heb eu darllen. Yn gyffredinol, mae ein defnyddwyr yn gweithio'n gyflym, felly mae'r oedi fel arfer yn 0, ond weithiau gall fod brig tymor byr. Gall Kafka wneud hyn allan o'r bocs, ond mae angen i chi osod cyfwng penodol.
Mae prosiect a fydd yn rhoi mwy o wybodaeth i chi am Kafka. Yn syml, mae'n defnyddio'r API grŵp defnyddwyr i roi statws sut mae'r grŵp hwn yn ei wneud. Yn ogystal ag Iawn a Methwyd, mae rhybudd, a gallwch ddarganfod na all eich defnyddwyr ymdopi â chyflymder y cynhyrchiad - nid oes ganddynt amser i brawfddarllen yr hyn sydd wedi'i ysgrifennu. Mae'r system yn eithaf smart ac yn hawdd i'w defnyddio.
Dyma sut olwg sydd ar yr ymateb API. Dyma'r grŵp bob-live-fifa, rhaniad refund.update.v1, statws OK, oedi 0 - y gwrthbwyso terfynol olaf o'r fath ac o'r fath.
Monitro updated_at CLG (yn sownd) Soniais eisoes. Er enghraifft, mae'r cynnyrch wedi newid i'r statws ei fod yn barod i'w ddychwelyd. Rydyn ni'n gosod Cron, sy'n dweud, os nad yw'r gwrthrych hwn wedi mynd i ad-daliad mewn 5 munud (rydym yn dychwelyd arian trwy systemau talu yn gyflym iawn), yna aeth rhywbeth o'i le yn bendant, ac mae hyn yn bendant yn achos cefnogaeth. Felly, yn syml, rydym yn cymryd Cron, sy'n darllen pethau o'r fath, ac os ydynt yn fwy na 0, yna mae'n anfon rhybudd.
I grynhoi, mae defnyddio digwyddiadau yn gyfleus pan:
- mae angen gwybodaeth ar sawl system;
- nid yw canlyniad prosesu yn bwysig;
- prin yw'r digwyddiadau neu ddigwyddiadau bach.
Mae'n ymddangos bod gan yr erthygl bwnc penodol iawn - API asyncronaidd ar Kafka, ond mewn cysylltiad ag ef hoffwn argymell llawer o bethau ar unwaith.
Yn gyntaf, nesaf mae angen i ni aros tan fis Tachwedd; ym mis Ebrill bydd fersiwn St. Petersburg, ac ym mis Mehefin byddwn yn siarad am lwythi uchel yn Novosibirsk.
Yn ail, mae awdur yr adroddiad, Sergei Zaika, yn aelod o Bwyllgor Rhaglen ein cynhadledd newydd ar reoli gwybodaeth . Mae'r gynhadledd yn un diwrnod, yn cael ei chynnal ar Ebrill 26, ond mae ei rhaglen yn ddwys iawn.
Ac fe fydd ym mis Mai и (gyda DevOpsConf wedi'i gynnwys) - gallwch hefyd awgrymu eich pwnc yno, siarad am eich profiad a chwyno am eich conau wedi'u stwffio.
Ffynhonnell: hab.com