Uzoefu wa kuunda huduma ya Zana ya Kurejesha Pesa na API isiyosawazisha kwenye Kafka

Ni nini kinachoweza kulazimisha kampuni kubwa kama Lamoda, iliyo na mchakato ulioratibiwa na huduma nyingi zilizounganishwa, kubadilisha sana mbinu yake? Kuhamasishwa kunaweza kuwa tofauti kabisa: kutoka kwa sheria hadi hamu ya kujaribu asili katika watengeneza programu wote.

Lakini hii haina maana kwamba huwezi kutegemea faida za ziada. Sergey Zaika atakuambia ni nini hasa unaweza kushinda ikiwa utatumia API inayoendeshwa na matukio kwenye Kafka (wachache) Pia hakika kutakuwa na mazungumzo juu ya risasi kubwa na uvumbuzi wa kupendeza - majaribio hayawezi kufanya bila wao.

Kanusho: Makala haya yanatokana na nyenzo kutoka kwa mkutano ambao Sergey alifanya mnamo Novemba 2018 kuhusu HighLoad++. Uzoefu wa moja kwa moja wa Lamoda wa kufanya kazi na Kafka uliwavutia wasikilizaji sio chini ya ripoti zingine kwenye ratiba. Tunafikiri huu ni mfano bora wa ukweli kwamba unaweza na unapaswa kupata watu wenye nia kama hiyo kila wakati, na waandaaji wa HighLoad++ wataendelea kujaribu kuunda mazingira yanayofaa hili.

Kuhusu mchakato

Lamoda ni jukwaa kubwa la e-commerce ambalo lina kituo chake cha mawasiliano, huduma ya utoaji (na washirika wengi), studio ya picha, ghala kubwa, na yote haya yanaendeshwa na programu yake mwenyewe. Kuna njia nyingi za kulipa, washirika wa b2b ambao wanaweza kutumia baadhi au huduma hizi zote na wanataka kujua maelezo ya kisasa kuhusu bidhaa zao. Kwa kuongeza, Lamoda inafanya kazi katika nchi tatu badala ya Shirikisho la Urusi na kila kitu ni tofauti kidogo huko. Kwa jumla, pengine kuna njia zaidi ya mia moja za kusanidi utaratibu mpya, ambao lazima ufanyike kwa njia yake mwenyewe. Yote hii inafanya kazi kwa msaada wa huduma kadhaa ambazo wakati mwingine huwasiliana kwa njia zisizo wazi. Pia kuna mfumo mkuu ambao jukumu lake kuu ni hali ya mpangilio. Tunamwita BOB, nafanya naye kazi.

Zana ya Kurejesha Pesa kwa kutumia API inayoendeshwa na matukio

Neno linaloendeshwa na matukio limedukuliwa kabisa; mbele kidogo tutafafanua kwa undani zaidi maana ya hii. Nitaanza na muktadha ambao tuliamua kujaribu mbinu ya API inayoendeshwa na matukio huko Kafka.

Katika duka lolote, pamoja na maagizo ambayo wateja hulipa, kuna wakati duka huhitajika kurejesha pesa kwa sababu bidhaa haikufaa mteja. Huu ni mchakato mfupi sana: tunafafanua habari, ikiwa ni lazima, na kuhamisha pesa.

Lakini kurudi kukawa ngumu zaidi kwa sababu ya mabadiliko ya sheria, na ilibidi tutekeleze huduma ndogo tofauti kwa hiyo.

Motisha yetu:

1. Sheria FZ-54 - kwa ufupi, sheria inahitaji kuripoti kwa ofisi ya ushuru kuhusu kila shughuli ya fedha, iwe ni kurejesha au risiti, ndani ya muda mfupi wa SLA wa dakika chache. Sisi, kama kampuni ya e-commerce, tunafanya shughuli nyingi. Kitaalam, hii inamaanisha jukumu jipya (na kwa hivyo huduma mpya) na maboresho katika mifumo yote inayohusika.
2. BOB imegawanyika ni mradi wa ndani wa kampuni ili kupunguza BOB kutoka kwa idadi kubwa ya majukumu yasiyo ya msingi na kupunguza utata wake kwa ujumla.

Mchoro huu unaonyesha mifumo kuu ya Lamoda. Sasa wengi wao ni zaidi kundinyota la huduma ndogo 5-10 karibu na monolith inayopungua. Wanakua polepole, lakini tunajaribu kuwafanya kuwa ndogo, kwa sababu kupeleka kipande kilichochaguliwa katikati ni cha kutisha - hatuwezi kuruhusu kuanguka. Tunalazimika kuhifadhi kubadilishana zote (mishale) na kuzingatia ukweli kwamba yeyote kati yao anaweza kugeuka kuwa haipatikani.

BOB pia ina ubadilishanaji mwingi: mifumo ya malipo, mifumo ya utoaji, mifumo ya arifa, nk.

