🥇Historia ya usanifu wa Dodo IS: monolith ya mapema

Au kila kampuni isiyo na furaha yenye monolith haina furaha kwa njia yake mwenyewe.

Ukuzaji wa mfumo wa Dodo IS ulianza mara moja, kama biashara ya Dodo Pizza - mnamo 2011. Ilikuwa kwa msingi wa wazo la ujanibishaji kamili na wa jumla wa michakato ya biashara, na wao wenyewe, ambayo hata mwaka 2011 ilizua maswali mengi na mashaka. Lakini kwa miaka 9 sasa tumekuwa tukifuata njia hii - na maendeleo yetu wenyewe, ambayo yalianza na monolith.

Nakala hii ni "jibu" kwa maswali "Kwa nini uandike upya usanifu na kufanya mabadiliko makubwa na ya muda mrefu?" kwa makala iliyopita "Historia ya usanifu wa Dodo IS: njia ya ofisi ya nyuma". Nitaanza na jinsi maendeleo ya Dodo IS ilianza, jinsi usanifu wa awali ulivyoonekana, jinsi moduli mpya zilivyoonekana, na kwa sababu ya matatizo gani mabadiliko makubwa yalipaswa kufanywa.

Mfululizo wa makala "Dodo IS ni nini?" itasema kuhusu:

Monolith ya mapema huko Dodo IS (2011-2015). (Uko hapa)
Njia ya ofisi ya nyuma: besi tofauti na basi.
Njia ya sehemu ya mteja: facade juu ya msingi (2016-2017). (Inaendelea...)
Historia ya microservices halisi. (2018-2019). (Inaendelea...)
Kukata kukamilika kwa monolith na uimarishaji wa usanifu. (Inaendelea...)

Usanifu wa awali

Mnamo 2011, usanifu wa Dodo IS ulionekana kama hii:

Moduli ya kwanza katika usanifu ni kukubalika kwa utaratibu. Mchakato wa biashara ulikuwa kama hii:

mteja anaita pizzeria;
Meneja anachukua simu;
inachukua amri kwa simu;
Wakati huo huo, inaijaza katika interface ya kukubalika kwa utaratibu: habari kuhusu mteja, data juu ya maelezo ya utaratibu, na anwani ya utoaji huzingatiwa.

Kiolesura cha mfumo wa habari kilionekana kitu kama hiki...

Toleo la kwanza kutoka Oktoba 2011:

Imeboreshwa kidogo Januari 2012

Mfumo wa habari Mkahawa wa Utoaji wa Pizza wa Dodo

Nyenzo za kuunda moduli ya kuchukua agizo la kwanza zilikuwa chache. Ilikuwa ni lazima kufanya mengi, haraka na kwa timu ndogo. Timu ndogo ina watengenezaji 2 ambao waliweka msingi wa mfumo mzima wa siku zijazo.

Uamuzi wao wa kwanza uliamua hatima ya baadaye ya safu ya teknolojia:

Nyuma kwenye ASP.NET MVC, lugha ya C#. Watengenezaji walikuwa vitone; rundo hili lilikuwa linafahamika na liliwapendeza.
Mazingira ya mbele kwenye Bootstrap na JQuery: violesura vya watumiaji kulingana na mitindo na hati maalum.
Hifadhidata ya MySQL: hakuna gharama za leseni, ni rahisi kutumia.
Seva kwenye Seva ya Windows, kwa sababu .NET basi inaweza kuwa kwenye Windows pekee (hatutajadili Mono).

Kimwili, haya yote yalionyeshwa kwenye "dawati la mwenyeji."

Usanifu wa maombi ya kukubali agizo

Wakati huo, kila mtu alikuwa tayari anazungumza juu ya huduma ndogo, na SOA ilikuwa imetumika katika miradi mikubwa kwa karibu miaka 5, kwa mfano, WCF ilitolewa mnamo 2006. Lakini basi walichagua suluhisho la kuaminika na kuthibitishwa.

Hii hapa.

Asp.Net MVC ni Razor, ambayo, kwa ombi kutoka kwa fomu au kutoka kwa mteja, hutoa ukurasa wa HTML wenye uwasilishaji kwenye seva. Kwenye mteja, hati za CSS na JS tayari zinaonyesha habari na, ikiwa ni lazima, fanya maombi ya AJAX kupitia JQuery.

