Çi dikare pargîdaniyek wusa mezin a wekî Lamoda, bi pêvajoyek birêkûpêk û bi dehan karûbarên bi hev ve girêdayî, neçar bike ku nêzîkatiya xwe bi girîngî biguhezîne? Motivasyon dikare bi tevahî cûda be: ji zagonsaz heya xwesteka ceribandinê ya ku di hemî bernamenûsan de ye.
Lê ev nayê vê wateyê ku hûn nikanin li ser feydeyên zêde hesab bikin. Sergey Zaika dê ji we re bêje ku hûn bi rastî hûn dikarin çi bi dest bixin ger hûn API-ya bûyeran li ser Kafka bicîh bînin (). Dê bê guman li ser fîşekên mezin û vedîtinên balkêş jî were axaftin - ceribandin bêyî wan nabe.
Daxuyandî: Ev gotar li ser materyalên ji civînek ku Sergey di Mijdara 2018-an de li ser HighLoad ++ pêk anî ye. Tecrûbeya zindî ya Lamoda ya xebata bi Kafka re ji raporên din ên li ser bernameyê ne kêmtir guhdaran kişand. Em difikirin ku ev mînakek hêja ye ku hûn dikarin û divê her gav mirovên hemfikir bibînin, û organîzatorên HighLoad++ dê berdewam bikin ku hewl bidin ku atmosferek ji bo vê yekê biafirînin.
Di derbarê pêvajoyê de
Lamoda platformek e-bazirganiya mezin e ku xwedan navenda pêwendiyê, karûbarê radestkirinê (û gelek pargîdaniyên xwe), stûdyoyek wêneyan, depoyek mezin e, û ev hemî li ser nermalava xwe dimeşe. Bi dehan awayên dravdanê hene, hevkarên b2b hene ku dibe ku hin an hemî van karûbaran bikar bînin û dixwazin agahdariya nûjen li ser hilberên xwe bizanibin. Wekî din, Lamoda ji bilî Federasyona Rûsyayê li sê welatan dixebite û li wir her tişt hinekî cûda ye. Bi tevahî, belkî zêdetirî sed awayên mîhengkirina fermanek nû hene, ku divê bi awayê xwe were pêvajo kirin. Hemî ev bi arîkariya bi dehan karûbarên ku carinan bi awayên ne-eşkere danûstandinê dikin dixebite. Pergalek navendî jî heye ku berpirsiyariya wê ya sereke statuyên fermanê ne. Em jê re dibêjin BOB, ez pê re dixebitim.
Amûra Vegerandinê ya bi API-ya bûyeran ve
Peyva bûyer-rêveberî bi tevahî xapînok e; hinekî din em ê bi hûrgulî diyar bikin ka mebest ji vê yekê çi ye. Ez ê bi çarçoweya ku me biryar da ku li Kafka nêzîkatiya API-ya bûyeran biceribînim dest pê bikim.
Li her firotgehê, ji bilî fermanên ku xerîdar lê didin, carinan hene ku ji firotgehê tê xwestin ku drav vegerîne ji ber ku hilber li gorî xerîdar nebû. Ev pêvajoyek pêvajoyek kurt e: heke hewce be, em agahdarî zelal dikin û drav vediguhezînin.
Lê veger ji ber guhertinên di qanûnê de tevlihevtir bû, û me neçar ma ku ji bo wê mîkroxizmetek cihêreng bicîh bînin.
Motivasyona me:
- Qanûna FZ-54 - Bi kurtî, qanûn hewce dike ku di nav çend hûrdeman de SLA-ya pir kurt a çend hûrdeman de ji daîreya bacê re di derheqê her danûstendina diravî de, çi veger an jî meqbûz be, rapor bike. Em, wekî pargîdaniyek e-bazirganî, gelek operasyonan pêk tînin. Ji hêla teknîkî ve, ev tê wateya berpirsiyariya nû (û ji ber vê yekê karûbarek nû) û di hemî pergalên têkildar de çêtirkirin.
- BOB perçe kirin projeyek navxweyî ya pargîdanî ye ku BOB ji hejmareke mezin ji berpirsiyariyên ne-bingehîn xilas dike û tevliheviya wê ya giştî kêm dike.
Ev diagram pergalên Lamoda yên sereke nîşan dide. Niha piraniya wan zêdetir in komstêreke ji 5-10 mîkroxizmetên li dora monolîtek hûrbûyî. Ew hêdî hêdî mezin dibin, lê em hewl didin ku wan piçûktir bikin, ji ber ku bicihkirina perçeya ku di navîn de hatî hilbijartin tirsnak e - em nekarin destûrê bidin ku ew bikeve. Em neçar in ku hemî danûstendinan (tîrên) veqetînin û vê rastiyê bihesibînin ku dibe ku yek ji wan nederbasdar be.
BOB di heman demê de gelek danûstendinan jî heye: pergalên dravdanê, pergalên radestkirinê, pergalên ragihandinê, hwd.
Teknîkî BOB ev e:
- ~ 150 hezar rêzikên kodê + ~ 100 hezar rêzikên ceribandinê;
- php7.2 + Zend 1 & Symfony Components 3;
- > 100 API & ~ 50 entegrasyonên derve;
- 4 welat bi mantiqa karsaziya xwe.
Bicihkirina BOB biha û bi êş e, hêjmara kod û pirsgirêkên ku ew çareser dike ew qas e ku kes nikane wê hemî têxe serê xwe. Bi gelemperî, gelek sedem hene ku wê hêsan bikin.
Pêvajoya Vegerê
Di destpêkê de, du pergal di pêvajoyê de beşdar dibin: BOB û Payment. Niha du kesên din xuya dikin:
- Xizmeta Fîskalîzasyonê, ku dê pirsgirêkên bi darayîkirin û danûstendina bi karûbarên derveyî re çareser bike.
- Amûra Vegerandinê, ku bi tenê danûstendinên nû vedihewîne da ku BOB-ê zêde neke.
Niha pêvajo wiha xuya dike:
- BOB daxwazek ji bo vegerandinê distîne.
- BOB li ser vê Amûra Vegerandinê dipeyive.
- Amûra Vegerandinê ji Paymentê re dibêje: "Pere vegerîne."
- Payment pere vedigerîne.
- Amûra Vegerandinê û BOB statûyan bi hevûdu re hevdeng dikin, ji ber ku heya niha ew her du jî jê re hewce ne. Em hîn ne amade ne ku bi tevahî veguherînin Amûra Vegerandinê, ji ber ku BOB xwedan UI, raporên ji bo hesabkirinê, û bi gelemperî gelek daneyên ku nekarin bi hêsanî werin veguheztin heye. Divê hûn li ser du kursiyan rûnin.
- Daxwaza fiskalîzasyonê ji holê radibe.
Di encamê de, me li ser Kafka celebek otobusek bûyerê çêkir - bûyer-otobus, ku her tişt li ser dest pê kir. Hêro, naha xalek me ya têkçûnek (serkazm) heye.
Pros û neyînî pir eşkere ne. Me otobusek çêkir, ev tê vê wateyê ku naha hemî karûbar bi wê ve girêdayî ne. Ev sêwiranê hêsan dike, lê yek xalek têkçûnê di pergalê de destnîşan dike. Kafka wê biqelişe, pêvajo raweste.
API-ya bûyer-rêveberî çi ye
Bersivek baş a vê pirsê di raporta Martin Fowler de ye (GOTO 2017) .
Bi kurtî me çi kir:
- Hemî danûstendinên asynkron bi rê ve biqedînin depokirina bûyeran. Li şûna ku em her xerîdarek eleqedar di derheqê guheztina statûyek li ser torê de agahdar bikin, em bûyerek li ser guheztina statûyê li depoyek navendî dinivîsin, û xerîdarên ku bi mijarê re eleqedar dibin her tiştê ku ji wir xuya dike dixwînin.
- Bûyer di vê rewşê de agahdariyek e (agahdariyan) ku tiştek li cihekî guherî. Mînakî, rewşa fermanê guherî. Xerîdarek ku bi hin daneyên digel guhartina statûyê ya ku di ragihandinê de ne tê de eleqedar dibe, dikare bixwe rewşa wê bibîne.
- Vebijarka herî zêde çavkaniya bûyerê ya tam e, veguhestina dewletê, di kîjan bûyerê de hemî agahdariya ku ji bo pêvajoyê hewce dike dihewîne: ew ji ku hatî û berbi kîjan statûyê ve çû, çawa bi rastî dane guheztin û hwd. Pirs tenê îmkan û çendeya agahdariya ku hûn dikarin hilînin e.
Wekî beşek ji destpêkirina Amûra Vegerandinê, me vebijarka sêyemîn bikar anî. Vê pêvajoya bûyerê ya hêsankirî ji ber ku ne hewce bû ku agahdariya hûrgulî derxîne, hem jî ew senaryoya ku her bûyerek nû teqînek zelalkirina daxwazên ji xerîdaran çêdike ji holê rakir.
Xizmeta Amûra Vegerandinê ne barkirin, ji ber vê yekê Kafka ji hewcedariyê zêdetir tama pênûsê heye. Ez nafikirim ku ger karûbarê vegerandinê bibe projeyek bargiran, karsaz dê kêfxweş bibe.
Async danûstendina AS IS
Ji bo danûstendinên asynchronous, beşa PHP bi gelemperî RabbitMQ bikar tîne. Me daneyên ji bo daxwazê berhev kir, ew xist rêzek, û xerîdarê heman karûbarê ew xwend û şand (an neşand). Ji bo API bixwe, Lamoda bi rengek çalak Swagger bikar tîne. Em API-yek dîzayn dikin, wê di Swagger de vedibêjin, û koda xerîdar û serverê diafirînin. Em di heman demê de JSON RPC 2.0-ê hinekî pêşkeftî bikar tînin.
Li hin deveran otobusên ESB têne bikar anîn, hin li ser activeMQ dijîn, lê, bi gelemperî, RabbitMQ - standard.
Danûstendina Async TO BE
Dema ku bi navgîniya bûyer-otobusê danûstendina sêwirandî, analojiyek dikare were şopandin. Em bi heman rengî danûstendina daneya pêşerojê bi navgîniya ravekirinên avahiya bûyerê vedibêjin. Forma yaml, diviya bû ku me bi xwe hilberîna kodê bikira, jenerator li gorî diyardeyê DTO-yan diafirîne û xerîdar û pêşkêşkeran fêr dike ku bi wan re bixebitin. Nifş diçe du zimanan - golang û php. Ev dibe alîkar ku pirtûkxane hevgirtî bimînin. Generator bi golangê hatiye nivîsandin, ji ber vê yekê jî navê gogî lê kiriye.
Çavkaniya bûyeran li ser Kafka tiştek tîpîk e. Çareseriyek ji guhertoya pargîdaniya sereke ya Kafka Confluent heye, heye , çareseriyek ji birayên me yên domainê Zalando. Yên me motîvasyona ku bi vanilla Kafka dest pê bike - ev tê wê wateyê ku çareseriyê azad bihêlin heya ku em di dawiyê de biryar bidin ka em ê wê li her deverê bikar bînin an na, û her weha ji xwe re cîhê manevra û çêtirbûnê bihêlin: em ji bo xwe piştgirî dixwazin. JSON RPC 2.0, jeneratorên ji bo du zimanan û em bibînin ka çi din.
Tiştekî îronîk e ku tewra di rewşek wusa bextewar de jî, dema ku karsaziyek hema hema dişibihe, Zalando, ku çareseriyek hema hema bi heman rengî çêkiriye, em nikanin wê bi bandor bikar bînin.
Nimûneya mîmarî ya di destpêkê de wiha ye: em rasterast ji Kafka dixwînin, lê tenê bi bûyer-otobusê dinivîsin. Di Kafka de ji bo xwendinê gelek amade hene: broker, balansker, û ew ji bo pîvandina horizontî kêm-zêde amade ye, min xwest ez vê biparêzim. Me xwest ku tomarkirinê bi yek Gateway aka Events-otobusê temam bikin, û li vir çima ye.
Bûyer-otobus
An jî otobusek bûyerê. Ev tenê dergehek http ya bêdewlet e, ku çend rolên girîng digire:
- Hilberîna Validation - em kontrol dikin ku bûyer bi taybetmendiyên me re têkildar in.
- Pergala masterê ya bûyerê, ango, ev pergala sereke û yekane ye di pargîdaniyê de ku bersiva vê pirsê dide ka kîjan bûyer bi kîjan avahiyan re derbasdar têne hesibandin. Verastkirin bi tenê cûreyên daneyê û navnîşan vedihewîne da ku naverokê bi hişkî diyar bike.
- Fonksiyona Hash ji bo parvekirinê - strukturê peyama Kafka nirx-kilît e û bi karanîna haşa kilîtê tê hesab kirin ku li ku derê were danîn.
Çima
Em di pargîdaniyek mezin de bi pêvajoyek birêkûpêk dixebitin. Çima tiştek guhertin? Ev ceribandinek e, û em hêvî dikin ku gelek feydeyan bistînin.
1:n+1 pevguhertin (yek ji gelekan)
Kafka girêdana xerîdarên nû bi API-yê re pir hêsan dike.
Ka em bibêjin pelrêçek we heye ku hûn hewce ne ku bi yekcarî di gelek pergalê de (û di hin nû de) de nûve bikin. Berê, me pakêtek ku set-API pêk anî îcad kir, û pergala master ji navnîşanên xerîdar agahdar bû. Naha pergala master nûvekirinên mijarê dişîne, û her kesê ku eleqedar e wê dixwîne. Pergalek nû derketiye - me ew ji bo mijarê îmze kir. Erê, di heman demê de pakêt jî, lê hêsantir.
Di mijara vegerandin-amûra, ku perçeyek BOB-ê ye, ji me re hêsan e ku em wan bi Kafka re hevdem bikin. Payment dibêje ku drav hatine vegerandin: BOB, RT vê yekê fêhm kirin, statûyên xwe guheztin, Servîsa Fîskalîzasyonê li ser vê yekê fêhm kir û kontrolek derxist.
Planên me hene ku em Karûbarek Agahdariyê ya yekbûyî biafirînin ku dê xerîdar li ser nûçeyên di derheqê ferman/vegera wî de agahdar bike. Niha ev berpirsiyarî di navbera sîsteman de belav bûye. Dê bes be ku em Karûbarê Agahdariyê hîn bikin ku agahdariya têkildar ji Kafka bigire û bersivê bide (û van agahdariyan di pergalên din de neçalak bike). Dê danûstendinên rasterast ên nû ne hewce be.
Daneyên danûstandin
Agahdariya di navbera pergalan de şefaf dibe - ferq nake ku we çi "karsaziya xwînxwar" heye û her çi qas paşverûtiya we pir be. Lamoda xwedan dezgehek Daneyên Analytics e ku daneyan ji pergalan berhev dike û wê di formek ji nû ve bi kar tîne, hem ji bo karsaziyê û hem jî ji bo pergalên hişmend. Kafka destûrê dide te ku hûn bi lez û bez gelek daneyan bidin wan û wan agahdarî rojane bihêlin.
Têketina dubarekirinê
Mesaj piştî ku têne xwendin winda nabin, wekî RabbitMQ. Dema ku bûyerek ji bo pêvajoyê têra agahdarî dihewîne, dîroka me ya guheztinên nû yên li ser objektê heye, û heke bixwaze, şiyana ku em van guhertinan bicîh bînin hene.
Demjimêra hilanînê ya qeyda dubarekirinê bi tundiya nivîsandina vê mijarê ve girêdayî ye; Kafka dihêle hûn bi nermî li ser dema hilanînê û qebareya daneyê sînoran bicîh bikin. Ji bo mijarên zexm, girîng e ku hemî xerîdar dem hebin ku agahdariya berî windabûnê bixwînin, tewra di rewşa neçalakbûna kurt-kurt de. Bi gelemperî gengaz e ku meriv daneyan hilîne yekîneyên rojan, ku ji bo piştgiriyê têra xwe dike.
Paşê, ji bo kesên ku bi Kafka nizanin (wêne jî ji belgeyê ye) piçekî vegerandina belgeyê.
AMQP rêzên xwe hene: em ji bo xerîdar ji rêzek peyaman dinivîsin. Bi gelemperî, yek rêz ji hêla yek pergalê ve bi heman mantiqa karsaziyê ve tête pêvajoyê kirin. Heke hûn hewce ne ku gelek pergalan agahdar bikin, hûn dikarin serîlêdanê hîn bikin ku li çend rêzan binivîsin an bi mekanîzmaya fanout-ê ku wan bixwe klon dike veguheztinê mîheng bikin.
Kafka jî xwedî abstrakasyoneke bi vî rengî ye mijar, ku hûn tê de peyaman dinivîsin, lê piştî xwendinê winda nabin. Bi xwerû, gava ku hûn bi Kafka ve girêdidin, hûn hemî peyaman distînin û vebijarka we heye ku hûn li cîhê ku we lê hiştibin hilînin. Ango, hûn bi rêzê dixwînin, dibe ku hûn peyamê wekî xwendî nîşan nekin, lê id-ya ku hûn hingê dikarin xwendinê bidomînin hilînin. Nasnameya ku we li ser rûniştiye jê re offset tê gotin, û mekanîzma jî commit offset e.
Li gorî vê yekê, mantiqên cûda dikarin bêne bicîh kirin. Mînakî, me ji bo welatên cihê di 4 mînakan de BOB heye - Lamoda li Rûsya, Qazaxistanê, Ukrayna, Belarusê ye. Ji ber ku ew ji hev veqetandî têne bicîh kirin, ew xwedan mîhengên piçûktir û mantiqa karsaziya xwe ne. Em di peyamê de destnîşan dikin ku ew behsa kîjan welatî dike. Her xerîdarek BOB-ê li her welatek bi komekIdek cihêreng dixwîne, û heke peyam ji wan re derbas nebe, ew jê derbas dibin, yanî. yekser offset +1 dike. Ger heman mijar ji hêla Karûbarê meya Paymentê ve were xwendin, wê hingê ew wiya bi komek cûda re dike, û ji ber vê yekê veqetandin hevdu nagirin.
Pêdiviyên bûyerê:
- Tevahiya daneyê. Ez dixwazim bûyer bi têra xwe daneyên xwe hebe da ku were pêvajo kirin.
- Linavketinî. Em verastkirina ku bûyer domdar e û ew dikare wê bişopîne ji Events-otobusê re vedibêje.
- Ferman girîng e. Di mijara vegerê de em neçar in ku bi dîrokê re bixebitin. Bi ragihandinan re, rêz ne girîng e, heke ew agahdariya homojen bin, e-name dê yek be bêyî ku kîjan ferman yekem were. Di doza vegerandinê de, pêvajoyek zelal heye; ger em rêzê biguhezînin, dê îstîsna çêbibin, vegerandin nayê çêkirin an pêvajo - em ê di rewşek cûda de biqedin.
- Consistency. Dikanek me heye, û naha em li şûna API-yê bûyeran diafirînin. Pêdiviya me bi rêyek heye ku em bi lez û bez agahdariya li ser bûyerên nû û guheztinên heyî ji karûbarên xwe re bişînin. Ev bi navgîniyek hevbeş di depoyek git û jeneratorên kodê yên cihêreng de tê bidestxistin. Ji ber vê yekê, xerîdar û pêşkêşker di karûbarên cûda de hevrêz in.
Kafka li Lamoda
Sê sazûmanên me yên Kafka hene:
- Logs;
- R&D;
- Bûyer-otobus.
Îro em tenê behsa xala dawîn dikin. Di bûyer-otobusê de, sazgehên me yên pir mezin tune - 3 broker (server) û tenê 27 mijar. Wekî qaîdeyek, yek mijar yek pêvajo ye. Lê ev xalek nazik e, û em ê niha li ser wê bisekinin.
Li jor grafika rps heye. Pêvajoya vegerandinê bi xêzek turquoise (erê, ya li ser eksê X) tê nîşankirin, û xeta pembe jî pêvajoya nûvekirina naverokê ye.
Kataloga Lamoda bi mîlyonan hilberan vedihewîne, û daneyên her dem têne nûve kirin. Hin berhevok ji modayê derdikevin, yên nû têne berdan ku şûna wan digirin, û modelên nû bi domdarî di katalogê de derdikevin. Em hewl didin ku pêşbîn bikin ka dê sibê ji xerîdarên me re çi balkêş be, ji ber vê yekê em bi domdarî tiştên nû dikirin, wan wêne dikin û pêşangehê nûve dikin.
Pelên pembe nûvekirinên hilberê ne, ango guhertinên hilberan in. Tê dîtin ku xortan wêne kişandin, wêne kişandin, û paşê dîsa! - pakêtek bûyeran bar kir.
Lamoda Events rewşên bikar tînin
Em mîmariya çêkirî ji bo karên jêrîn bikar tînin:
- Vegere şopandina rewşa: banga-çalakiyê û şopandina statûyê ji hemî pergalên têkildar. Tezmînat, statû, darayîkirin, ragihandin. Li vir me nêzîkatî ceriband, amûr çêkir, hemî xeletî berhev kirin, belge nivîsandin û ji hevkarên xwe re got ku meriv wê çawa bikar bîne.
- Nûvekirina kartên hilberê: veavakirin, meta-dane, taybetmendî. Pergalek dixwîne (ku nîşan dide), û çend kes dinivîsin.
- Email, push û sms: emir kom bûye, emr hatiye, veger hatiye qebulkirin û hwd., gelek in.
- Stock, nûkirina wargehê - Nûvekirina hêjmarî ya tiştan, tenê hejmar: hatina bargehê, vegerandin. Pêdivî ye ku hemî pergalên ku bi rezervkirina tiştan ve girêdayî ne bi daneyên herî heyî tevbigerin. Heya nuha, pergala nûvekirina stock pir tevlihev e; Kafka wê hêsan bike.
- Analyziya Dîtan (Beşa R&D), Amûrên ML, analîtîk, statîstîk. Em dixwazin agahdarî zelal bin - Kafka ji bo vê yekê baş e.
Naha beşê balkêştir di derbarê qelpên mezin û vedîtinên balkêş ên ku di şeş mehên borî de qewimîne.
Pirsgirêkên sêwiranê
Ka em bibêjin ku em dixwazin tiştek nû bikin - mînakî, tevahiya pêvajoya radestkirinê ji Kafka re veguhezînin. Naha beşek pêvajoyê di Pêvajoya Orderê de di BOB de tête bicîh kirin. Li pişt veguheztina fermanê ji bo karûbarê radestkirinê, tevgera berbi depoyek navîn û hwd modelek statûyek heye. Tevahiya monolîtek heye, tewra du jî, plus komek API-yên ku ji bo radestkirinê hatine veqetandin. Ew di derbarê radestkirinê de pir zêde dizanin.
Dixuye ku ev deverên mîna hev in, lê Pêvajoya Orderê di BOB û Pergala Barkirinê de statûyên cûda hene. Mînakî, hin karûbarên kurye statûyên navîn naşînin, lê tenê yên paşîn dişînin: "desthilatdar" an "winda". Yên din, berevajî, bi hûrgulî li ser tevgera tiştan radigihînin. Her kes rêzikên xwe yên pejirandinê hene: ji bo hin kesan, e-name derbasdar e, ku tê vê wateyê ku ew ê were pêvajo kirin; ji bo yên din ew ne derbasdar e, lê ferman dê dîsa jî were pêvajo kirin ji ber ku jimareyek têlefonê ji bo têkiliyê heye, û kesek dê bêje ku fermanek wusa dê qet neyê pêvajo kirin.
Herikîna daneyan
Di mijara Kafka de pirsa birêxistinkirina herikîna daneyan derdikeve pêş. Ev peywir bi hilbijartina stratejiyek li ser bingeha çend xalan ve girêdayî ye; ka em hemî wan bişopînin.
Di mijarekê de yan di mijarên cuda de?
Taybetmendiyek me ya bûyerê heye. Di BOB de em dinivîsin ku pêdivî ye ku fermanek wusa û wusa were radest kirin, û destnîşan dikin: hejmara fermanê, pêkhateya wê, hin SKU û kodên bar, hwd. Dema ku eşya digihîje depoyê, radest dê karibe statû, dem û her tiştê ku hewce dike bistîne. Lê paşê em dixwazin nûvekirinan li ser van daneyan di BOB de bistînin. Me pêvajoyek berevajî ya wergirtina daneyan ji radestkirinê heye. Ma ev heman bûyer e? An jî ev danûstendinek cuda ye ku mijara xwe heq dike?
Bi îhtimaleke mezin, ew ê pir dişibin hev, û ceribandina çêkirina yek mijarê ne bêbingeh e, ji ber ku mijarek veqetandî tê wateya xerîdarên veqetandî, mîhengên cihêreng, nifşek cûda ya van hemîyan. Lê ne rastiyek.
Qada nû an bûyerek nû?
Lê heke hûn heman bûyeran bikar bînin, wê hingê pirsgirêkek din derdikeve. Mînakî, ne hemî pergalên radestkirinê dikarin celebek DTO-ya ku BOB dikare çêbike çêbikin. Em nasnameyê ji wan re dişînin, lê ew wê xilas nakin ji ber ku ew ne hewce ne, û ji hêla destpêkirina pêvajoya bûyer-otobusê ve, ev zevî pêdivî ye.
Ger em ji bo bûyer-otobusê qaîdeyek destnîşan bikin ku ev zevî pêdivî ye, wê hingê em neçar in ku di BOB-ê de an jî di rêvekera bûyera destpêkê de qaîdeyên pejirandinê yên din saz bikin. Verastkirin dest pê dike ku li seranserê karûbarê belav bibe - ev ne pir hêsan e.
Pirsgirêkek din jî ceribandina pêşveçûna zêde ye. Ji me re tê gotin ku pêdivî ye ku tiştek li bûyerê were zêdekirin, û dibe ku, ger em li ser bifikirin, diviyabû ew bûyerek cihê bûya. Lê di plana me de, bûyerek cûda mijarek cûda ye. Mijarek veqetandî tevahiya pêvajoya ku min li jor diyar kir e. Pêşvebir tê ceribandin ku bi tenê qadek din li şemaya JSON zêde bike û wê ji nû ve çêbike.
Di mijara vegerandinê de, em di nîv salekê de gihîştin bûyera bûyeran. Me yek meta-bûyerek bi navê nûvekirina vegerandinê hebû, ku qadek celebê wê diyar dike ku ev nûvekirin bi rastî çi ye. Ji ber vê yekê, me bi verastkeran re guheztinên "ecêb" hebûn ku ji me re digotin ka meriv çawa vê bûyerê bi vî rengî erê bike.
Guhertoya bûyerê
Ji bo pejirandina peyamên li Kafka hûn dikarin bikar bînin , lê hewce bû ku tavilê li ser wê were danîn û Confluent bikar bînin. Di rewşa me de, divê em bi guhertoyê re baldar bin. Dê her gav ne mumkun be ku peyamên ji qeyda dubarekirinê ji nû ve werin xwendin ji ber ku model "hiştiye". Di bingeh de, derdikeve holê ku guhertoyan ava dike da ku model bi paş ve lihevhatî be: Mînakî, zeviyek demkî vebijarkî çêbikin. Ger cûdahî pir xurt bin, em di mijarek nû de dest bi nivîsandinê dikin, û gava ku xwendina ya kevin qedandin xerîdaran vediguhezînin.
Rêza xwendina dabeşan a garantîkirî
Mijarên di hundirê Kafka de li ser dabeşan têne dabeş kirin. Dema ku em sazî û danûstendinan sêwiran dikin ev ne pir girîng e, lê gava ku meriv biryar dide ka meriv wê çawa bikar tîne û mezin dike girîng e.
Di rewşa asayî de, hûn di Kafka de mijarekê dinivîsin. Bi xwerû, yek dabeşek tê bikar anîn, û hemî peyamên di vê mijarê de diçin wê. Û di encamê de xerîdar van peyaman bi rêz dixwîne. Ka em bibêjin naha pêdivî ye ku em pergalê berfireh bikin da ku peyam ji hêla du xerîdarên cûda ve werin xwendin. Heke, bo nimûne, hûn SMS dişînin, wê hingê hûn dikarin ji Kafka re bibêjin ku dabeşek zêde çêbike, û Kafka dê dest bi parvekirina peyaman bike du beş - nîv li vir, nîv li vir.
Kafka çawa wan parçe dike? Her peyamek laşek heye (ku em JSON tê de hilînin) û kilîtek. Hûn dikarin fonksiyonek hash bi vê mifteyê ve girêdin, ku dê diyar bike ku dê peyam têkeve kîjan dabeşkirinê.
Di doza me ya vegerandinê de, ev girîng e, ger em du dabeşan bavêjin, wê hingê şansek heye ku xerîdarek paralel bûyera duyemîn berî ya yekem bişopîne û dê pirsgirêk derkeve. Fonksiyona hash piştrast dike ku peyamên bi heman mifteyê di heman dabeşkirinê de biqede.
Bûyerên vs fermanan
Ev jî pirsgirêkeke din a ku em pê re rû bi rû mane ye. Bûyer bûyerek diyar e: em dibêjin ku li deverek tiştek qewimiye (tiştek_qewimî), mînakek tişt hate betal kirin an vegerandin çêbû. Ger kesek guh bide van bûyeran, wê hingê li gorî "maddeya betalkirî" dê saziya vegerandinê were afirandin, û "vegerandin çêbû" dê li cîhek sazûmanan were nivîsandin.
Lê bi gelemperî, gava ku hûn bûyeran sêwirînin, hûn naxwazin wan vala binivîsin - hûn xwe dispêrin vê yekê ku kesek dê wan bixwîne. Ceribandinek mezin heye ku meriv ne tiştek_çebûye (tişt_betalkirin, vegerandin_vegerandin), lê tiştek_divê_be_binivîse. Mînakî, tişt ji bo vegerandinê amade ye.
Ji aliyekî ve, ew pêşniyar dike ku bûyer dê çawa were bikar anîn. Ji hêla din ve, ew pir kêmtir wekî navek bûyerek normal xuya dike. Wekî din, ew ji vir ne dûr e fermana do_something. Lê garantiya we tune ku kesek vê bûyerê bixwîne; û eger tu bixwînî, wê demê tu bi serkeftî dixwînî; û heke we ew bi serfirazî xwend, wê hingê we tiştek kir, û ew tiştek serfiraz bû. Wexta ku bûyerek bibe do_something, bersiv hewce dibe, û ew pirsgirêkek e.
Di danûstendina asynchronous de li RabbitMQ, gava ku hûn peyamê dixwînin, biçin http, bersivek we heye - bi kêmanî ew peyam hat wergirtin. Dema ku tu ji Kafka re dinivîsî, peyamek ku te ji Kafka re nivîsî heye, lê tu tiştek nizane ka ew çawa hatiye pêvajokirin.
Ji ber vê yekê, di rewşa me de, me neçar bû ku bûyerek bersivdayînê destnîşan bikin û çavdêriyek saz bikin, da ku heke ewqas bûyer hatin şandin, piştî demek wusa û filan jî heman hejmar bûyerên bersivdayînê bigihîje. Ger ev yek pêk neyê, wê hingê xuya dike ku tiştek xelet çûye. Mînakî, heke me bûyera "item_ready_to_refund" şand, em li bendê ne ku vegerandinek were çêkirin, dê drav ji xerîdar re were vegerandin, û bûyera "money_refunded" ji me re were şandin. Lê ev ne diyar e, ji ber vê yekê çavdêrî hewce ye.
Nuances
Pirsgirêkek pir eşkere heye: heke hûn ji mijarekê bi rêzê bixwînin, û we hin peyamek xirab hebe, xerîdar dê bikeve, û hûn ê bêtir neçin. Hûn hewce ne hemî serfkaran rawestînin, ji bo berdewamkirina xwendinê bêtir guheztinan bikin.
Me pê dizanibû, me hesabê wê dikir, lê dîsa jî ew çêbû. Û ev yek çêbû ji ber ku bûyer ji hêla bûyeran-otobusê ve derbasdar bû, bûyer ji hêla erêkerê serîlêdanê ve derbasdar bû, lê ji hêla PostgreSQL ve ne derbasdar bû, ji ber ku di pergala me de yekane MySQL bi INT-ya UNESIGNED re, û di ya nû hatî nivîsandin de pergala PostgreSQL tenê bi INT re hebû. Mezinahiya wî piçek piçûktir e, û Id li hev nedihat. Symfony bi îstîsnayek mir. Me, bê guman, îstîsna girt ji ber ku me pişta xwe bi wê ve girêda, û me diçû ku vê bertengkirinê pêk bînin, lê berî wê me dixwest ku kêşeya pirsgirêkê zêde bikin, ji ber ku peyam bêserkeftin hate pêvajo kirin. Di vê projeyê de jimarvan jî di databasê de ne, û Symfony berê pêwendiya bi databasê re girtiye, û îstîsna duyemîn tevahiya pêvajoyê bêyî ku şansek jihevkirinê bikuje.
Karûbar ji bo demekê rawestiya - bi bextewarî, bi Kafka re ev ne ewqas xirab e, ji ber ku peyam dimînin. Dema ku kar ji nû ve were vegerandin, hûn dikarin xwendina wan biqedînin. Rehet e.
Kafka xwedan şiyana ku bi amûrkirinê veqetandinek keyfî saz bike. Lê ji bo kirina vê yekê, hûn hewce ne ku hemî xerîdar rawestînin - di doza me de, serbestberdanek cihêreng amade bikin ku tê de dê xerîdar, veguheztin tune bin. Dûv re di Kafka de hûn dikarin bi navgîniya amûrkirinê veguhezînin, û peyam dê derbas bibe.
Nîşanek din - log replication vs rdkafka.so - bi taybetmendiyên projeya me ve girêdayî ye. Em PHP-ê bikar tînin, û di PHP-ê de, wekî qaîdeyek, hemî pirtûkxane bi riya depoya rdkafka.so bi Kafka re diaxivin, û dûv re celebek pêçan heye. Dibe ku ev zehmetiyên me yên kesane bin, lê derket holê ku bi tenê ji nû ve xwendina perçeyek ji tiştê ku me berê xwendibû ne ew qas hêsan e. Bi gelemperî, pirsgirêkên nermalavê hebûn.
Vegere ser taybetmendiyên xebata bi dabeşan re, ew rast di belgeyê de hatî nivîsandin serfkaran >= dabeşên mijarê. Lê min li ser vê yekê ji ya ku ez dixwazim pir dereng fêr bûm. Heke hûn dixwazin pîvandin û du xerîdar hebin, hûn bi kêmî ve du dabeşan hewce ne. Ango, heke we yek parçeyek ku tê de 20 hezar peyam kom bûbûn hebûya û we yek nû çêkiribû, dê di demek nêzîk de hejmara peyaman neyê hevber kirin. Ji ber vê yekê, ji bo ku du xerîdarên paralel hebin, hûn hewce ne ku bi dabeşan re mijûl bibin.
Ingopandin
Ez wisa difikirim ku bi awayê ku em çavdêriyê bikin dê hîn zelaltir bibe ka di nêzîkatiya heyî de çi pirsgirêk hene.
Mînakî, em hesab dikin ka çend hilberên di databasê de van demên dawî rewşa xwe guhezîne, û li gorî vê yekê, divê bûyer li gorî van guhertinan çêbibin, û em vê hejmarê ji pergala xweya çavdêriyê re dişînin. Dûre ji Kafka em hejmara duyemîn distînin, ku bi rastî çend bûyer hatine tomarkirin. Eşkere ye ku ferqa di navbera van her du hejmaran de divê her dem sifir be.
Wekî din, hûn hewce ne ku çavdêriyê bikin ka çêker çawa dike, gelo bûyer-otobus peyam distînin, û xerîdar çawa dike. Mînakî, di nexşeyên jêrîn de, Amûra Vegerandinê baş dixebite, lê BOB eşkere hin pirsgirêk hene (pişkên şîn).
Min berê behsa derengiya koma xerîdar kir. Bi gelemperî, ev hejmara peyamên nexwendî ye. Bi gelemperî, xerîdarên me zû dixebitin, ji ber vê yekê dereng bi gelemperî 0 ye, lê carinan dibe ku pezek kurt-kurt hebe. Kafka dikare vê yekê ji qutiyê bike, lê hûn hewce ne ku navberek diyar bikin.
Projeyek heye ku dê bêtir agahdarî li ser Kafka bide we. Ew bi tenê API-koma xerîdar bikar tîne da ku statûyê bide ka ev kom çawa dike. Digel OK û Biserneket, hişyariyek heye, û hûn dikarin fêr bibin ku xerîdarên we nikanin bi leza hilberînê re mijûl bibin - wextê wan tune ku tiştê ku hatî nivîsandin rast bikin. Pergalek pir jîr û karanîna hêsan e.
Ev e ku bersiva API-ê wekî xuya dike. Li vir koma bob-live-fifa, partition refund.update.v1, statûya OK, derengiya 0 heye - guheztina dawîn a weha û wusa.
Ingopandin updated_at SLA (qewimî) Min berê jî behs kiribû. Mînakî, hilber guheriye rewşa ku ew ji bo vegerê amade ye. Em Cron saz dikin, ku dibêje heke di nav 5 hûrdeman de ev tişt neçûye vegerandinê (em drav bi pergalên dravdanê pir zû vegerînin), wê hingê bê guman tiştek xelet derket, û ev bê guman ji bo piştgirîyê dozek e. Ji ber vê yekê, em tenê Cron digirin, ku tiştên weha dixwîne, û heke ew ji 0-ê mezintir bin, wê hingê ew hişyariyek dişîne.
Bi kurtasî, karanîna bûyeran dema ku hêsan e:
- agahdarî ji hêla çend pergalên pêdivî ye;
- encama pêvajoyê ne girîng e;
- çend bûyer an bûyerên piçûk hene.
Wusa dixuye ku gotar xwedan mijarek pir taybetî ye - API-ya asynchronous li ser Kafka, lê di pêwendiya wê de ez dixwazim bi yekcarî gelek tiştan pêşniyar bikim.
Pêşî, paşê Pêwîst e em li benda meha Mijdarê bin; di meha Nîsanê de dê guhertoyek St.
Ya duyemîn, nivîskarê raporê, Sergei Zaika, endamê Komîteya Bernameyê ya konferansa me ya nû ya li ser rêveberiya zanînê ye. . Konferans yek-rojî ye, dê di 26ê Nîsanê de pêk were, lê bernameya wê pir giran e.
Û ew ê di Gulanê de be и (bi nav de DevOpsConf) - hûn jî dikarin li wir mijara xwe pêşniyar bikin, li ser ezmûna xwe bipeyivin û li ser konên xwe yên dagirtî gilî bikin.
Source: www.habr.com