Kitaalam BOB ni:

• ~ 150k mistari ya kanuni + ~ 100k mistari ya majaribio;
• php7.2 + Zend 1 & Symfony Vipengele 3;
• >100 API & ~50 miunganisho ya nje;
• Nchi 4 zenye mantiki zao za kibiashara.

Kupeleka BOB ni ghali na chungu, kiasi cha msimbo na matatizo hutatua ni kwamba hakuna mtu anayeweza kuweka yote katika vichwa vyao. Kwa ujumla, kuna sababu nyingi za kurahisisha.

Mchakato wa Kurudisha

Hapo awali, mifumo miwili inahusika katika mchakato: BOB na Malipo. Sasa mbili zaidi zinaonekana:

• Huduma ya Ufadhili, ambayo itashughulikia shida na ufadhili na mawasiliano na huduma za nje.
• Zana ya Kurejesha Pesa, ambayo ina ubadilishanaji mpya ili usiingize BOB.

Sasa mchakato unaonekana kama hii:

1. BOB inapokea ombi la kurejeshewa pesa.
2. BOB inazungumza kuhusu Zana hii ya Kurejesha Pesa.
3. Zana ya Kurejesha Pesa inaambia Malipo: "Rudisha pesa."
4. Malipo yanarudisha pesa.
5. Zana ya Kurejesha Pesa na BOB husawazisha hali kwa kila mmoja, kwa sababu kwa sasa wote wanaihitaji. Bado hatuko tayari kubadili kabisa kwa Zana ya Kurejesha Pesa, kwa kuwa BOB ina UI, inaripoti kwa uhasibu, na kwa ujumla data nyingi ambazo haziwezi kuhamishwa kwa urahisi. Unapaswa kukaa kwenye viti viwili.
6. Ombi la ufadhili linatoweka.

Kama matokeo, tulifanya aina ya basi ya hafla kwenye Kafka - basi ya hafla, ambayo kila kitu kilianza. Hurray, sasa tuna nukta moja ya kutofaulu (kejeli).

Faida na hasara ni dhahiri. Tulifanya basi, ambayo ina maana kwamba sasa huduma zote zinategemea. Hii hurahisisha muundo, lakini inaleta nukta moja ya kutofaulu kwenye mfumo. Kafka itaanguka, mchakato utaacha.

API inayoendeshwa na matukio ni nini

Jibu zuri kwa swali hili liko kwenye ripoti ya Martin Fowler (GOTO 2017) "Maana Nyingi za Usanifu Unaoendeshwa na Tukio".

Kwa kifupi tulichofanya:

1. Malizia ubadilishanaji wote usiolingana kupitia uhifadhi wa matukio. Badala ya kumfahamisha kila mtumiaji anayevutiwa kuhusu mabadiliko ya hali kwenye mtandao, tunaandika tukio kuhusu mabadiliko ya hali kwenye hifadhi ya kati, na watumiaji wanaovutiwa na mada husoma kila kitu kinachoonekana kutoka hapo.
2. Tukio katika kesi hii ni arifa (meddelanden) kwamba kitu kimebadilika mahali fulani. Kwa mfano, hali ya utaratibu imebadilika. Mtumiaji anayevutiwa na baadhi ya data inayoambatana na mabadiliko ya hali ambayo hayajajumuishwa kwenye arifa anaweza kujua hali yake mwenyewe.
3. Chaguo la juu ni kupata tukio kamili, uhamisho wa serikali, katika tukio ambalo lina habari zote muhimu kwa usindikaji: ilitoka wapi na ni hali gani ilikwenda, jinsi data ilivyobadilika, nk Swali pekee ni uwezekano na kiasi cha habari ambacho unaweza kumudu kuhifadhi.

Kama sehemu ya uzinduzi wa Zana ya Kurejesha Pesa, tulitumia chaguo la tatu. Uchakataji huu wa matukio uliorahisishwa kwa kuwa hapakuwa na haja ya kutoa maelezo ya kina, na pia uliondoa hali ambapo kila tukio jipya hutoa ufafanuzi wa maombi ya kupokea kutoka kwa watumiaji.

Huduma ya Zana ya Kurejesha haijapakiwa, hivyo Kafka kuna zaidi ya ladha ya kalamu kuliko umuhimu. Sidhani kama huduma ya kurejesha pesa ikawa mradi wa mzigo mkubwa, biashara itakuwa na furaha.

Ubadilishanaji wa Async AS IS

Kwa ubadilishanaji wa asynchronous, idara ya PHP kawaida hutumia RabbitMQ. Tulikusanya data ya ombi, tukaiweka kwenye foleni, na mtumiaji wa huduma sawa aliisoma na kuituma (au hakuituma). Kwa API yenyewe, Lamoda hutumia Swagger kikamilifu. Tunatengeneza API, tunaielezea katika Swagger, na kuzalisha mteja na msimbo wa seva. Pia tunatumia JSON RPC 2.0 iliyoboreshwa kidogo.

