Tangu 2019, Urusi imekuwa na sheria juu ya uwekaji lebo ya lazima. Sheria haitumiki kwa vikundi vyote vya bidhaa, na tarehe za kuanza kwa uwekaji lebo ya lazima kwa vikundi vya bidhaa ni tofauti. Tumbaku, viatu na dawa zitakuwa za kwanza kuwekewa lebo za lazima; bidhaa zingine zitaongezwa baadaye, kwa mfano, manukato, nguo na maziwa. Ubunifu huu wa kisheria ulichochea ukuzaji wa suluhisho mpya za IT ambazo zitafanya iwezekane kufuatilia mlolongo mzima wa maisha wa bidhaa kutoka kwa uzalishaji hadi ununuzi na watumiaji wa mwisho, kwa washiriki wote katika mchakato huo: serikali yenyewe na mashirika yote yanayouza bidhaa. kuweka lebo kwa lazima.
Katika X5, mfumo ambao utafuatilia bidhaa zilizo na lebo na kubadilishana data na serikali na wasambazaji unaitwa "Marcus". Hebu tuambie kwa mpangilio jinsi na nani aliitengeneza, mrundikano wake wa teknolojia ni nini, na kwa nini tuna kitu cha kujivunia.
Mzigo Halisi
"Marcus" hutatua matatizo mengi, kuu ni mwingiliano wa ushirikiano kati ya mifumo ya habari ya X5 na mfumo wa habari wa serikali wa bidhaa zilizo na lebo (MP wa GIS) kufuatilia harakati za bidhaa zilizo na lebo. Mfumo huo pia huhifadhi misimbo yote ya uwekaji lebo tuliyopokea na historia nzima ya uhamishaji wa misimbo hii kwenye vitu, na husaidia kuondoa uwekaji daraja upya wa bidhaa zilizo na lebo. Kwa kutumia mfano wa bidhaa za tumbaku, ambazo zilijumuishwa katika vikundi vya kwanza vya bidhaa zilizo na lebo, lori moja tu la sigara lina pakiti 600, ambazo kila moja ina nambari zake za kipekee. Na kazi ya mfumo wetu ni kufuatilia na kuthibitisha uhalali wa mienendo ya kila pakiti kama hiyo kati ya ghala na maduka, na hatimaye kuthibitisha kuruhusiwa kwa mauzo yao kwa mnunuzi wa mwisho. Na tunarekodi takriban miamala 000 ya pesa taslimu kwa saa, na pia tunahitaji kurekodi jinsi kila kifurushi kama hicho kiliingia dukani. Kwa hivyo, kwa kuzingatia harakati zote kati ya vitu, tunatarajia makumi ya mabilioni ya rekodi kwa mwaka.
Timu ya M
Licha ya ukweli kwamba Marcus inachukuliwa kuwa mradi ndani ya X5, inatekelezwa kwa kutumia mbinu ya bidhaa. Timu inafanya kazi kulingana na Scrum. Mradi huo ulianza msimu wa joto uliopita, lakini matokeo ya kwanza yalikuja tu mnamo Oktoba - timu yetu wenyewe ilikusanyika kikamilifu, usanifu wa mfumo ulitengenezwa na vifaa vilinunuliwa. Sasa timu ina watu 16, sita kati yao wanahusika katika maendeleo ya nyuma na ya mbele, watatu kati yao wanahusika katika uchambuzi wa mfumo. Watu sita zaidi wanahusika katika kufanya majaribio ya kiotomatiki, ya upakiaji, ya kiotomatiki na ya mwongozo. Kwa kuongeza, tuna mtaalamu wa SRE.
Sio tu wasanidi programu huandika msimbo katika timu yetu; karibu watu wote wanajua jinsi ya kupanga na kuandika majaribio ya kiotomatiki, kupakia hati na hati za otomatiki. Tunalipa kipaumbele maalum kwa hili, kwani hata msaada wa bidhaa unahitaji kiwango cha juu cha automatisering. Daima tunajaribu kuwashauri na kuwasaidia wenzetu ambao hawajapanga hapo awali, na kuwapa kazi ndogo ndogo za kufanyia kazi.
Kwa sababu ya janga la coronavirus, tulihamisha timu nzima kwenye kazi ya mbali; upatikanaji wa zana zote za usimamizi wa maendeleo, mtiririko wa kazi uliojengwa huko Jira na GitLab ulifanya iwezekane kupita hatua hii kwa urahisi. Miezi iliyotumika kwa mbali ilionyesha kuwa tija ya timu haikuteseka kama matokeo; kwa wengi, faraja kazini iliongezeka, kitu pekee kilikosekana ni mawasiliano ya moja kwa moja.
Mkutano wa timu ya mbali
Mikutano wakati wa kazi ya mbali
Mkusanyiko wa teknolojia ya suluhisho
Hifadhi ya kawaida na zana ya CI/CD ya X5 ni GitLab. Tunaitumia kwa hifadhi ya msimbo, majaribio ya mara kwa mara, na kusambaza seva za majaribio na uzalishaji. Pia tunatumia mazoezi ya kukagua msimbo, wakati angalau wenzetu 2 wanahitaji kuidhinisha mabadiliko yaliyofanywa na msanidi programu kwenye msimbo. Vichanganuzi vya misimbo tuli SonarQube na JaCoCo hutusaidia kuweka msimbo wetu safi na kuhakikisha kiwango kinachohitajika cha matumizi ya majaribio ya kitengo. Mabadiliko yote kwenye msimbo lazima yapitie ukaguzi huu. Maandishi yote ya majaribio ambayo yanaendeshwa kwa mikono yanaendeshwa kiotomatiki.
Kwa utekelezaji wa mafanikio wa michakato ya biashara na "Marcus", tulipaswa kutatua matatizo kadhaa ya kiteknolojia, kuhusu kila mmoja kwa utaratibu.
Kazi ya 1. Mahitaji ya usawa wa usawa wa mfumo
Ili kutatua tatizo hili, tulichagua mbinu ya microservice ya usanifu. Wakati huo huo, ilikuwa muhimu sana kuelewa maeneo ya wajibu wa huduma. Tulijaribu kuwagawanya katika shughuli za biashara, kwa kuzingatia maalum ya taratibu. Kwa mfano, kukubalika katika ghala sio kazi ya mara kwa mara, lakini kwa kiasi kikubwa sana, wakati ambapo ni muhimu kupata haraka kutoka kwa mdhibiti wa serikali kuhusu vitengo vya bidhaa zinazokubaliwa, idadi ambayo katika utoaji mmoja hufikia 600000. , angalia kuruhusiwa kwa kukubali bidhaa hii kwenye ghala na urudishe taarifa zote muhimu kwa mfumo wa otomatiki wa ghala. Lakini usafirishaji kutoka kwa ghala una nguvu kubwa zaidi, lakini wakati huo huo hufanya kazi na kiasi kidogo cha data.
Tunatekeleza huduma zote kwa msingi usio na uraia na hata kujaribu kugawanya shughuli za ndani katika hatua, kwa kutumia kile tunachokiita mada za kibinafsi za Kafka. Huu ndio wakati huduma ndogo hutuma ujumbe yenyewe, ambayo hukuruhusu kusawazisha mzigo kwenye shughuli zinazotumia rasilimali nyingi na kurahisisha utunzaji wa bidhaa, lakini zaidi juu ya hilo baadaye.
Tuliamua kutenganisha moduli za mwingiliano na mifumo ya nje katika huduma tofauti. Hii ilifanya iwezekane kusuluhisha tatizo la kubadilisha mara kwa mara API za mifumo ya nje, bila athari yoyote kwa huduma zilizo na utendaji wa biashara.
Huduma zote ndogo huwekwa kwenye kundi la OpenShift, ambalo hutatua tatizo la kuongeza kila huduma ndogo na huturuhusu kutotumia zana za Ugunduzi wa Huduma za wahusika wengine.
Jukumu la 2. Haja ya kudumisha mzigo wa juu na ubadilishanaji wa data wa kina kati ya huduma za jukwaa: Wakati wa awamu ya uzinduzi wa mradi pekee, takriban shughuli 600 kwa sekunde hufanywa. Tunatarajia thamani hii kuongezeka hadi ops 5000/sekunde kwani maduka yanaunganishwa kwenye mfumo wetu.
Tatizo hili lilitatuliwa kwa kupeleka nguzo ya Kafka na karibu kuachana kabisa na mwingiliano kati ya huduma ndogo za jukwaa. Hii inahitaji uchambuzi wa makini sana wa mahitaji ya mfumo, kwani sio shughuli zote zinaweza kuwa za asynchronous. Wakati huo huo, sisi sio tu kusambaza matukio kwa njia ya broker, lakini pia kusambaza taarifa zote za biashara zinazohitajika katika ujumbe. Kwa hivyo, saizi ya ujumbe inaweza kufikia kilobytes mia kadhaa. Kikomo cha ukubwa wa ujumbe katika Kafka kinatuhitaji kutabiri kwa usahihi ukubwa wa ujumbe, na ikiwa ni lazima, tunawagawanya, lakini mgawanyiko ni wa kimantiki, unaohusiana na shughuli za biashara.
Kwa mfano, tunagawanya bidhaa zinazofika kwenye gari kwenye masanduku. Kwa shughuli za synchronous, microservices tofauti zinatengwa na upimaji wa kina wa mzigo unafanywa. Kutumia Kafka kulituletea changamoto nyingine - kujaribu utendakazi wa huduma yetu kwa kuzingatia ujumuishaji wa Kafka hufanya majaribio yetu yote ya kitengo kuwa sawa. Tulitatua tatizo hili kwa kuandika mbinu zetu za matumizi kwa kutumia Embedded Kafka Broker. Hii haiondoi hitaji la kuandika vipimo vya kitengo kwa mbinu za kibinafsi, lakini tunapendelea kujaribu kesi ngumu kwa kutumia Kafka.
Uangalifu mwingi ulilipwa kwa ufuatiliaji wa kumbukumbu ili TraceId yao isipotee wakati isipokuwa kutokea wakati wa utendakazi wa huduma au wakati wa kufanya kazi na kundi la Kafka. Na ikiwa hapakuwa na masuala maalum na ya kwanza, basi katika kesi ya pili tunalazimika kuweka TraceIds zote ambazo kundi lilikuja na kuchagua moja ili kuendelea kufuatilia. Kisha, wakati wa kutafuta kwa TraceId asili, mtumiaji atapata kwa urahisi ni nini ufuatiliaji uliendelea.
Kazi ya 3. Haja ya kuhifadhi kiasi kikubwa cha data: Zaidi ya lebo bilioni 1 kwa mwaka kwa tumbaku pekee huja kwa X5. Wanahitaji ufikiaji wa mara kwa mara na wa haraka. Kwa jumla, mfumo lazima uchakata takriban rekodi bilioni 10 za historia ya usafirishaji wa bidhaa hizi zilizo na lebo.
Ili kutatua tatizo la tatu, hifadhidata ya NoSQL ya MongoDB ilichaguliwa. Tumeunda sehemu ya nodi 5 na kila nodi ina Seti ya Replica ya seva 3. Hii inakuwezesha kuongeza mfumo kwa usawa, na kuongeza seva mpya kwenye nguzo, na kuhakikisha uvumilivu wake wa makosa. Hapa tulikutana na shida nyingine - kuhakikisha shughuli katika nguzo ya mongo, kwa kuzingatia utumiaji wa huduma ndogo za usawa. Kwa mfano, mojawapo ya kazi za mfumo wetu ni kutambua majaribio ya kuuza tena bidhaa zilizo na misimbo sawa ya lebo. Hapa, viwekeleo vinaonekana na skanning zisizo sahihi au utendakazi wenye makosa wa watunza fedha. Tuligundua kuwa nakala kama hizi zinaweza kutokea ndani ya kundi moja la Kafka linalochakatwa, na ndani ya beti mbili zikichakatwa kwa sambamba. Kwa hivyo, kuangalia kwa nakala kwa kuuliza hifadhidata hakutoa chochote. Kwa kila huduma ndogo, tulitatua tatizo tofauti kulingana na mantiki ya biashara ya huduma hii. Kwa mfano, kwa hundi, tuliongeza hundi ndani ya kundi na usindikaji tofauti kwa kuonekana kwa nakala wakati wa kuingiza.
Ili kuhakikisha kuwa kazi ya watumiaji na historia ya utendakazi haiathiri kwa njia yoyote jambo muhimu zaidi - utendakazi wa michakato yetu ya biashara, tumetenganisha data zote za kihistoria kuwa huduma tofauti na hifadhidata tofauti, ambayo pia hupokea habari kupitia Kafka. . Kwa njia hii, watumiaji hufanya kazi na huduma iliyotengwa bila kuathiri huduma zinazochakata data kwa shughuli zinazoendelea.
Kazi ya 4: Uchakataji na ufuatiliaji wa foleni:
Katika mifumo iliyosambazwa, matatizo na makosa hujitokeza katika upatikanaji wa hifadhidata, foleni na vyanzo vya data vya nje. Katika kesi ya Marcus, chanzo cha makosa hayo ni ushirikiano na mifumo ya nje. Ilihitajika kupata suluhisho ambalo lingeruhusu maombi ya mara kwa mara ya majibu yenye makosa na muda uliowekwa maalum, lakini wakati huo huo usiache kusindika maombi yaliyofaulu kwenye foleni kuu. Kwa kusudi hili, dhana inayoitwa "mada kulingana na kujaribu tena" ilichaguliwa. Kwa kila mada kuu, mada moja au zaidi ya kujaribu tena huundwa ambayo ujumbe wenye makosa hutumwa na wakati huo huo ucheleweshaji wa usindikaji wa ujumbe kutoka kwa mada kuu huondolewa. Mpango wa mwingiliano -
Ili kutekeleza mpango huo, tulihitaji yafuatayo: kuunganisha suluhisho hili na Spring na kuepuka kurudia kanuni. Wakati wa kuvinjari wavuti, tuligundua suluhisho kama hilo kulingana na Spring BeanPostProccessor, lakini ilionekana kuwa ngumu kwetu. Timu yetu imefanya suluhisho rahisi zaidi linaloturuhusu kujumuika katika kipindi cha Majira ya kuchipua ili kuunda watumiaji na kuongeza Jaribu tena Wateja. Tulitoa mfano wa suluhisho letu kwa timu ya Spring, unaweza kuiona . Idadi ya Wateja wa Jaribu tena na idadi ya majaribio kwa kila mtumiaji husanidiwa kupitia vigezo, kulingana na mahitaji ya mchakato wa biashara, na ili kila kitu kifanye kazi, kilichobaki ni kuongeza maelezo org.springframework.kafka.annotation.KafkaListener , ambayo inajulikana kwa watengenezaji wote wa Spring.
Ikiwa ujumbe haukuweza kuchakatwa baada ya majaribio yote ya kujaribu tena, huenda kwa DLT (mada ya herufi mfu) kwa kutumia Spring DeadLetterPublishingRecoverer. Kwa ombi la usaidizi, tulipanua utendakazi huu na kuunda huduma tofauti inayokuruhusu kuona ujumbe uliojumuishwa katika DLT, stackTrace, traceId na taarifa nyingine muhimu kuzihusu. Kwa kuongeza, ufuatiliaji na tahadhari ziliongezwa kwa mada zote za DLT, na sasa, kwa kweli, kuonekana kwa ujumbe katika mada ya DLT ni sababu ya kuchambua na kurekebisha kasoro. Hii ni rahisi sana - kwa jina la mada, tunaelewa mara moja kwa hatua gani ya mchakato tatizo lililotokea, ambalo linaharakisha kwa kiasi kikubwa utafutaji wa sababu yake ya mizizi.
Hivi majuzi, tumetumia kiolesura ambacho kinaturuhusu kutuma tena ujumbe kwa kutumia usaidizi wetu baada ya kuondoa sababu zao (kwa mfano, kurejesha utendaji wa mfumo wa nje) na, bila shaka, kuanzisha kasoro sambamba kwa uchambuzi. Hapa ndipo mada zetu za kibinafsi zinafaa: ili usianzishe tena mlolongo mrefu wa usindikaji, unaweza kuianzisha tena kutoka kwa hatua unayotaka.
Uendeshaji wa Jukwaa
Jukwaa tayari linafanya kazi kwa tija, kila siku tunafanya usafirishaji na usafirishaji, kuunganisha vituo vipya vya usambazaji na duka. Kama sehemu ya majaribio, mfumo hufanya kazi na vikundi vya bidhaa za "Tumbaku" na "Viatu".
Timu yetu nzima inashiriki katika kuendesha majaribio, kuchanganua matatizo yanayojitokeza na kutoa mapendekezo ya kuboresha bidhaa zetu, kuanzia kuboresha kumbukumbu hadi kubadilisha michakato.
Ili kutorudia makosa yetu, kesi zote zinazopatikana wakati wa majaribio zinaonyeshwa katika vipimo vya kiotomatiki. Uwepo wa idadi kubwa ya majaribio ya kiotomatiki na vipimo vya kitengo hukuruhusu kufanya majaribio ya urekebishaji na kusakinisha hotfix halisi ndani ya masaa machache.
Sasa tunaendelea kukuza na kuboresha jukwaa letu, na kila mara tunakabiliwa na changamoto mpya. Ikiwa una nia, tutazungumzia kuhusu ufumbuzi wetu katika makala zifuatazo.
Chanzo: mapenzi.com