Habr anabadilisha ulimwengu. Tumekuwa tukiblogi kwa zaidi ya mwaka mmoja. Takriban miezi sita iliyopita tulipokea maoni ya kimantiki kutoka kwa wakaazi wa Khabrovsk: "Dodo, unasema kila mahali kwamba una mfumo wako mwenyewe. Huu ni mfumo wa aina gani? Na kwa nini mnyororo wa pizzeria unahitaji?"
Tulikaa na kufikiria na kugundua kuwa uko sawa. Tunajaribu kuelezea kila kitu kwa vidole, lakini hutoka kwa vipande vilivyopasuka na hakuna maelezo kamili ya mfumo popote. Hivyo ilianza safari ndefu ya kukusanya taarifa, kutafuta waandishi na kuandika mfululizo wa makala kuhusu Dodo IS. Twende!
Shukrani: Asante kwa kushiriki maoni yako nasi. Shukrani kwake, hatimaye tulielezea mfumo, tukakusanya technoradar, na hivi karibuni tutatoa maelezo makubwa ya taratibu zetu. Bila wewe, tungekuwa tumekaa hivi kwa miaka 5 nyingine.
Mfululizo wa makala "Dodo IS ni nini?" itasema kuhusu:
- Monolith ya mapema huko Dodo IS (2011-2015). (Inaendelea...)
- Njia ya ofisi ya nyuma: besi tofauti na basi. (Uko hapa)
- 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...)
Ikiwa una nia ya kujifunza kitu kingine chochote, andika kwenye maoni.
Maoni juu ya maelezo ya mpangilio kutoka kwa mwandishi
Mara kwa mara mimi hufanya mkutano kwa wafanyikazi wapya juu ya mada "Usanifu wa Mfumo". Tunauita "Utangulizi wa Usanifu wa Dodo IS" na ni sehemu ya mchakato wa kuabiri kwa wasanidi wapya. Kuzungumza kwa namna moja au nyingine kuhusu usanifu wetu, kuhusu vipengele vyake, nilitengeneza mbinu fulani ya kihistoria kwa maelezo.
Kijadi, tunaangalia mfumo kama seti ya vipengele (kiufundi au kiwango cha juu), moduli za biashara zinazoingiliana ili kufikia lengo fulani. Na wakati maoni kama hayo yanafaa kwa muundo, haifai kabisa kwa maelezo na kuelewa. Kuna sababu kadhaa:
- Ukweli ni tofauti na ule ulio kwenye karatasi. Sio kila kitu kinafanyika kama ilivyopangwa. Na tunavutiwa na jinsi kila kitu kiligeuka na kufanya kazi.
- Uwasilishaji thabiti wa habari. Kwa kweli, unaweza kwenda kwa mpangilio kutoka mwanzo hadi hali ya sasa.
- Kutoka rahisi hadi ngumu. Sio ulimwengu wote, lakini kwa upande wetu ni hivyo. Usanifu ulihama kutoka kwa njia rahisi hadi ngumu zaidi. Mara nyingi, kwa njia ya shida, shida za kasi ya utekelezaji na utulivu, pamoja na kadhaa ya mali zingine kutoka kwenye orodha ya mahitaji yasiyo ya kazi ( imezungumza vizuri juu ya ugumu wa kulinganisha na mahitaji mengine).
Mnamo 2011, usanifu wa Dodo IS ulionekana kama hii:
Kufikia 2020, ikawa ngumu zaidi na ikawa kama hii:
Je, mageuzi haya yalitokeaje? Kwa nini sehemu tofauti za mfumo zinahitajika? Ni maamuzi gani ya usanifu yalifanywa na kwa nini? Hebu tujue katika mfululizo huu wa makala.
Matatizo ya kwanza ya 2016: kwa nini huduma zinapaswa kuondoka monolith?
Makala ya kwanza katika mfululizo itakuwa juu ya huduma ambazo zilikuwa za kwanza kujitenga na monolith. Ili kukuweka katika muktadha, nitakuambia ni matatizo gani tuliyokuwa nayo katika mfumo mwanzoni mwa 2016, ambayo tulipaswa kukabiliana na mgawanyiko wa huduma.
Hifadhidata moja ya MySql ambayo programu zote zilizokuwepo wakati huo huko Dodo IS ziliandika rekodi zao. Madhara yalikuwa:
- Mzigo mzito (na 85% ya maombi yakisomwa).
- Msingi ulikuwa unakua. Kwa sababu hii, gharama na usaidizi ukawa suala.
- Hatua moja ya kushindwa. Ikiwa programu moja inaandika kwenye hifadhidata ghafla ilianza kufanya hivyo kwa bidii zaidi, basi programu zingine zilihisi athari.
- Ukosefu wa uhifadhi na maswali. Mara nyingi data ilihifadhiwa katika muundo fulani ambao ulikuwa rahisi kwa hali fulani lakini sio kwa zingine. Fahirisi huharakisha baadhi ya shughuli, lakini zinaweza kupunguza kasi zingine.
- Baadhi ya shida zilitatuliwa na kache zilizotengenezwa kwa haraka na nakala za kusoma kwa hifadhidata (hii itajadiliwa katika nakala tofauti), lakini walituruhusu tu kupata wakati na hawakusuluhisha shida kimsingi.
Tatizo lilikuwa uwepo wa monolith yenyewe. Madhara yalikuwa:
- Matoleo ya kipekee na adimu.
- Ugumu ni katika maendeleo shirikishi ya idadi kubwa ya watu.
- Kutokuwa na uwezo wa kuanzisha teknolojia mpya, mifumo mipya na maktaba.
Matatizo na msingi na monolith yameelezwa mara nyingi, kwa mfano, katika mazingira ya ajali mapema 2018 (, ΠΈ ), kwa hivyo sitakaa sana. Acha niseme tu kwamba tulitaka kutoa urahisi zaidi wakati wa kuunda huduma. Kwanza kabisa, hii ilihusu zile ambazo zilikuwa zimepakiwa zaidi na mizizi katika mfumo mzima - Auth na Tracker.
Njia ya ofisi ya nyuma: besi tofauti na basi
Urambazaji wa Sura
Mpango wa monolith 2016
Hapa kuna vizuizi kuu vya Dodo IS monolith ya 2016, na hapa chini ni mchanganuo wa kazi zao kuu.
Dawati la utoaji wa pesa. Uhasibu kwa wasafirishaji, kutoa maagizo kwa wasafirishaji.
Kituo cha mawasiliano. Kukubali maagizo kupitia opereta.
Site. Tovuti zetu (dodopizza.ru, dodopizza.co.uk, dodopizza.by, nk.).
Auth. Huduma ya uidhinishaji na uthibitishaji kwa ofisi ya nyuma.
Tracker. Kifuatiliaji cha mpangilio wa jikoni. Huduma ya kuashiria hali ya utayari wakati wa kuandaa agizo.
Dawati la pesa la mgahawa. Kupokea maagizo katika mgahawa, miingiliano ya mtunza fedha.
Hamisha. Inapakia ripoti katika 1C za uhasibu.
Arifa na ankara. Amri za sauti jikoni (kwa mfano, "Pizza mpya imefika") + uchapishaji wa ankara za wasafirishaji.
Meneja wa Shift. Maingiliano ya kazi ya meneja wa mabadiliko: orodha ya maagizo, chati za tija, kuleta wafanyikazi kwa zamu.
Meneja wa Ofisi. Maingiliano ya kazi ya franchisees na mameneja: mapokezi ya wafanyakazi, ripoti juu ya kazi ya pizzeria.
Bodi ya mgahawa. Inaonyesha menyu kwenye TV kwenye pizzeria.
Msimamizi. Mipangilio ya pizzeria mahususi: menyu, bei, uhasibu, misimbo ya matangazo, matangazo, mabango ya tovuti, n.k.
Akaunti ya kibinafsi ya mfanyakazi. Ratiba ya kazi ya wafanyikazi, habari kuhusu wafanyikazi.
Bodi ya Motisha ya Jikoni. Skrini tofauti inayoning'inia jikoni na kuonyesha kasi ya waundaji wa pizza.
Mawasiliano. Kutuma sms na barua pepe.
Hifadhi ya Faili. Huduma yako mwenyewe ya kupokea na kutoa faili tuli.
Majaribio ya kwanza ya kutatua matatizo yalitusaidia, lakini yalikuwa ni pumziko la muda tu. Hawakuwa suluhisho la mfumo, kwa hivyo ilikuwa wazi kwamba kitu kinapaswa kufanywa na besi. Kwa mfano, gawanya hifadhidata ya jumla katika zingine kadhaa maalum.
Tunaanza kupakua monolith: kujitenga kwa Auth na Tracker
Huduma kuu ambazo ziliandika na kusoma kutoka kwa hifadhidata zaidi kuliko zingine:
- Auth. Huduma ya uidhinishaji na uthibitishaji kwa ofisi ya nyuma.
- Mfuatiliaji. Kifuatiliaji cha mpangilio wa jikoni. Huduma ya kuashiria hali ya utayari wakati wa kuandaa agizo.
Auth hufanya nini?
Auth ni huduma ambayo watumiaji huingia kwenye ofisi ya nyuma (kuna kuingia kwa kujitegemea kwa upande wa mteja). Pia inarejelewa katika ombi la kuhakikisha kuwa haki sahihi za ufikiaji zipo na kwamba haki hizi hazijabadilika tangu kuingia mara ya mwisho. Vifaa huingiza pizzeria kupitia hiyo.
Kwa mfano, tunataka kufungua maonyesho na hali ya maagizo yaliyokamilishwa kwenye TV kunyongwa kwenye ukumbi. Kisha tunafungua auth.dodopizza.ru, chagua "Ingia kama kifaa", msimbo unaonekana ambao unaweza kuingizwa kwenye ukurasa maalum kwenye kompyuta ya meneja wa mabadiliko, inayoonyesha aina ya kifaa (kifaa). TV yenyewe itaenda kwenye kiolesura unachotaka cha pizzeria yake na kuanza kuonyesha hapo majina ya wateja ambao maagizo yao yapo tayari.
Mizigo inatoka wapi?
Kila mtumiaji aliyeingia katika ofisi ya nyuma huenda kwenye hifadhidata kwa kila ombi, kwa jedwali la mtumiaji, humtoa mtumiaji kutoka hapo kupitia hoja ya sql na kuangalia kama ana ufikiaji na haki zinazohitajika kwa ukurasa huu.
Kila moja ya vifaa hufanya sawa tu na meza ya kifaa, kuangalia jukumu lake na ufikiaji wake. Idadi kubwa ya maombi kwa hifadhidata kuu husababisha upakiaji wake na upotezaji wa rasilimali za hifadhidata za jumla kwenye shughuli hizi.
Inapakua Auth
Auth ina kikoa kilichotengwa, yaani, data kuhusu watumiaji, watu wanaoingia au vifaa huingia kwenye huduma (kwa sasa hivi) na kubaki hapo. Ikiwa mtu anazihitaji, ataenda kwenye huduma hii kwa data.
ILIKUWA. Mtiririko wa kazi hapo awali ulikuwa kama hii:
Ningependa kueleza kidogo jinsi ilivyofanya kazi:
- Ombi la nje linakuja kwa mazingira ya nyuma (Asp.Net MVC hapo), ikileta kidakuzi cha kikao, ambacho hutumika kupata data ya kikao kutoka kwa Redis(1). Inaweza kuwa na habari kuhusu ufikiaji, na kisha ufikiaji wa mtawala umefunguliwa (3,4), au la.
- Ikiwa hakuna ufikiaji, unahitaji kupitia utaratibu wa idhini. Hapa, kwa urahisi, inaonyeshwa kama sehemu ya njia katika sifa sawa, ingawa hii ni mpito kwa ukurasa wa kuingia. Katika kesi ya hali nzuri, tutapokea kipindi kilichojazwa kwa usahihi na kwenda kwa Kidhibiti cha Backoffice.
- Ikiwa kuna data, basi unahitaji kuiangalia kwa umuhimu katika hifadhidata ya mtumiaji. Je, jukumu lake limebadilika, asiruhusiwe kwenye ukurasa sasa? Katika kesi hii, baada ya kupokea kikao (1), unahitaji kwenda moja kwa moja kwenye hifadhidata na uangalie ufikiaji wa mtumiaji kwa kutumia safu ya mantiki ya uthibitishaji (2). Ifuatayo, nenda kwa ukurasa wa kuingia au nenda kwa kidhibiti. Huu ni mfumo rahisi, lakini sio kiwango kabisa.
- Ikiwa taratibu zote zimekamilika, basi tunaruka zaidi katika mantiki katika watawala na mbinu.
Data ya mtumiaji imetenganishwa na data nyingine zote, inahifadhiwa katika jedwali tofauti la wanachama, vitendaji kutoka kwa safu ya mantiki ya AuthService vinaweza kuwa mbinu za API. Mipaka ya kikoa imefafanuliwa kwa uwazi kabisa: watumiaji, majukumu yao, data ya ufikiaji, utoaji na kufutwa kwa ufikiaji. Kila kitu kinaonekana kama kinaweza kuhamishwa hadi kwa huduma tofauti.
UKAWA. Ndivyo walivyofanya:
Mbinu hii ina matatizo kadhaa. Kwa mfano, kupiga simu kwa njia ndani ya mchakato sio sawa na kupiga huduma ya nje kupitia http. Kuchelewa, kuegemea, usaidizi, na uwazi wa operesheni ni tofauti kabisa. Andrey Morevsky alizungumza kwa undani zaidi juu ya shida hizi katika ripoti yake .
Huduma ya uthibitishaji na pamoja nayo huduma ya kifaa hutumiwa kwa ofisi ya nyuma, yaani, kwa huduma na miingiliano inayotumika katika uzalishaji. Uthibitishaji wa huduma za mteja (kama vile tovuti au programu ya simu) hutokea kando bila kutumia Auth. Mgawanyiko ulichukua karibu mwaka, na sasa tunafanya kazi tena juu ya mada hii, kuhamisha mfumo kwa huduma mpya za uthibitishaji (na itifaki za kawaida).
Kwa nini kutengana kulichukua muda mrefu?
Kulikuwa na shida nyingi njiani ambazo zilipunguza kasi yetu:
- Tulitaka kuhamisha data kuhusu watumiaji, vifaa na uthibitishaji kutoka kwa hifadhidata za nchi hadi moja. Ili kufanya hivyo, ilitubidi kuhamisha majedwali na matumizi yote kutoka kwa kitambulisho cha int hadi kitambulisho cha kimataifa cha UUId (hivi majuzi tulirekebisha nambari hii. na mradi wa chanzo huria ) Kuhifadhi data ya mtumiaji (kwa kuwa hii ni taarifa ya kibinafsi) ina vikwazo vyake na kwa baadhi ya nchi ni muhimu kuihifadhi kando. Lakini lazima kuwe na kitambulisho cha kimataifa cha mtumiaji.
- Majedwali mengi katika hifadhidata yana habari ya ukaguzi kuhusu mtumiaji aliyefanya operesheni. Hii ilihitaji utaratibu wa ziada ili kuhakikisha uthabiti.
- Baada ya kuundwa kwa huduma za API, kulikuwa na muda mrefu na wa taratibu wa uhamisho kwenye mfumo mwingine. Swichi ilibidi zifanyike bila mshono kwa watumiaji na zilihitaji kazi ya mikono.
Mpango wa kusajili kifaa kwenye pizzeria:
Usanifu wa jumla baada ya kutenganisha huduma ya Auth na Devices:
Kumbuka. Kwa 2020, tunafanyia kazi toleo jipya la Auth, ambalo linategemea kiwango cha uidhinishaji cha OAuth 2.0. Kiwango hiki ni changamani sana, lakini ni muhimu kwa kutengeneza huduma ya uthibitishaji kutoka mwisho hadi mwisho. Katika makala "Β» sisi Alexey Chernyaev tulijaribu kuzungumza juu ya kiwango kwa urahisi na kwa uwazi iwezekanavyo ili uokoe wakati wa kuisoma.
Tracker hufanya nini?
Sasa kuhusu pili ya huduma zilizopakiwa. Mfuatiliaji hufanya kazi mbili:
- Kwa upande mmoja, kazi yake ni kuonyesha wafanyakazi jikoni ni maagizo gani yanayoendelea sasa, ni bidhaa gani zinahitajika kutayarishwa sasa.
- Kwa upande mwingine, ongeza michakato yote jikoni.
Wakati bidhaa mpya (kwa mfano, pizza) inaonekana kwa utaratibu, huenda kwenye kituo cha kufuatilia "Rolling". Katika kituo hiki kuna mtengenezaji wa pizza ambaye huchukua bun ya saizi inayohitajika na kuikunja, baada ya hapo anaweka alama kwenye kibao cha tracker kwamba amekamilisha kazi yake na kupitisha msingi wa unga kwenye kituo kinachofuata - "Kujaza" .
Huko, mtengenezaji wa pizza anayefuata anaweka juu ya pizza, kisha anaweka alama kwenye kibao kwamba amekamilisha kazi yake na kuweka pizza kwenye tanuri (hii pia ni kituo tofauti ambacho kinahitaji kuwekwa alama kwenye kibao). Mfumo kama huo ulikuwepo tangu mwanzo kabisa huko Dodo na tangu mwanzo wa Dodo IS. Inakuruhusu kufuatilia kikamilifu na kuweka shughuli zote dijitali. Kwa kuongezea, kifuatiliaji kinapendekeza jinsi ya kuandaa bidhaa fulani, kutekeleza kila aina ya bidhaa kulingana na mipango yake ya utengenezaji, kuhifadhi wakati mwafaka wa kupikia bidhaa, na kufuatilia shughuli zote kwenye bidhaa.
Hivi ndivyo skrini ya kompyuta kibao inavyoonekana kwenye kituo cha ufuatiliaji cha Raskatka.
Mizigo inatoka wapi?
Kila pizzeria ina takriban vidonge vitano na tracker. Mnamo 2016 tulikuwa na pizzeria zaidi ya 100 (na sasa kuna zaidi ya 600). Kila moja ya kompyuta kibao hutoa ombi la kurudisha nyuma kila sekunde 10 na kukusanya data kutoka kwa jedwali la kuagiza (kiungo na mteja na anwani), muundo wa mpangilio (kiungo na bidhaa na kiashiria cha idadi), na jedwali la motisha (inafuata. wakati wa kushinikiza). Wakati mtengenezaji wa pizza anabofya kwenye bidhaa kwenye kifuatiliaji, rekodi katika majedwali haya yote husasishwa. Jedwali la agizo ni la jumla; wakati huo huo lina viingilizi wakati wa kukubali agizo, sasisho kutoka kwa sehemu zingine za mfumo, na usomaji mwingi, kwa mfano, kwenye Runinga inayoning'inia kwenye pizzeria na inaonyesha maagizo yaliyotengenezwa tayari kwa wateja.
Katika kipindi cha mapambano na mizigo, wakati kila kitu na kila mtu kilihifadhiwa na kuhamishiwa kwenye replica ya asynchronous ya hifadhidata, shughuli hizi na tracker ziliendelea kwenda kwenye hifadhidata kuu. Hatupaswi kuchelewa hapa, data lazima iwe ya kisasa, nje ya usawazishaji haukubaliki.
Pia, ukosefu wa jedwali zetu wenyewe na faharisi juu yao haukuturuhusu kuandika maswali maalum zaidi yaliyolengwa kwa matumizi yetu. Kwa mfano, inaweza kuwa na manufaa kwa kifuatiliaji kuwa na faharasa ya pizzeria kwenye jedwali lake la maagizo. Kila mara sisi hufuta maagizo ya pizzeria kutoka kwa hifadhidata ya kifuatiliaji. Wakati huo huo, kukubali amri, sio muhimu sana ambayo pizzeria huanguka, ni nini muhimu zaidi ni mteja gani aliyefanya utaratibu huu. Hii inamaanisha kuwa kuna haja ya kuwa na index kwenye mteja. Pia si lazima kwa kifuatiliaji kuhifadhi kitambulisho cha risiti iliyochapishwa au ofa za bonasi zinazohusiana na agizo kwenye jedwali la agizo. Huduma yetu ya kifuatiliaji haipendezwi na habari hii. Katika hifadhidata ya kawaida ya monolithic, meza zinaweza tu kuwa maelewano kati ya watumiaji wote. Hili lilikuwa mojawapo ya matatizo ya awali.
ILIKUWA. Hapo awali, usanifu ulikuwa kama huu:
Hata baada ya kugawanywa katika michakato tofauti, msingi mwingi wa nambari ulibaki kuwa wa kawaida kwa huduma tofauti. Kila kitu kilicho chini ya vidhibiti kiliunganishwa na kiliishi katika hifadhi moja. Njia za kawaida za huduma, hazina, na hifadhidata ya kawaida iliyo na meza za kawaida zilitumiwa.
Inapakua Kifuatiliaji
Shida kuu ya kifuatiliaji ni kwamba data lazima ilandanishwe kati ya hifadhidata tofauti. Hii pia ni tofauti yake kuu kutoka kwa mgawanyiko wa huduma ya Auth; mpangilio na hali yake inaweza kubadilika na inapaswa kuonyeshwa katika huduma mbalimbali.
Tunakubali maagizo katika Malipo ya Mgahawa (hii ni huduma), huhifadhiwa kwenye hifadhidata katika hali ya "Inayokubaliwa". Baada ya hayo, inapaswa kwenda kwa mfuatiliaji, ambapo itabadilisha hali yake mara kadhaa zaidi: kutoka "Jikoni" hadi "Packed". Katika hali hii, baadhi ya athari za nje kutoka kwa Cashier au kiolesura cha Kidhibiti cha Shift kinaweza kutokea kwa utaratibu. Nitatoa hali za agizo na maelezo yao kwenye jedwali:
Mpango wa mabadiliko ya hali ya mpangilio unaonekana kama hii:
Hali hubadilika kati ya mifumo tofauti. Na hapa tracker sio mfumo wa mwisho ambao data imefungwa. Tumeona njia kadhaa zinazowezekana za kujitenga katika kesi kama hii:
- Tunazingatia vitendo vyote vya kuagiza katika huduma moja. Kwa upande wetu, chaguo hili linahitaji huduma nyingi sana ili kusindika agizo. Ikiwa tungeishia hapo, tungeishia na monolith ya pili. Tusingetatua matatizo.
- Mfumo mmoja hufanya wito kwa mwingine. Chaguo la pili ni la kuvutia zaidi. Lakini nayo, minyororo ya simu inawezekana (), uunganisho wa vipengele ni wa juu, na ni vigumu zaidi kusimamia.
- Tunapanga matukio, na kila huduma hubadilishana na nyingine kupitia matukio haya. Matokeo yake, chaguo la tatu lilichaguliwa, kulingana na ambayo huduma zote zinaanza kubadilishana matukio na kila mmoja.
Ukweli kwamba tulichagua chaguo la tatu inamaanisha kuwa mfuatiliaji atakuwa na hifadhidata yake mwenyewe, na kwa kila mabadiliko katika mpangilio atatuma tukio kuhusu hili, ambalo huduma zingine zingejiandikisha na ambazo pia zitajumuishwa kwenye hifadhidata kuu. Ili kufanya hivyo, tulihitaji huduma fulani ambayo ingehakikisha uwasilishaji wa ujumbe kati ya huduma.
Kufikia wakati huo, tayari tulikuwa na RabbitMQ kwenye rafu, kwa hivyo uamuzi wa mwisho wa kuitumia kama wakala wa ujumbe. Mchoro unaonyesha mpito wa agizo kutoka kwa Cashier ya Mgahawa kupitia Tracker, ambapo hubadilisha hali yake na onyesho lake kwenye kiolesura cha Maagizo ya Msimamizi. UKAWA:
Agiza njia hatua kwa hatua
Njia ya kuagiza huanza katika moja ya huduma za chanzo cha agizo. Hapa kuna Cashier ya Mgahawa:
- Agizo liko tayari kabisa kwenye Malipo, na ni wakati wa kuituma kwa kifuatiliaji. Tukio ambalo kifuatiliaji kimejisajili hutupwa.
- Mfuatiliaji, akikubali agizo, huihifadhi katika hifadhidata yake, na kufanya tukio la "Agizo Linakubaliwa na Mfuatiliaji" na kuituma kwa RMQ.
- Washughulikiaji kadhaa tayari wamejiandikisha kwa basi maalum la hafla. Kwa sisi, moja ambayo inalinganisha na hifadhidata ya monolithic ni muhimu.
- Mshughulikiaji hupokea tukio, huchagua kutoka kwake data ambayo ni muhimu kwake: kwa upande wetu, hii ndiyo hali ya utaratibu "Imekubaliwa na Tracker" na inasasisha chombo chake cha utaratibu katika hifadhidata kuu.
Ikiwa mtu anahitaji amri hasa kutoka kwa meza ya maagizo ya monolithic, basi anaweza kuisoma kutoka huko pia. Kwa mfano, hivi ndivyo kiolesura cha Maagizo katika Kidhibiti cha Shift kinahitaji:
Huduma zingine zote pia zinaweza kujiandikisha ili kuagiza matukio kutoka kwa kifuatiliaji ili kuzitumia zenyewe.
Ikiwa baada ya muda utaratibu unachukuliwa katika uzalishaji, hali yake ya kwanza inabadilika kwenye hifadhidata yake (database ya Tracker), na kisha tukio la "OrderInWork" linatolewa mara moja. Pia huingia kwenye RMQ, kutoka ambapo inasawazishwa katika hifadhidata ya monolithic na kuwasilishwa kwa huduma zingine. Kunaweza kuwa na shida mbali mbali kwenye njia hii; maelezo zaidi juu yao yanaweza kupatikana katika ripoti ya Zhenya Peshkov .
Usanifu wa mwisho baada ya mabadiliko katika Auth na Tracker
Kwa muhtasari: Hapo awali, nilikuwa na wazo la kuweka historia ya miaka tisa ya mfumo wa Dodo IS kuwa nakala moja. Nilitaka kuzungumza haraka na kwa urahisi juu ya hatua za mageuzi. Walakini, baada ya kukaa chini kusoma nyenzo, niligundua kuwa kila kitu ni ngumu zaidi na cha kuvutia kuliko inavyoonekana.
Kuzingatia faida (au ukosefu wake) wa nyenzo kama hizo, nilifikia hitimisho kwamba maendeleo endelevu hayawezekani bila historia kamili ya matukio, kumbukumbu za kina na uchambuzi wa maamuzi ya zamani ya mtu.
Natumai umeona ni muhimu na ya kuvutia kujifunza kuhusu safari yetu. Sasa ninakabiliwa na chaguo la ni sehemu gani ya mfumo wa Dodo IS nielezee katika makala inayofuata: andika kwenye maoni au upige kura.
Watumiaji waliojiandikisha pekee ndio wanaweza kushiriki katika utafiti. tafadhali.
Ni sehemu gani ya Dodo IS ungependa kujifunza kuhusu katika makala inayofuata?
-
24,1%Monolith ya mapema huko Dodo IS (2011-2015)14
-
24,1%Matatizo ya kwanza na ufumbuzi wao (2015-2016)14
-
20,7%Njia ya sehemu ya mteja: facade juu ya msingi (2016-2017)12
-
36,2%Historia ya huduma ndogo ndogo (2018-2019)21
-
44,8%Kukata kukamilika kwa monolith na uimarishaji wa usanifu26
-
29,3%Kuhusu mipango zaidi ya maendeleo ya mfumo17
-
19,0%Sitaki kujua chochote kuhusu Dodo IS11
Watumiaji 58 walipiga kura. Watumiaji 6 walijizuia.
Chanzo: mapenzi.com