Katika maeneo mengine mabasi ya ESB hutumiwa, mengine yanaishi kwenye activeMQ, lakini, kwa ujumla, RabbitMQ - kiwango.

Ubadilishanaji wa Async TO BE

Wakati wa kubuni kubadilishana kupitia matukio-basi, mlinganisho unaweza kufuatiliwa. Vile vile tunaelezea ubadilishanaji wa data wa siku zijazo kupitia maelezo ya muundo wa tukio. Umbizo la yaml, ilitubidi kufanya utengenezaji wa msimbo sisi wenyewe, jenereta huunda DTO kulingana na vipimo na hufundisha wateja na seva kufanya kazi nazo. Kizazi huenda katika lugha mbili - golang na php. Hii husaidia kuweka maktaba sawa. Jenereta imeandikwa kwa golang, ndiyo sababu ilipata jina la gogi.

Utoaji wa hafla kwenye Kafka ni jambo la kawaida. Kuna suluhisho kutoka kwa toleo kuu la biashara la Kafka Confluent, kuna nakadi, suluhisho kutoka kwa kikoa chetu ndugu Zalando. Yetu motisha ya kuanza na vanilla Kafka - hii inamaanisha kuacha suluhisho bila malipo hadi hatimaye tuamue ikiwa tutaitumia kila mahali, na pia kujiachia nafasi ya ujanja na uboreshaji: tunataka msaada kwa ajili yetu. JSON RPC 2.0, jenereta za lugha mbili na wacha tuone ni nini kingine.

Inashangaza kwamba hata katika kesi ya furaha kama hii, wakati kuna biashara takriban sawa, Zalando, ambayo ilifanya suluhisho takriban sawa, hatuwezi kuitumia kwa ufanisi.

Muundo wa usanifu wakati wa uzinduzi ni kama ifuatavyo: tunasoma moja kwa moja kutoka Kafka, lakini tunaandika tu kupitia matukio-basi. Kuna mengi tayari kwa kusoma katika Kafka: madalali, wasawazishaji, na iko tayari zaidi au chini kwa kuongeza mlalo, nilitaka kuweka hii. Tulitaka kukamilisha kurekodi kupitia basi moja la Gateway aka Events-basi, na hii ndiyo sababu.

Matukio-basi

Au basi ya tukio. Hili ni lango la http lisilo na uraia, ambalo huchukua majukumu kadhaa muhimu:

• Kuzalisha Uthibitishaji - tunaangalia kuwa matukio yanakidhi vipimo vyetu.
• Mfumo mkuu wa hafla, yaani, hii ndiyo mfumo kuu na pekee katika kampuni ambayo hujibu swali la matukio ambayo miundo inachukuliwa kuwa halali. Uthibitishaji unahusisha tu aina za data na enum ili kubainisha maudhui kikamilifu.
• Utendaji wa hashi kwa sharding - muundo wa ujumbe wa Kafka ni wa thamani-msingi na kwa kutumia hashi ya ufunguo huhesabiwa mahali pa kuiweka.

Kwa nini

Tunafanya kazi katika kampuni kubwa na mchakato ulioratibiwa. Kwa nini ubadilishe chochote? Hili ni jaribio, na tunatarajia kuvuna faida kadhaa.

1:n+1 kubadilishana (moja hadi nyingi)

Kafka hurahisisha sana kuunganisha watumiaji wapya kwenye API.

Wacha tuseme unayo saraka ambayo unahitaji kusasisha katika mifumo kadhaa mara moja (na katika zingine mpya). Hapo awali, tulivumbua kifurushi kilichotekeleza set-API, na mfumo mkuu uliarifiwa kuhusu anwani za watumiaji. Sasa mfumo mkuu hutuma sasisho kwa mada, na kila mtu anayevutiwa anaisoma. Mfumo mpya umeonekana - tuliusajili kwa mada. Ndio, pia kifungu, lakini rahisi zaidi.

Kwa upande wa chombo cha kurejesha pesa, ambacho ni kipande cha BOB, ni rahisi kwetu kuziweka zikiwa zimesawazishwa kupitia Kafka. Malipo yanasema kwamba pesa zilirejeshwa: BOB, RT waligundua juu ya hili, walibadilisha hali zao, Huduma ya Fiscalization iligundua kuhusu hili na kutoa hundi.

Tuna mipango ya kuunda Huduma iliyounganishwa ya Arifa ambayo ingemjulisha mteja kuhusu habari kuhusu agizo/rejesho lake. Sasa jukumu hili limeenea kati ya mifumo. Itatutosha kufundisha Huduma ya Arifa kupata taarifa muhimu kutoka Kafka na kujibu (na kuzima arifa hizi katika mifumo mingine). Hakuna ubadilishanaji mpya wa moja kwa moja utahitajika.

Inaendeshwa na data