Maombi kwenye seva huangukia katika *darasa za Kidhibiti, ambapo mbinu huchakata na kutengeneza ukurasa wa mwisho wa HTML. Vidhibiti hufanya maombi kwa safu ya mantiki inayoitwa *Huduma. Kila moja ya huduma ililingana na sehemu fulani ya biashara:

Kwa mfano, DepartmentStructureService ilitoa taarifa kuhusu pizzeria na idara. Idara ni kikundi cha pizzeria kinachosimamiwa na mkodishwaji mmoja.
ReceivingOrdersService imepokelewa na kukokotoa maudhui ya agizo.
Na SmsService ilituma SMS kwa kupiga huduma za API kwa kutuma SMS.

Huduma zilichakatwa data kutoka kwa hifadhidata na kuhifadhi mantiki ya biashara. Kila huduma ilikuwa na hazina moja au zaidi * zenye jina linalofaa. Tayari zilikuwa na maswali kwa taratibu zilizohifadhiwa kwenye hifadhidata na safu ya ramani. Hifadhi zilikuwa na mantiki ya biashara, haswa nyingi ambazo zilitoa data ya kuripoti. ORM haikutumika, kila mtu alitegemea sql iliyoandikwa kwa mkono.

Pia kulikuwa na safu ya mfano wa kikoa na madarasa ya msaidizi wa jumla, kwa mfano, darasa la Agizo, ambalo lilihifadhi utaratibu. Huko, kwenye safu, kulikuwa na msaidizi wa kubadilisha maandishi ya kuonyesha kulingana na sarafu iliyochaguliwa.

Yote hii inaweza kuwakilishwa na mfano huu:

Njia ya kuagiza

Wacha tuchunguze njia rahisi ya kuunda agizo kama hilo.

Hapo awali tovuti ilikuwa tuli. Kulikuwa na bei juu yake, na juu kulikuwa na nambari ya simu na maandishi "Ikiwa unataka pizza, piga nambari hiyo na uagize." Ili kuagiza, tunahitaji kutekeleza mtiririko rahisi:

Mteja huenda kwenye tovuti tuli na bei, huchagua bidhaa na kupiga simu kwa nambari iliyoorodheshwa kwenye tovuti.
Mteja anataja bidhaa anazotaka kuongeza kwenye agizo.
Anatoa anwani na jina lake.
Opereta anakubali agizo.
Agizo linaonyeshwa kwenye kiolesura cha maagizo kilichokubaliwa.

Yote huanza na onyesho la menyu. Mtumiaji wa opereta aliyeingia anakubali agizo moja tu kwa wakati mmoja. Kwa hiyo, rasimu ya gari inaweza kuhifadhiwa katika kikao chake (kipindi cha mtumiaji kinahifadhiwa kwenye kumbukumbu). Kuna kitu cha Cart kilicho na bidhaa na maelezo ya mteja.

Mteja anataja bidhaa, opereta anabofya + karibu na bidhaa, na ombi hutumwa kwa seva. Taarifa kuhusu bidhaa hutolewa kutoka kwa hifadhidata na taarifa kuhusu bidhaa huongezwa kwenye rukwama.

Kumbuka. Ndio, hapa sio lazima kuvuta bidhaa kutoka kwa hifadhidata, lakini uhamishe kutoka mwisho wa mbele. Lakini kwa uwazi, nilionyesha njia haswa kutoka kwa msingi.

Ifuatayo, ingiza anwani na jina la mteja.

Unapobofya "Unda agizo":

Tunatuma ombi kwa OrderController.SaveOrder().
Tunapata Cart kutoka kwa kikao, kuna bidhaa kwa wingi tunaohitaji.
Tunaongezea Cart na taarifa kuhusu mteja na kuipitisha kwa njia ya AddOrder ya darasa la ReceivingOrderService, ambapo huhifadhiwa kwenye hifadhidata.
Hifadhidata ina majedwali yenye mpangilio, yaliyomo kwenye agizo, mteja, na zote zimeunganishwa.
Kiolesura cha onyesho la mpangilio huenda na kutoa maagizo ya hivi punde na kuyaonyesha.

