Sisi sote tunapenda hadithi. Tunapenda kuketi karibu na moto na kuzungumza juu ya ushindi wetu wa zamani, vita, au uzoefu wetu wa kazi tu.
Leo ni siku kama hiyo. Na hata kama hauko motoni hivi sasa, tuna hadithi kwako. Hadithi ya jinsi tulivyoanza kufanya kazi na uhifadhi kwenye Tarantool.
Hapo zamani, kampuni yetu ilikuwa na "monoliths" kadhaa na "dari" moja kwa wote, ambayo monoliths hizi zilikaribia polepole lakini kwa hakika, zikizuia kukimbia kwa kampuni yetu, maendeleo yetu. Na kulikuwa na ufahamu wazi: siku moja tutapiga dari hii kwa bidii.
Sasa ni itikadi iliyopo ya kutenganisha kila kitu na kila mtu, kuanzia vifaa hadi mantiki ya biashara. Matokeo yake, sisi, kwa mfano, tuna DC mbili ambazo zinajitegemea kivitendo katika ngazi ya mtandao. Na kisha kila kitu kilikuwa tofauti kabisa.
Leo, kuna zana na zana nyingi za kufanya mabadiliko katika mfumo wa CI/CD, K8S, nk. Katika wakati wa "monolithic", hatukuhitaji maneno mengi ya kigeni. Ilitosha kusahihisha tu "hifadhi" kwenye hifadhidata.
Lakini wakati ulisonga mbele, na idadi ya maombi ilisonga mbele pamoja nayo, wakati mwingine ikipiga RPS zaidi ya uwezo wetu. Pamoja na kuingia kwa nchi za CIS kwenye soko, mzigo kwenye processor ya database ya monolith ya kwanza haukuanguka chini ya 90%, na RPS ilibakia katika kiwango cha 2400. Na hawa hawakuwa wachaguzi wadogo tu, lakini maswali makubwa na rundo la hundi na JOIN ambazo zinaweza kutumia karibu nusu ya data dhidi ya usuli wa IO kubwa.
Wakati mauzo kamili ya Ijumaa Nyeusi yalipoanza kuonekana kwenye eneo la tukio - na Wildberries alikuwa mmoja wa wa kwanza kuwashikilia nchini Urusi - hali ikawa ya kusikitisha kabisa. Baada ya yote, mzigo kwa siku kama hizo huongezeka mara tatu.
Lo, hizi "nyakati za monolithic"! Nina hakika kuwa umepitia kitu kama hicho, na bado huwezi kuelewa jinsi hii inaweza kutokea kwako.
Unaweza kufanya nini - mtindo ni asili katika teknolojia. Karibu miaka 5 iliyopita, tulipaswa kufikiria upya mojawapo ya mods hizi kwa namna ya tovuti iliyopo kwenye seva ya NET na MS SQL, ambayo ilihifadhi kwa uangalifu mantiki yote ya tovuti yenyewe. Niliiweka kwa uangalifu sana hivi kwamba kuona monolith kama hiyo iligeuka kuwa raha ndefu na sio rahisi kabisa.
Kicheko kidogo.
Katika hafla mbalimbali ninasema: "ikiwa haukuona monolith, basi haukua!" Ninavutiwa na maoni yako juu ya suala hili, tafadhali andika kwenye maoni.
Sauti ya Ngurumo
Hebu turudi kwenye "bonfire" yetu. Ili kusambaza mzigo wa utendakazi wa "monolithic", tuliamua kugawa mfumo katika huduma ndogo kulingana na teknolojia huria. Kwa sababu, kwa kiwango cha chini, wao ni nafuu kwa kiwango. Na tulikuwa na uelewa wa 100% kwamba tutalazimika kuongeza (na mengi). Baada ya yote, tayari wakati huo iliwezekana kuingia katika masoko ya nchi jirani, na idadi ya usajili, pamoja na idadi ya maagizo, ilianza kukua kwa nguvu zaidi.
Baada ya kuchambua watahiniwa wa kwanza wa kuondoka kutoka kwa monolith kwenda kwa huduma ndogo, tuligundua kuwa 80% ya maandishi ndani yao yanatoka kwa mifumo ya ofisi ya nyuma, na kusoma kutoka ofisi ya mbele. Kwanza kabisa, hii ilihusu mifumo michache muhimu kwetu - data ya watumiaji na mfumo wa kuhesabu gharama ya mwisho ya bidhaa kulingana na habari kuhusu punguzo la ziada la wateja na kuponi.
Imeingizwa ndani. Sasa inatisha kufikiria, lakini pamoja na mifumo ndogo iliyotajwa hapo juu, katalogi za bidhaa, gari la ununuzi la watumiaji, mfumo wa utafutaji wa bidhaa, mfumo wa kuchuja wa katalogi za bidhaa, na aina mbalimbali za mifumo ya mapendekezo pia iliondolewa kwenye monolith yetu. Kwa uendeshaji wa kila mmoja wao, kuna madarasa tofauti ya mifumo iliyopangwa nyembamba, lakini mara moja kwa wakati wote waliishi katika "nyumba" moja.
Tulipanga mara moja kuhamisha data kuhusu wateja wetu kwa mfumo uliogawanywa. Kuondolewa kwa utendakazi wa kuhesabu gharama ya mwisho ya bidhaa kulihitaji uwezo mzuri wa kusoma, kwa sababu iliunda mzigo mkubwa wa RPS na ilikuwa ngumu zaidi kutekeleza kwa hifadhidata (data nyingi inahusika katika mchakato wa hesabu).
Kama matokeo, tulikuja na mpango ambao unalingana vizuri na Tarantool.
Wakati huo, kwa ajili ya uendeshaji wa microservices, mipango ya kufanya kazi na vituo kadhaa vya data kwenye mashine za virtual na vifaa vilichaguliwa. Kama inavyoonyeshwa kwenye takwimu, chaguo za urudufishaji wa Tarantool zilitumika katika njia za bwana-bwana na mtumwa-bwana.
Usanifu. Chaguo 1. Huduma ya mtumiaji
Kwa wakati huu, kuna shards 24, ambayo kila moja ina matukio 2 (moja kwa kila DC), yote katika hali ya bwana-bwana.
Juu ya hifadhidata kuna programu zinazofikia nakala za hifadhidata. Programu hufanya kazi na Tarantool kupitia maktaba yetu maalum, ambayo hutumia kiolesura cha kiendeshi cha Tarantool Go. Anaona nakala zote na anaweza kufanya kazi na bwana kusoma na kuandika. Kimsingi, hutumia muundo wa kuweka nakala, ambayo huongeza mantiki ya kuchagua nakala, kufanya majaribio tena, kivunja mzunguko na kikomo cha kiwango.
Katika kesi hii, inawezekana kusanidi sera ya uteuzi wa replica katika muktadha wa shards. Kwa mfano, roundrobin.
Usanifu. Chaguo 2. Huduma ya kuhesabu gharama ya mwisho ya bidhaa
Miezi michache iliyopita, maombi mengi ya kuhesabu gharama ya mwisho ya bidhaa yalikwenda kwa huduma mpya, ambayo, kimsingi, inafanya kazi bila hifadhidata, lakini wakati fulani uliopita kila kitu kilishughulikiwa 100% na huduma iliyo na Tarantool chini ya kofia.
Hifadhidata ya huduma ina masters 4 ambamo kilandanishi hukusanya data, na kila moja ya mabwana hawa wa urudufishaji husambaza data kwa nakala za kusoma pekee. Kila bwana ana takriban nakala 15 kama hizo.
Katika mpango wa kwanza au wa pili, ikiwa DC moja haipatikani, programu inaweza kupokea data kwa pili.
Inafaa kumbuka kuwa urudufishaji katika Tarantool unaweza kunyumbulika kabisa na unaweza kusanidiwa wakati wa utekelezaji. Katika mifumo mingine, shida ziliibuka. Kwa mfano, kubadilisha max_wal_senders na max_replication_slots vigezo katika PostgreSQL kunahitaji kuanzisha upya mchawi, ambayo katika baadhi ya matukio inaweza kusababisha kukatwa kwa miunganisho kati ya programu na DBMS.
Tafuta na utapata!
Kwa nini hatukufanya "kama watu wa kawaida", lakini tulichagua njia isiyo ya kawaida? Inategemea kile kinachochukuliwa kuwa kawaida. Watu wengi kwa ujumla hutengeneza nguzo kutoka Mongo na kuisambaza kwenye DC tatu zilizosambazwa kijiografia.
Wakati huo, tayari tulikuwa na miradi miwili ya Redis. Ya kwanza ilikuwa kache, na ya pili ilikuwa hifadhi ya kudumu kwa data isiyo muhimu sana. Ilikuwa ngumu kwake, kwa sehemu kupitia kosa letu. Wakati mwingine kiasi kikubwa kilikuwa kwenye ufunguo, na mara kwa mara tovuti ikawa mbaya. Tulitumia mfumo huu katika toleo la bwana-mtumwa. Na kulikuwa na matukio mengi ambapo kitu kilitokea kwa bwana na replication ilivunjika.
Hiyo ni, Redis ni nzuri kwa kazi zisizo na sheria, sio za serikali. Kimsingi, iliruhusu kusuluhisha shida nyingi, lakini tu ikiwa zilikuwa suluhisho la dhamana-msingi na jozi ya faharisi. Lakini Redis wakati huo alikuwa na huzuni sana na uvumilivu na kurudia. Aidha, kulikuwa na malalamiko kuhusu utendaji kazi.
Tulifikiria kuhusu MySQL na PostgreSQL. Lakini ya kwanza kwa namna fulani haikupatana nasi, na ya pili ni bidhaa ya kisasa yenyewe, na itakuwa haifai kujenga huduma rahisi juu yake.
Tulijaribu RIAK, Cassandra, hata hifadhidata ya grafu. Haya yote ni masuluhisho yasiyofaa ambayo hayakufaa kwa jukumu la zana ya jumla ya kuunda huduma.
Hatimaye tulitulia kwenye Tarantool.
Tuliigeukia wakati ilikuwa katika toleo la 1.6. Tulivutiwa nayo kwa ulinganifu wa thamani-msingi na utendakazi wa hifadhidata ya uhusiano. Kuna faharisi za sekondari, shughuli na nafasi, hizi ni kama meza, lakini sio rahisi, unaweza kuhifadhi nambari tofauti za safu ndani yao. Lakini kipengele cha muuaji cha Tarantool kilikuwa faharisi za pili pamoja na thamani kuu na shughuli.
Jumuiya sikivu inayozungumza Kirusi, iliyo tayari kusaidia katika gumzo, pia ilichangia. Tulitumia hii kikamilifu na tunaishi moja kwa moja kwenye gumzo. Na usisahau kuhusu kuendelea kwa heshima bila makosa na makosa dhahiri. Ikiwa unatazama historia yetu na Tarantool, tulikuwa na maumivu mengi na kushindwa kwa replication, lakini hatukuwahi kupoteza data kutokana na kosa lake!
Utekelezaji ulianza vibaya
Wakati huo, safu yetu kuu ya ukuzaji ilikuwa .NET, ambayo hapakuwa na kiunganishi cha Tarantool. Mara moja tulianza kufanya kitu katika Go. Ilifanya kazi vizuri na Lua pia. Shida kuu wakati huo ilikuwa na utatuzi: katika NET kila kitu ni nzuri na hii, lakini baada ya hapo ilikuwa ngumu kuingia kwenye ulimwengu wa Lua iliyoingia, wakati huna utatuzi isipokuwa magogo. Kwa kuongezea, kwa sababu fulani replication ilianguka mara kwa mara, kwa hivyo ilinibidi kuzama kwenye muundo wa injini ya Tarantool. Gumzo lilisaidia na hii, na kwa kiwango kidogo, hati; wakati mwingine tuliangalia nambari. Wakati huo, nyaraka zilikuwa hivyo-hivyo.
Kwa hiyo, kwa muda wa miezi kadhaa, niliweza kupata kichwa changu na kupata matokeo mazuri kutokana na kufanya kazi na Tarantool. Tulikusanya maendeleo ya marejeleo katika git ambayo yalisaidia katika uundaji wa huduma ndogo ndogo. Kwa mfano, wakati kazi ilipotokea: kuunda microservice nyingine, msanidi aliangalia msimbo wa chanzo wa suluhisho la kumbukumbu kwenye hifadhi, na ilichukua si zaidi ya wiki moja kuunda mpya.
Hizi zilikuwa nyakati maalum. Kwa kawaida, basi unaweza kwenda kwa msimamizi kwenye jedwali linalofuata na kuuliza: "Nipe mashine pepe." Takriban dakika thelathini baadaye gari lilikuwa na wewe. Ulijiunganisha, ukasakinisha kila kitu, na trafiki ilitumwa kwako.
Leo hii haitafanya kazi tena: unahitaji kuongeza ufuatiliaji na kumbukumbu kwenye huduma, kufunika utendakazi na majaribio, kuagiza mashine ya mtandaoni au uwasilishaji kwa Kuber, nk. Kwa ujumla, itakuwa bora kwa njia hii, ingawa itachukua muda mrefu na kuwa na shida zaidi.
Gawanya na utawala. Je, Lua ana shida gani?
Kulikuwa na tatizo kubwa: baadhi ya timu hazikuweza kufanya mabadiliko kwa njia ya kuaminika kwa huduma yenye mantiki nyingi katika Kilua. Hii mara nyingi iliambatana na huduma kutofanya kazi.
Hiyo ni, watengenezaji wanatayarisha aina fulani ya mabadiliko. Tarantool huanza kufanya uhamiaji, lakini replica bado iko na msimbo wa zamani; Baadhi ya DDL au kitu kingine hufika hapo kupitia urudufishaji, na msimbo huanguka tu kwa sababu hauzingatiwi. Kama matokeo, utaratibu wa kusasisha wasimamizi uliwekwa kwenye karatasi ya A4: acha kurudia, sasisha hii, washa urudufishaji, zima hapa, sasisha hapo. Jinamizi!
Kama matokeo, sasa mara nyingi tunajaribu kufanya chochote katika Lua. Tumia tu iproto (itifaki ya binary ya kuingiliana na seva), na ndivyo hivyo. Labda hii ni ukosefu wa ujuzi kati ya watengenezaji, lakini kutoka kwa mtazamo huu mfumo ni ngumu.
Hatufuati hati hii kwa upofu kila wakati. Leo hatuna nyeusi na nyeupe: ama kila kitu kiko katika Lua, au kila kitu kiko kwenye Go. Tayari tunaelewa jinsi tunavyoweza kuzichanganya ili tusije tukapata matatizo ya uhamiaji baadaye.
Tarantool iko wapi sasa?
Tarantool hutumiwa katika huduma kwa kukokotoa gharama ya mwisho ya bidhaa kwa kuzingatia kuponi za punguzo, pia hujulikana kama "Mtangazaji". Kama nilivyosema awali, sasa anastaafu: nafasi yake inachukuliwa na huduma mpya ya katalogi yenye bei zilizokokotwa awali, lakini miezi sita iliyopita mahesabu yote yalifanywa katika Promotizer. Hapo awali, nusu ya mantiki yake iliandikwa kwa Lua. Miaka miwili iliyopita, huduma iligeuzwa kuwa kituo cha kuhifadhi, na mantiki iliandikwa tena katika Go, kwa sababu mechanics ya punguzo ilikuwa imebadilika kidogo na huduma ilikosa utendaji.
Moja ya huduma muhimu zaidi ni wasifu wa mtumiaji. Hiyo ni, watumiaji wote wa Wildberries wamehifadhiwa katika Tarantool, na kuna takriban milioni 50 kati yao.
Kulingana na RPS, Promoter aliwahi kuwa kiongozi, na kufikia maombi elfu 6. Wakati mmoja tulikuwa na nakala 50-60. Sasa kiongozi katika RPS ni wasifu wa mtumiaji, kuhusu elfu 12. Huduma hii hutumia sharding ya desturi, imegawanywa na safu za vitambulisho vya mtumiaji. Huduma hutumikia zaidi ya mashine 20, lakini hii ni nyingi sana; tunapanga kupunguza rasilimali zilizotengwa, kwa sababu uwezo wa mashine 4-5 unatosha.
Huduma ya kipindi ni huduma yetu ya kwanza kwenye vshard na Cartridge. Kuweka vshard na kusasisha Cartridge kulihitaji juhudi fulani kutoka kwetu, lakini mwishowe kila kitu kilifanyika.
Huduma ya kuonyesha mabango tofauti kwenye tovuti na katika programu ya simu ilikuwa moja ya kwanza kutolewa moja kwa moja kwenye Tarantool. Huduma hii inajulikana kwa ukweli kwamba ina umri wa miaka 6-7, bado inafanya kazi na haijawahi kuwashwa tena. Replication-master-master ilitumika. Hakuna kilichowahi kuvunja.
Kuna mfano wa kutumia Tarantool kwa utendaji wa haraka wa marejeleo katika mfumo wa ghala ili kukagua haraka maelezo mara mbili katika visa vingine. Tulijaribu kutumia Redis kwa hili, lakini data katika kumbukumbu ilichukua nafasi zaidi kuliko Tarantool.
Huduma za orodha ya wanaosubiri, usajili wa wateja, hadithi za mtindo kwa sasa na bidhaa zilizoahirishwa pia hufanya kazi na Tarantool. Huduma ya mwisho katika kumbukumbu inachukua karibu 120 GB. Hii ni huduma ya kina zaidi ya hapo juu.
Hitimisho
Shukrani kwa faharasa za upili pamoja na thamani-msingi na shughuli, Tarantool inafaa kwa usanifu wa msingi wa huduma ndogo. Hata hivyo, tulikumbana na matatizo wakati wa kufanya mabadiliko kwa huduma kwa mantiki nyingi katika Lua - huduma mara nyingi ziliacha kufanya kazi. Hatukuweza kushinda hili, na baada ya muda tulifika kwenye mchanganyiko tofauti wa Lua na Go: tunajua wapi kutumia lugha moja na wapi kutumia nyingine.
Nini kingine cha kusoma kwenye mada
- Kuunda programu ya upakiaji wa juu kutoka mwanzo kwa kutumia Tarantool
- Chaguo la kiongozi anayeaminika katika Tarantool Cartridge
- Telegraph channel Tarantool na habari kuhusu bidhaa
- Jadili Tarantool kwenye gumzo la jumuiya
Chanzo: mapenzi.com