Taarifa kati ya mifumo inakuwa wazi - haijalishi ni "biashara gani ya umwagaji damu" uliyo nayo na haijalishi ni rekodi yako kubwa kiasi gani. Lamoda ina idara ya Uchanganuzi wa Data ambayo hukusanya data kutoka kwa mifumo na kuiweka katika fomu inayoweza kutumika tena, kwa ajili ya biashara na mifumo ya akili. Kafka hukuruhusu kuwapa data nyingi haraka na kusasisha habari hiyo.

Replication logi

Ujumbe haupotei baada ya kusomwa, kama katika RabbitMQ. Wakati tukio lina maelezo ya kutosha kwa ajili ya usindikaji, tuna historia ya mabadiliko ya hivi karibuni kwa kitu, na, ikiwa ni lazima, uwezo wa kutumia mabadiliko haya.

Kipindi cha uhifadhi wa logi ya urudufishaji inategemea ukubwa wa kuandika kwa mada hii; Kafka hukuruhusu kuweka vikomo vya muda wa kuhifadhi na kiasi cha data kwa urahisi. Kwa mada ya kina, ni muhimu kwamba watumiaji wote wawe na wakati wa kusoma habari kabla ya kutoweka, hata katika hali ya kutofanya kazi kwa muda mfupi. Kwa kawaida inawezekana kuhifadhi data kwa vitengo vya siku, ambayo ni ya kutosha kwa msaada.

Ifuatayo, kuelezea tena nyaraka, kwa wale ambao hawajui Kafka (picha pia ni kutoka kwa nyaraka)

AMQP ina foleni: tunaandika ujumbe kwa foleni kwa watumiaji. Kwa kawaida, foleni moja huchakatwa na mfumo mmoja wenye mantiki sawa ya biashara. Iwapo unahitaji kuarifu mifumo kadhaa, unaweza kufundisha programu kuandika kwa foleni kadhaa au kusanidi ubadilishanaji na utaratibu wa fanout, ambao hujifananisha yenyewe.

Kafka ina muhtasari sawa mada, ambayo unaandika ujumbe, lakini hazipotee baada ya kusoma. Kwa chaguo-msingi, unapounganisha kwa Kafka, unapokea ujumbe wote na una chaguo la kuhifadhi ulipoachia. Hiyo ni, unasoma kwa kufuatana, unaweza usitie alama kuwa ujumbe umesomwa, lakini hifadhi kitambulisho ambacho unaweza kuendelea kusoma. Kitambulisho ulichotulia kinaitwa offset, na utaratibu umekamilika.

Ipasavyo, mantiki tofauti inaweza kutekelezwa. Kwa mfano, tuna BOB katika matukio 4 kwa nchi tofauti - Lamoda iko Urusi, Kazakhstan, Ukraine, Belarus. Kwa kuwa zimetumwa kando, zina usanidi tofauti kidogo na mantiki yao ya biashara. Tunaonyesha katika ujumbe ambayo inarejelea nchi. Kila mtumiaji wa BOB katika kila nchi anasoma na groupId tofauti, na ikiwa ujumbe hauwahusu, wanaruka, i.e. mara moja hufanya kukabiliana na +1. Ikiwa mada sawa inasomwa na Huduma yetu ya Malipo, basi inafanya hivyo na kikundi tofauti, na kwa hivyo malipo hayaingiliani.

Mahitaji ya tukio:

• Ukamilifu wa data. Ningependa tukio liwe na data ya kutosha ili liweze kuchakatwa.

• Uadilifu Tunakabidhi kwa Matukio-basi uthibitishaji kwamba tukio ni thabiti na linaweza kulichakata.
• Utaratibu ni muhimu. Katika kesi ya kurudi, tunalazimika kufanya kazi na historia. Kwa arifa, agizo sio muhimu, ikiwa ni arifa za homogeneous, barua pepe itakuwa sawa bila kujali ni agizo gani lililofika kwanza. Katika kesi ya kurejesha pesa, kuna mchakato wazi; ikiwa tutabadilisha agizo, isipokuwa kutatokea, marejesho hayataundwa au kuchakatwa - tutaishia katika hali tofauti.
• Uthabiti. Tuna duka, na sasa tunaunda matukio badala ya API. Tunahitaji njia ya kusambaza taarifa kwa haraka na kwa bei nafuu kuhusu matukio mapya na mabadiliko kwa yaliyopo kwenye huduma zetu. Hii inafanikiwa kupitia uainishaji wa kawaida katika hazina tofauti ya git na jenereta za nambari. Kwa hiyo, wateja na seva katika huduma tofauti huratibiwa.

Kafka huko Lamoda

Tunayo mitambo mitatu ya Kafka:

1. Kumbukumbu;
2. R&D;
3. Matukio-basi.