Moduli mpya

Kupokea agizo lilikuwa muhimu na la lazima. Huwezi kuendesha biashara ya pizza ikiwa huna oda ya kuuza. Kwa hivyo, mfumo ulianza kupata utendaji - kutoka takriban 2012 hadi 2015. Wakati huu, vitalu vingi tofauti vya mfumo vilionekana, ambavyo nitaita moduli, kinyume na dhana ya huduma au bidhaa.

Moduli ni seti ya vitendakazi ambavyo vimeunganishwa na lengo fulani la kawaida la biashara. Zaidi ya hayo, ziko kimwili katika maombi sawa.

Moduli zinaweza kuitwa vizuizi vya mfumo. Kwa mfano, hii ni moduli ya kuripoti, miingiliano ya msimamizi, tracker ya bidhaa za jikoni, idhini. Hizi zote ni miingiliano tofauti ya watumiaji, zingine hata zina mitindo tofauti ya kuona. Zaidi ya hayo, kila kitu kiko ndani ya programu moja, mchakato mmoja unaoendesha.

Kitaalam, moduli ziliundwa kama Eneo (wazo hili hata lilibaki ndani msingi wa asp.net) Kulikuwa na faili tofauti za sehemu ya mbele, mifano, na madarasa yao ya kidhibiti. Kama matokeo, mfumo ulibadilishwa kutoka ...

... kwa hii:

Baadhi ya moduli hutekelezwa na tovuti tofauti (mradi unaoweza kutekelezwa), kwa sababu ya utendakazi tofauti kabisa na kwa sehemu kutokana na maendeleo tofauti, yenye umakini zaidi. Hii:

Site - toleo la kwanza tovuti dodopizza.ru.
Hamisha: inapakua ripoti kutoka kwa Dodo IS za 1C.
Binafsi - akaunti ya kibinafsi ya mfanyakazi. Ilitengenezwa tofauti na ina sehemu yake ya kuingia na muundo tofauti.
fs - mradi wa kukaribisha tuli. Baadaye tuliondoka nayo, tukihamisha yaliyomo tuli hadi CDN ya Akamai.

Vitalu vilivyobaki vilikuwa kwenye programu ya BackOffice.

Ufafanuzi wa majina:

Cashier - Rejesta ya pesa ya mgahawa.
ShiftManager - miingiliano ya jukumu la "Kidhibiti Shift": takwimu za uendeshaji juu ya mauzo ya pizzeria, uwezo wa kuweka bidhaa kwenye orodha ya kuacha, kubadilisha agizo.
OfficeManager - miingiliano ya majukumu ya "Kidhibiti cha Pizzeria" na "Franchisee". Hapa unaweza kupata vipengele vya kusanidi pizzeria, matangazo yake ya bonasi, kupokea na kufanya kazi na wafanyakazi, na ripoti.
Skrini za Umma - violesura vya TV na kompyuta kibao zinazoning'inia kwenye pizzeria. Televisheni zinaonyesha menyu, maelezo ya utangazaji, na hali ya agizo zinapowasilishwa.

Walitumia safu ya huduma ya kawaida, kizuizi cha kawaida cha madarasa ya kikoa cha Dodo.Core, na msingi wa kawaida. Wakati mwingine bado wangeweza kuongozana kupitia vifungu kwa kila mmoja. Kwa kuongeza, tovuti za kibinafsi, kama vile dodopizza.ru au personal.dodopizza.ru, pia zilipata huduma za kawaida.

Wakati moduli mpya zilipoonekana, tulijaribu kutumia tena iwezekanavyo msimbo ulioundwa tayari kwa huduma, taratibu zilizohifadhiwa na meza katika hifadhidata.

Kwa ufahamu bora wa kiwango cha moduli zilizotengenezwa kwenye mfumo, hapa kuna mchoro kutoka 2012 na mipango ya maendeleo:

Kufikia 2015, kila kitu kilikuwa sawa na hata zaidi kilikuwa katika uzalishaji.