Leo tunazungumza tu juu ya hatua ya mwisho. Katika matukio-basi, hatuna mitambo kubwa sana - mawakala 3 (seva) na mada 27 tu. Kama sheria, mada moja ni mchakato mmoja. Lakini hii ni hatua ya hila, na tutaigusa sasa.

Hapo juu ni grafu ya rps. Mchakato wa kurejesha pesa umewekwa alama ya laini ya turquoise (ndiyo, iliyo kwenye mhimili wa X), na laini ya waridi ni mchakato wa kusasisha maudhui.

Katalogi ya Lamoda ina mamilioni ya bidhaa, na data inasasishwa kila wakati. Baadhi ya makusanyo yanatoka kwa mtindo, mpya hutolewa ili kuchukua nafasi yao, na aina mpya zinaonekana mara kwa mara kwenye orodha. Tunajaribu kutabiri kile kitakachowavutia wateja wetu kesho, kwa hivyo tunanunua vitu vipya kila wakati, kuvipiga picha na kusasisha kipochi cha kuonyesha.

Vilele vya pink ni sasisho za bidhaa, yaani, mabadiliko katika bidhaa. Inaweza kuonekana kuwa wavulana walichukua picha, wakapiga picha, na kisha tena! - imepakia pakiti ya matukio.

Matukio ya matumizi ya matukio ya Lamoda

Tunatumia usanifu uliojengwa kwa shughuli zifuatazo:

• Rudisha ufuatiliaji wa hali: wito wa kuchukua hatua na ufuatiliaji wa hali kutoka kwa mifumo yote inayohusika. Malipo, hali, ufadhili, arifa. Hapa tulijaribu mbinu, tukafanya zana, tukakusanya mende zote, tukaandika nyaraka na kuwaambia wenzetu jinsi ya kutumia.
• Kusasisha kadi za bidhaa: usanidi, meta-data, sifa. Mfumo mmoja unasoma (ambao unaonyesha), na kuandika kadhaa.
• Barua pepe, push na sms: utaratibu umekusanywa, utaratibu umefika, kurudi imekubaliwa, nk, kuna mengi yao.
• Hifadhi, upyaji wa ghala - sasisho la kiasi cha vitu, nambari tu: kuwasili kwenye ghala, kurudi. Ni muhimu kwamba mifumo yote inayohusishwa na kuhifadhi bidhaa ifanye kazi na data ya sasa zaidi. Hivi sasa, mfumo wa kusasisha hisa ni ngumu sana; Kafka itarahisisha.
• Data Uchambuzi (Idara ya R&D), zana za ML, uchanganuzi, takwimu. Tunataka habari iwe wazi - Kafka inafaa kwa hili.

Sasa sehemu ya kuvutia zaidi kuhusu matuta makubwa na uvumbuzi wa kuvutia ambao umetokea kwa muda wa miezi sita iliyopita.

Matatizo ya kubuni

Hebu tuseme tunataka kufanya jambo jipya - kwa mfano, kuhamisha mchakato mzima wa utoaji kwa Kafka. Sasa sehemu ya mchakato inatekelezwa katika Usindikaji wa Kuagiza katika BOB. Kuna mfano wa hali nyuma ya uhamisho wa amri kwa huduma ya utoaji, harakati kwenye ghala la kati, na kadhalika. Kuna monolith nzima, hata mbili, pamoja na rundo la API zinazotolewa kwa utoaji. Wanajua mengi zaidi kuhusu utoaji.

Haya yanaonekana kuwa maeneo yanayofanana, lakini Uchakataji wa Agizo katika BOB na Mfumo wa Usafirishaji una hali tofauti. Kwa mfano, huduma zingine za barua pepe hazitumi hali za kati, lakini zile za mwisho tu: "zinazotolewa" au "zilizopotea". Wengine, kinyume chake, wanaripoti kwa undani sana juu ya usafirishaji wa bidhaa. Kila mtu ana sheria zake za uthibitishaji: kwa baadhi, barua pepe ni halali, ambayo ina maana kuwa itashughulikiwa; kwa wengine sio halali, lakini agizo bado litashughulikiwa kwa sababu kuna nambari ya simu ya mawasiliano, na mtu atasema kuwa agizo kama hilo halitashughulikiwa kabisa.

Mtiririko wa data

Katika kesi ya Kafka, swali la kuandaa mtiririko wa data hutokea. Kazi hii inajumuisha kuchagua mkakati kulingana na vidokezo kadhaa; wacha tupitie zote.

Katika mada moja au tofauti?

Tunayo maelezo ya tukio. Katika BOB tunaandika kwamba agizo kama hilo na kama hilo linahitaji kutolewa, na zinaonyesha: nambari ya agizo, muundo wake, SKU kadhaa na nambari za bar, nk. Bidhaa zikifika kwenye ghala, uwasilishaji utaweza kupokea hali, mihuri ya muda na kila kitu kinachohitajika. Lakini basi tunataka kupokea sasisho kwenye data hii katika BOB. Tuna mchakato wa kinyume wa kupokea data kutoka kwa utoaji. Je, hili ni tukio sawa? Au hii ni kubadilishana tofauti ambayo inastahili mada yake mwenyewe?