Kukubalika kwa agizo kumekua kizuizi tofauti cha Kituo cha Mawasiliano, ambapo agizo linakubaliwa na mwendeshaji.
Skrini za umma zilizo na menyu na habari zimeonekana kwenye pizzeria.
Jikoni ina moduli ambayo hucheza kiotomatiki ujumbe wa sauti "Pizza Mpya" wakati agizo jipya linapowasili, na pia huchapisha ankara kwa mjumbe. Hii hurahisisha sana michakato jikoni na inaruhusu wafanyikazi wasipotoshwe na idadi kubwa ya shughuli rahisi.
Kizuizi cha uwasilishaji kikawa Cashier tofauti ya Uwasilishaji, ambapo agizo lilitolewa kwa mjumbe, ambaye hapo awali alikuwa amechukua zamu yake. Saa zake za kazi zilizingatiwa kwa kukokotoa mshahara wake.

Sambamba, kutoka 2012 hadi 2015, watengenezaji zaidi ya 10 walionekana, pizzerias 35 zilifunguliwa, mfumo huo ulipelekwa Romania na kutayarishwa kwa ufunguzi wa alama huko USA. Watengenezaji hawakuhusika tena katika kazi zote, lakini waligawanywa katika timu. kila mmoja maalumu katika sehemu yake ya mfumo.

Shida

Ikiwa ni pamoja na kwa sababu ya usanifu (lakini si tu).

Machafuko katika msingi

Msingi mmoja ni rahisi. Inawezekana kufikia uthabiti, na kwa gharama ya zana zilizojengwa kwenye hifadhidata za uhusiano. Kufanya kazi nayo ni kawaida na rahisi, haswa ikiwa kuna meza chache na data ndogo.

Lakini zaidi ya miaka 4 ya maendeleo, hifadhidata ilikuwa na meza 600, taratibu 1500 zilizohifadhiwa, nyingi ambazo pia zilikuwa na mantiki. Kwa bahati mbaya, taratibu zilizohifadhiwa hazitoi manufaa mengi wakati wa kufanya kazi na MySQL. Hazijaakibishwa na hifadhidata, na kuhifadhi mantiki ndani yake kunatatiza maendeleo na utatuzi. Kutumia tena msimbo pia ni ngumu.

Jedwali nyingi hazikuwa na faharasa zinazofaa, mahali fulani, kinyume chake, kulikuwa na indexes nyingi, ambazo zilifanya uingizaji kuwa mgumu. Takriban majedwali 20 yalilazimika kurekebishwa—shughuli ya kuunda agizo inaweza kuchukua kama sekunde 3-5.

Data katika majedwali haikuwa kila mara katika fomu ifaayo zaidi. Mahali fulani ilikuwa ni lazima kufanya denormalization. Baadhi ya data iliyopokelewa mara kwa mara ilikuwa katika safu katika muundo wa muundo wa XML, ambao uliongeza muda wa utekelezaji, uliongeza maswali na usanidi tata.

Meza hizo hizo zilishughulikiwa sana maombi tofauti. Jedwali maarufu, kama jedwali lililotajwa hapo juu, ziliathiriwa haswa amri au meza Pizzeria. Zilitumiwa kuonyesha miingiliano ya uendeshaji jikoni na uchanganuzi. Tovuti pia iliwasiliana nao (dopizza.ru), ambapo maombi mengi yanaweza kufika ghafla wakati wowote.

Data haikujumlishwa na mahesabu mengi yalifanyika kwa kuruka kwa kutumia msingi. Hii iliunda mahesabu yasiyo ya lazima na mzigo wa ziada.

Mara nyingi nambari iliingia kwenye hifadhidata wakati haikuweza kufanya hivyo. Mahali fulani kulikuwa na ukosefu wa shughuli nyingi, mahali fulani itakuwa muhimu kugawanya ombi moja katika kadhaa kwa njia ya kanuni ili kuharakisha na kuongeza kuegemea.

Mshikamano na Mkanganyiko katika Kanuni