Uwezekano mkubwa zaidi, watakuwa sawa sana, na jaribu la kufanya mada moja sio msingi, kwa sababu mada tofauti inamaanisha watumiaji tofauti, usanidi tofauti, kizazi tofauti cha haya yote. Lakini si ukweli.

Sehemu mpya au tukio jipya?

Lakini ikiwa unatumia matukio sawa, basi shida nyingine hutokea. Kwa mfano, si mifumo yote ya utoaji inaweza kuzalisha aina ya DTO ambayo BOB inaweza kuzalisha. Tunawatumia kitambulisho, lakini hawakihifadhi kwa sababu hawakihitaji, na kwa mtazamo wa kuanzisha mchakato wa basi la tukio, sehemu hii inahitajika.

Ikiwa tutaanzisha sheria kwa basi la tukio kwamba sehemu hii inahitajika, basi tunalazimika kuweka sheria za ziada za uthibitishaji katika BOB au katika kidhibiti cha tukio la kuanza. Uthibitishaji huanza kuenea katika huduma - hii sio rahisi sana.

Tatizo jingine ni jaribu la maendeleo ya ziada. Tunaambiwa kwamba kitu kinahitaji kuongezwa kwenye tukio, na labda, ikiwa tunafikiri juu yake, inapaswa kuwa tukio tofauti. Lakini katika mpango wetu, tukio tofauti ni mada tofauti. Mada tofauti ni mchakato mzima ambao nilielezea hapo juu. Msanidi anajaribiwa kuongeza tu sehemu nyingine kwenye schema ya JSON na kuitengeneza upya.

Katika kesi ya kurejesha pesa, tulifika kwenye tukio la matukio katika nusu mwaka. Tulikuwa na tukio moja linaloitwa sasisho la kurejesha pesa, ambalo lilikuwa na aina ya sehemu inayoelezea sasisho hili lilikuwa nini. Kwa sababu hii, tulikuwa na swichi "za ajabu" na wathibitishaji ambao walituambia jinsi ya kuthibitisha tukio hili na aina hii.

Toleo la tukio

Ili kudhibitisha ujumbe katika Kafka unaweza kutumia Avro, lakini ilikuwa ni lazima mara moja kuweka juu yake na kutumia Confluent. Kwa upande wetu, tunapaswa kuwa makini na toleo. Haitawezekana kila wakati kusoma tena ujumbe kutoka kwa kumbukumbu ya kunakili kwa sababu kielelezo "kimeondoka". Kimsingi, inageuka kuunda matoleo ili mfano uendane nyuma: kwa mfano, fanya shamba kwa hiari kwa muda. Ikiwa tofauti ni kubwa sana, tunaanza kuandika katika mada mpya, na kuhamisha wateja wanapomaliza kusoma ya zamani.

Agizo la usomaji lililohakikishwa la sehemu

Mada ndani ya Kafka imegawanywa katika sehemu. Hili si muhimu sana tunapounda huluki na ubadilishanaji, lakini ni muhimu tunapoamua jinsi ya kutumia na kuongeza ukubwa wake.

Katika hali ya kawaida, unaandika mada moja huko Kafka. Kwa chaguo-msingi, kizigeu kimoja kinatumika, na ujumbe wote kwenye mada hii huenda kwake. Na mtumiaji husoma ujumbe huu kwa mfuatano. Wacha tuseme sasa tunahitaji kupanua mfumo ili ujumbe usomeke na watumiaji wawili tofauti. Ikiwa, kwa mfano, unatuma SMS, basi unaweza kumwambia Kafka kufanya kizigeu cha ziada, na Kafka itaanza kugawanya ujumbe katika sehemu mbili - nusu hapa, nusu hapa.

Kafka inawagawaje? Kila ujumbe una mwili (ambamo tunahifadhi JSON) na ufunguo. Unaweza kuambatisha kazi ya heshi kwenye ufunguo huu, ambayo itaamua ni sehemu gani ambayo ujumbe utaingia.

Kwa upande wetu na marejesho, hii ni muhimu, ikiwa tunachukua sehemu mbili, basi kuna nafasi kwamba mtumiaji sambamba atashughulikia tukio la pili kabla ya kwanza na kutakuwa na shida. Chaguo za kukokotoa za heshi huhakikisha kuwa barua pepe zilizo na ufunguo sawa zinaishia katika sehemu sawa.

Matukio dhidi ya amri

Hili ni tatizo jingine ambalo tumekumbana nalo. Tukio ni tukio fulani: tunasema kwamba kitu kilifanyika mahali fulani (kitu_kilichofanyika), kwa mfano, kipengee kilighairiwa au kurejeshewa pesa kulitokea. Ikiwa mtu atasikiliza matukio haya, basi kulingana na "kipengee kimeghairiwa," huluki ya kurejesha itaundwa, na "kurejesha pesa" kutaandikwa mahali fulani katika usanidi.

Lakini kwa kawaida, unapotengeneza matukio, hutaki kuyaandika bure - unategemea ukweli kwamba mtu atasoma. Kuna majaribu makubwa ya kuandika sio kitu_kilichofanyika (kipengee_kilichoghairiwa, kurejeshwa_kurejeshwa), lakini kitu_kinapaswa_kufanywa. Kwa mfano, kipengee kiko tayari kurejeshwa.

Kwa upande mmoja, inapendekeza jinsi tukio litatumika. Kwa upande mwingine, inasikika kidogo kama jina la tukio la kawaida. Mbali na hilo, haiko mbali na hapa kwa amri ya do_something. Lakini huna uhakika kwamba mtu alisoma tukio hili; na ukiisoma, basi unaisoma kwa mafanikio; na ukiisoma kwa mafanikio, basi ulifanya kitu, na kitu hicho kilifanikiwa. Wakati tukio linakuwa do_something, maoni yanakuwa muhimu, na hilo ni tatizo.

Katika kubadilishana asynchronous katika RabbitMQ, unaposoma ujumbe, nenda kwa http, una jibu - angalau kwamba ujumbe ulipokelewa. Unapoandikia Kafka, kuna ujumbe ambao uliiandikia Kafka, lakini hujui lolote kuhusu jinsi ulivyochakatwa.

Kwa hiyo, kwa upande wetu, tulipaswa kuanzisha tukio la majibu na kuweka ufuatiliaji ili ikiwa matukio mengi yalitumwa, baada ya muda fulani na vile vile idadi sawa ya matukio ya majibu inapaswa kufika. Ikiwa hii haifanyiki, basi kuna kitu kinaonekana kuwa kimeenda vibaya. Kwa mfano, ikiwa tulituma tukio la "item_ready_to_refund", tunatarajia kwamba pesa zitarejeshwa, pesa zitarejeshwa kwa mteja, na tukio la "kurejeshewa_pesa" litatumwa kwetu. Lakini hii sio hakika, kwa hivyo ufuatiliaji unahitajika.

Usiku

Kuna shida dhahiri: ikiwa unasoma kutoka kwa mada kwa mpangilio, na una ujumbe mbaya, mtumiaji ataanguka, na hautaenda mbali zaidi. Unahitaji kusimamisha watumiaji wote, fanya kukabiliana zaidi ili kuendelea kusoma.

Tulijua juu yake, tulihesabu juu yake, na bado ilifanyika. Na hii ilitokea kwa sababu tukio lilikuwa halali kutoka kwa mtazamo wa matukio-basi, tukio hilo lilikuwa halali kutoka kwa mtazamo wa kithibitishaji cha maombi, lakini haikuwa halali kutoka kwa mtazamo wa PostgreSQL, kwa sababu katika mfumo wetu mmoja. MySQL iliyo na UNSIGNED INT, na katika mfumo mpya ulioandikwa ulikuwa na PostgreSQL tu na INT. Ukubwa wake ni mdogo kidogo, na Id haikufaa. Symfony alikufa isipokuwa. Sisi, bila shaka, tulipata ubaguzi kwa sababu tuliitegemea, na tungeenda kutekeleza utatuzi huu, lakini kabla ya hapo tulitaka kuongeza kihesabu cha tatizo, kwa kuwa ujumbe ulichakatwa bila mafanikio. Kaunta katika mradi huu pia ziko kwenye hifadhidata, na Symfony tayari imefunga mawasiliano na hifadhidata, na ubaguzi wa pili uliua mchakato mzima bila nafasi ya kufanya kazi.

Huduma ililala kwa muda - kwa bahati nzuri, na Kafka hii sio mbaya sana, kwa sababu ujumbe unabaki. Wakati kazi imerejeshwa, unaweza kumaliza kuzisoma. Ni vizuri.

Kafka ina uwezo wa kuweka kukabiliana kiholela kupitia zana. Lakini kwa kufanya hivyo, unahitaji kuacha watumiaji wote - kwa upande wetu, kuandaa kutolewa tofauti ambayo hakutakuwa na watumiaji, redeployments. Kisha katika Kafka unaweza kubadilisha kukabiliana kwa njia ya zana, na ujumbe utapitia.

Nuance nyingine - logi ya kuiga dhidi ya rdkafka.so - inahusiana na maalum ya mradi wetu. Tunatumia PHP, na katika PHP, kama sheria, maktaba zote huwasiliana na Kafka kupitia hazina ya rdkafka.so, na kisha kuna aina fulani ya kanga. Labda hizi ni shida zetu za kibinafsi, lakini ikawa kwamba kusoma tena kipande cha yale ambayo tayari tumesoma sio rahisi sana. Kwa ujumla, kulikuwa na matatizo ya programu.