Moduli ambazo zilipaswa kuwajibika kwa sehemu yao ya biashara hazikufanya kwa uaminifu. Baadhi yao walikuwa na nakala za utendakazi kwa majukumu. Kwa mfano, mfanyabiashara wa ndani ambaye anawajibika kwa shughuli ya uuzaji ya mtandao katika jiji lake alilazimika kutumia kiolesura cha "Msimamizi" (kuweka matangazo) na kiolesura cha "Ofisi ya Meneja" (ili kutazama athari za ofa kwenye biashara). Bila shaka, ndani ya moduli zote mbili zilitumia huduma sawa, ambayo ilifanya kazi na matangazo ya ziada.

Huduma (madarasa ndani ya mradi mmoja mkubwa wa monolithic) zinaweza kupigiana simu ili kuboresha data zao.

Na madarasa ya mfano yenyewe ambayo huhifadhi data, kazi katika kanuni ilifanyika tofauti. Mahali pengine kulikuwa na wajenzi ambao unaweza kutaja sehemu zinazohitajika. Mahali fulani hii ilifanyika kupitia mali ya umma. Kwa kweli, kupata na kubadilisha data kutoka kwa hifadhidata ilikuwa tofauti.

Mantiki ilikuwa ama katika vidhibiti au madarasa ya huduma.

Haya yanaonekana kama matatizo madogo, lakini yalipunguza kasi ya maendeleo na kupunguza ubora, na kusababisha kukosekana kwa utulivu na hitilafu.

Utata wa maendeleo makubwa

Ugumu uliibuka katika maendeleo yenyewe. Ilikuwa ni lazima kuunda vitalu tofauti vya mfumo, na kwa sambamba. Ilizidi kuwa ngumu kutosheleza mahitaji ya kila sehemu katika msimbo mmoja. Haikuwa rahisi kukubaliana na kupendeza vipengele vyote kwa wakati mmoja. Iliyoongezwa kwa hii ilikuwa mapungufu katika teknolojia, haswa kwa kuzingatia msingi na mwisho wa mbele. Ilihitajika kuachana na JQuery kwa niaba ya mifumo ya hali ya juu, haswa katika suala la huduma za mteja (tovuti).

Baadhi ya sehemu za mfumo zinaweza kutumia hifadhidata ambazo zinafaa zaidi kwa hili. Kwa mfano, baadaye tulikuwa na kielelezo cha kubadili kutoka kwa Redis hadi CosmosDB ili kuhifadhi gari la kuagiza.

Timu na wasanidi wanaofanya kazi katika eneo lao kwa wazi walitaka uhuru zaidi kwa huduma zao, katika masuala ya maendeleo na uchapishaji. Migogoro wakati wa kuunganisha, matatizo wakati wa kutolewa. Ikiwa kwa watengenezaji 5 shida hii haina maana, basi na 10, na hata zaidi na ukuaji uliopangwa, kila kitu kitakuwa mbaya zaidi. Na kilichokuja ni maendeleo ya programu ya rununu (ilianza mnamo 2017, na mnamo 2018 kulikuwa na anguko kubwa).

Sehemu tofauti za mfumo zilihitaji viashiria tofauti vya utulivu, lakini kutokana na muunganisho mkubwa wa mfumo, hatukuweza kutoa hili. Hitilafu wakati wa kuunda kazi mpya katika paneli ya msimamizi inaweza kuwa imesababisha kukubalika kwa utaratibu kwenye tovuti, kwa sababu kanuni ni ya kawaida na inaweza kutumika tena, hifadhidata na data pia ni sawa.

Pengine ingewezekana kuepuka makosa na matatizo haya ndani ya mfumo wa usanifu wa kawaida wa monolithic: kuunda mgawanyiko wa majukumu, refactor kanuni na hifadhidata, kutenganisha kwa uwazi tabaka kutoka kwa kila mmoja, na kufuatilia ubora kila siku. Lakini ufumbuzi uliochaguliwa wa usanifu na kuzingatia kwa haraka kupanua utendaji wa mfumo ulisababisha matatizo katika masuala ya utulivu.

Jinsi blogu ya Nguvu ya Akili inavyoweka rejista za pesa kwenye mikahawa