Kurudi kwa maalum ya kufanya kazi na partitions, imeandikwa haki katika nyaraka watumiaji >= sehemu za mada. Lakini nilipata habari hii baadaye sana kuliko vile ningependa. Ikiwa unataka kuongeza na kuwa na watumiaji wawili, unahitaji angalau sehemu mbili. Hiyo ni, ikiwa ulikuwa na kizigeu kimoja ambacho ujumbe elfu 20 ulikuwa umejilimbikiza, na ukafanya mpya, idadi ya ujumbe haitasawazishwa hivi karibuni. Kwa hiyo, ili kuwa na watumiaji wawili sambamba, unahitaji kukabiliana na partitions.

Ufuatiliaji

Nadhani jinsi tunavyofuatilia itakuwa wazi zaidi kuna matatizo gani katika mbinu iliyopo.

Kwa mfano, tunahesabu ni bidhaa ngapi kwenye hifadhidata zimebadilisha hali yao hivi karibuni, na, ipasavyo, matukio yanapaswa kutokea kulingana na mabadiliko haya, na tunatuma nambari hii kwa mfumo wetu wa ufuatiliaji. Kisha kutoka kwa Kafka tunapata nambari ya pili, ni matukio ngapi ambayo yalirekodiwa. Kwa wazi, tofauti kati ya nambari hizi mbili inapaswa kuwa sifuri kila wakati.

Kwa kuongeza, unahitaji kufuatilia jinsi mtayarishaji anavyofanya, kama matukio-ujumbe uliopokelewa na basi, na jinsi mtumiaji anavyofanya. Kwa mfano, katika chati zilizo hapa chini, Zana ya Kurejesha Pesa inafanya vizuri, lakini BOB ina matatizo kwa wazi (kilele cha bluu).

Tayari nilitaja bakia ya kikundi cha watumiaji. Kwa kusema, hii ni idadi ya ujumbe ambao haujasomwa. Kwa ujumla, watumiaji wetu hufanya kazi haraka, hivyo lag ni kawaida 0, lakini wakati mwingine kunaweza kuwa na kilele cha muda mfupi. Kafka inaweza kufanya hivi nje ya boksi, lakini unahitaji kuweka muda fulani.

Kuna mradi Pigaambayo itakupa habari zaidi juu ya Kafka. Inatumia tu API ya kikundi cha watumiaji kutoa hali ya jinsi kikundi hiki kinavyofanya. Mbali na Sawa na Imeshindwa, kuna onyo, na unaweza kugundua kuwa watumiaji wako hawawezi kukabiliana na kasi ya uzalishaji - hawana wakati wa kusahihisha yaliyoandikwa. Mfumo ni smart kabisa na rahisi kutumia.

Hivi ndivyo majibu ya API yanaonekana. Hiki hapa ni kikundi bob-live-fifa, partition refund.update.v1, status OK, bakia 0 - mwisho wa mwisho kukabiliana vile na vile.

Ufuatiliaji iliyosasishwa_kwenye SLA (imekwama) Nilishataja. Kwa mfano, bidhaa imebadilika hadi hali ya kuwa iko tayari kurudishwa. Tunaweka Cron, ambayo inasema kwamba ikiwa katika dakika 5 kitu hiki hakijarudi (tunarudisha pesa kupitia mifumo ya malipo haraka sana), basi hakika kuna kitu kilikwenda vibaya, na hii ni kweli kesi ya usaidizi. Kwa hivyo, tunachukua tu Cron, ambayo husoma vitu kama hivyo, na ikiwa ni kubwa kuliko 0, basi hutuma arifu.

Kwa muhtasari, kutumia matukio ni rahisi wakati:

• habari inahitajika na mifumo kadhaa;
• matokeo ya usindikaji sio muhimu;
• kuna matukio machache au matukio madogo.

Inaweza kuonekana kuwa kifungu hicho kina mada maalum - API ya asynchronous kwenye Kafka, lakini kuhusiana nayo ningependa kupendekeza mambo mengi mara moja.
Kwanza, ijayo HighLoad ++ tunahitaji kusubiri hadi Novemba; mwezi wa Aprili kutakuwa na toleo la St. Petersburg, na mwezi wa Juni tutazungumzia kuhusu mizigo ya juu huko Novosibirsk.
Pili, mwandishi wa ripoti hiyo, Sergei Zaika, ni mjumbe wa Kamati ya Programu ya mkutano wetu mpya wa usimamizi wa maarifa. MaarifaConf. Mkutano huo ni wa siku moja, utafanyika Aprili 26, lakini mpango wake ni mkali sana.
Na itakuwa Mei PHP Urusi и RIT++ (pamoja na DevOpsConf) - unaweza pia kupendekeza mada yako hapo, zungumza kuhusu uzoefu wako na ulalamike kuhusu koni zako zilizojazwa.

Chanzo: mapenzi.com