Ikiwa ukuaji wa mtandao wa pizzeria (na mzigo) uliendelea kwa kasi sawa, basi baada ya muda matone yatakuwa kwamba mfumo hautapona. Hadithi ifuatayo inaonyesha vizuri matatizo ambayo tulianza kukabiliana nayo kufikia 2015.

Katika blogi "Nguvu ya akili"kulikuwa na wijeti iliyoonyesha data ya mapato kwa mwaka kwa mtandao mzima. Wijeti ilifikia API ya umma ya Dodo, ambayo hutoa data hii. Takwimu hizi sasa zinapatikana kwenye http://dodopizzastory.com/. Wijeti ilionyeshwa kwenye kila ukurasa na ilituma maombi kwa kipima muda kila sekunde 20. Ombi lilienda kwa api.dodopizza.ru na kuuliza:

idadi ya pizzerias kwenye mtandao;
jumla ya mapato ya mtandao tangu mwanzo wa mwaka;
mapato ya leo.

Ombi la takwimu za mapato lilienda moja kwa moja kwenye hifadhidata na kuanza kuomba data juu ya maagizo, kukusanya data moja kwa moja kwenye nzi na kutoa kiasi hicho.

Rejesta za pesa katika mikahawa zilikwenda kwenye jedwali lile lile la maagizo, zikapakia orodha ya maagizo yaliyokubaliwa kwa leo, na maagizo mapya yaliongezwa kwake. Rejesta za fedha zilifanya maombi yao kila baada ya sekunde 5 au ukurasa ulipoonyeshwa upya.

Mchoro ulionekana kama hii:

Siku moja katika msimu wa joto, Fyodor Ovchinnikov aliandika nakala ndefu na maarufu kwenye blogi yake. Watu wengi walikuja kwenye blogi na wakaanza kusoma kila kitu kwa uangalifu. Wakati kila mmoja wa watu waliokuja alikuwa akisoma makala, wijeti ya mapato ilifanya kazi ipasavyo na kuomba API kila baada ya sekunde 20.

API iliita utaratibu uliohifadhiwa wa kukokotoa kiasi cha maagizo yote tangu mwanzo wa mwaka kwa pizzeria zote kwenye mtandao. Mkusanyiko huo ulitokana na meza ya maagizo, ambayo ni maarufu sana. Rejesta zote za pesa za mikahawa yote wazi wakati huo huenda kwake. Rejesta za pesa ziliacha kujibu na maagizo hayakukubaliwa. Pia hazikukubaliwa kutoka kwa tovuti, hazikuonekana kwenye tracker, na meneja wa mabadiliko hakuweza kuwaona kwenye interface yake.

Hii sio hadithi pekee. Kufikia msimu wa 2015, kila Ijumaa mzigo kwenye mfumo ulikuwa muhimu. Mara kadhaa tulizima API ya umma, na mara moja tulilazimika kuzima tovuti kwa sababu hakuna kitu kilichosaidia. Kulikuwa na hata orodha ya huduma na utaratibu wa kuzima chini ya mizigo nzito.

Kuanzia wakati huu, mapambano yetu na mizigo na kwa uimarishaji wa mfumo huanza (kutoka vuli 2015 hadi vuli 2018). Hapo ndipo ilipotokea"Anguko Kubwa" Zaidi ya hayo, wakati mwingine pia kulikuwa na kushindwa, baadhi ambayo yalikuwa nyeti sana, lakini kipindi cha jumla cha kutokuwa na utulivu sasa kinaweza kuchukuliwa kuwa juu.

Ukuaji wa haraka wa biashara

Kwa nini "haikuweza kufanywa vizuri mara moja"? Angalia tu grafu zifuatazo.

Pia mnamo 2014-2015 kulikuwa na ufunguzi huko Romania na ufunguzi huko USA ulikuwa unatayarishwa.

Mlolongo ulikua haraka sana, nchi mpya zilifunguliwa, aina mpya za pizzeria zilionekana, kwa mfano, pizzeria ilifunguliwa kwenye mahakama ya chakula. Haya yote yalihitaji umakini mkubwa haswa katika kupanua kazi za Dodo IS. Bila kazi hizi zote, bila kufuatilia jikoni, uhasibu wa bidhaa na hasara katika mfumo, kuonyesha utoaji wa maagizo katika ukumbi wa mahakama ya chakula, hakuna uwezekano kwamba sasa tungezungumza juu ya usanifu "sahihi" na "sahihi." ” mbinu ya maendeleo.

Kikwazo kingine kwa marekebisho ya wakati wa usanifu na tahadhari ya jumla kwa matatizo ya kiufundi ilikuwa mgogoro wa 2014. Mambo kama haya yanaumiza fursa za ukuaji wa timu, haswa kwa biashara changa kama Dodo Pizza.

Suluhisho za haraka ambazo zilisaidia

Matatizo yalihitaji ufumbuzi. Kimsingi, suluhisho zinaweza kugawanywa katika vikundi 2:

Zile za haraka zinazozima moto na kutupa kiasi kidogo cha usalama na kutununulia muda wa kubadilika.
Utaratibu na, kwa hiyo, kwa muda mrefu. Kuunda tena moduli kadhaa, kugawa usanifu wa monolithic katika huduma tofauti (nyingi wao sio ndogo, lakini ni huduma kubwa, na kuna zaidi juu ya hii. ripoti ya Andrey Morevsky).

Orodha kavu ya mabadiliko ya haraka ni:

Kuongeza msingi bwana

Bila shaka, jambo la kwanza ambalo linafanyika ili kupambana na mzigo ni kuongeza nguvu ya seva. Hii ilifanyika kwa hifadhidata kuu na seva za wavuti. Ole, hii inawezekana tu hadi kikomo fulani; zaidi ya hapo inakuwa ghali sana.

Tangu 2014, tumehamia Azure; tuliandika pia juu ya mada hii wakati huo katika nakala "Jinsi Dodo Pizza hutoa pizza kwa kutumia wingu la Microsoft Azure" Lakini baada ya kuongezeka kwa safu ya seva, gharama ya msingi ilifikia kikomo.

Nakala za hifadhidata za kusoma

Tulitengeneza nakala mbili za msingi:

SomaReplica kwa maombi ya saraka. Inatumika kusoma saraka, kama vile jiji, barabara, pizzeria, bidhaa (kikoa kilichobadilishwa polepole), na katika miingiliano hiyo ambapo ucheleweshaji mdogo unakubalika. Kulikuwa na nakala 2 kati ya hizi, tulihakikisha upatikanaji wao kwa njia sawa na bwana.

SomaReplica kwa maombi ya ripoti. Hifadhidata hii ilikuwa na upatikanaji wa chini, lakini ripoti zote zilienda kwake. Wanaweza kuwa na maombi mazito ya ukokotoaji mkubwa wa data, lakini hawaathiri hifadhidata kuu na miingiliano ya uendeshaji.

Akiba katika kanuni

Hakukuwa na kache mahali popote kwenye nambari (kabisa). Hii ilisababisha maombi ya ziada, sio lazima kila wakati, kwa hifadhidata iliyopakiwa. Mara ya kwanza, cache zilikuwa kwenye kumbukumbu na kwenye huduma ya kache ya nje, ilikuwa Redis. Kila kitu kilibatilishwa kwa wakati, mipangilio ilibainishwa kwenye nambari.

Seva nyingi za backend

Sehemu ya nyuma ya programu pia ilibidi iongezwe ili kuhimili mizigo iliyoongezeka. Ilihitajika kutengeneza nguzo kutoka kwa seva moja ya IIS. Tulihama kikao cha maombi kutoka kwa kumbukumbu kwenye RedisCache, ambayo ilifanya iwezekanavyo kuunda seva kadhaa nyuma ya usawa rahisi wa mzigo na robin ya pande zote. Mara ya kwanza, Redis hiyo hiyo ilitumiwa kama cache, kisha ikagawanywa katika kadhaa.

Kama matokeo, usanifu umekuwa mgumu zaidi ...

...lakini baadhi ya mvutano huo ulitulia.

Na kisha ilikuwa ni lazima kufanya upya vipengele vilivyobeba, ambavyo ndivyo tulivyochukua. Tutazungumza juu ya hili katika sehemu inayofuata.

Chanzo: mapenzi.com

Historia ya Usanifu wa Dodo NI: Monolith ya Mapema