Habr cîhanê diguherîne. Zêdetirî salek e em bloggeriyê dikin. Nêzîkî şeş meh berê me ji niştecihên Khabrovsk re bersivek pir mentiqî wergirt: "Dodo, hûn li her derê dibêjin ku pergala we heye. Ev sîstemeke çawa ye? Û çima zincîra pizzeryayê hewce dike?"
Em rûniştin û fikirîn û me fêm kir ku hûn rast dibêjin. Em hewl didin ku her tiştî bi tiliyên xwe vebêjin, lê ew perçe perçe derdikeve û li tu derê ravekirina tevahî ya pergalê tune. Bi vî rengî rêwîtiyek dirêj a berhevkirina agahiyan, lêgerîna li nivîskaran û nivîsandina rêze gotaran li ser Dodo IS dest pê kir. De em herin!
Pejirandin: Spas ji bo parvekirina nerînên xwe bi me re. Bi saya wî, me di dawiyê de pergalê diyar kir, teknoradarek berhev kir, û di demek nêzîk de dê ravekek mezin a pêvajoyên xwe derxînin holê. Bêyî we em ê 5 salên din jî wisa rûnin.
Rêze gotarên "Dodo IS çi ye?" li ser dibêje:
- Yekdestiya destpêkê li Dodo IS (2011-2015). (Ez teslîm nabim...)
- Rêya Backoffice: bingeh û otobus ji hev cuda. (Tu li vir î)
- Rêya milê xerîdar: rûya li ser bingehê (2016-2017). (Ez teslîm nabim...)
- Dîroka mîkroxizmetên rastîn. (2018-2019). (Ez teslîm nabim...)
- Dîtina yekdest û stabîlkirina mîmariyê qediya. (Ez teslîm nabim...)
Heke hûn dixwazin tiştek din fêr bibin, di şîroveyan de binivîsin.
Nêrîna li ser danasîna kronolojîk ji nivîskar
Ez bi berdewamî ji bo xebatkarên nû li ser mijara "Mîmariya Pergalê" civînekê li dar dixim. Em jê re dibêjin "Intro to Dodo IS Architecture" û ew ji bo pêşdebirên nû beşek ji pêvajoya guheztinê ye. Li ser mîmariya me, li ser taybetmendiyên wê, bi rengekî an yekî din axifîm, min hin nêzîkatiyek dîrokî ji bo vegotinê pêş xist.
Bi kevneşopî, em li pergalek wekî komek pêkhateyan (teknîkî an astek bilindtir), modulên karsaziyê ku bi hevûdu re têkilî daynin da ku bigihîjin hin armancê dinêrin. Û her çend nêrînek wusa ji bo sêwiranê rastdar e, ew bi tevahî ji bo ravekirin û têgihiştinê ne maqûl e. Çend sedem hene:
- Rastî ji ya li ser kaxezê cuda ye. Ne her tişt wekî ku hatî plan kirin bi rê ve diçe. Û em eleqedar dibin ka her tişt bi rastî çawa derketiye û dixebite.
- Pêşkêşkirina domdar a agahdariyê. Di rastiyê de, hûn dikarin bi kronolojîk ji destpêkê heya rewşa heyî biçin.
- Ji hêsan berbi tevlihev. Ne gerdûnî ye, lê di rewşa me de wusa ye. Mîmarî ji nêzîkatiyên sadetir ber bi yên tevlihevtir ve çû. Bi gelemperî, bi tevlihevî, pirsgirêkên leza bicîhkirinê û aramiyê, û her weha bi dehan taybetmendiyên din ên ji navnîşa hewcedariyên ne-fonksîyonel ( li ser berevajîkirina tevliheviya bi daxwazên din re baş hate axaftin).
Di 2011 de, mîmariya Dodo IS bi vî rengî xuya bû:
Di sala 2020-an de, ew hinekî tevlihevtir bû û wiha bû:
Ev pêşveçûn çawa çêbû? Çima beşên cûda yên pergalê hewce ne? Çi biryarên mîmarî hatin girtin û çima? Werin em di vê rêze gotaran de fêr bibin.
Pirsgirêkên yekem ên 2016: çima divê karûbar ji yekdestiyê derkeve?
Gotarên yekem ên di rêzê de dê li ser karûbarên ku yekem bûn ku ji monolîtê veqetiyan. Ji bo ku hûn têxin nav çarçoweyê, ez ê ji we re bibêjim ku di destpêka sala 2016-an de çi pirsgirêkên me di pergalê de hebûn, ku em neçar bûn ku bi veqetandina karûbaran re mijûl bibin.
Databasek MySql ya yekane ku hemî serîlêdanên ku di wê demê de li Dodo IS hebûn tomarên xwe tê de nivîsandin. Encam ev bûn:
- Barkirina giran (bi 85% ji daxwazan têne xwendin).
- Bingeh mezin dibû. Ji ber vê yekê mesref û piştgirî bû pirsgirêk.
- Yek xala têkçûnê. Ger yek serîlêdanek ku li databasê dinivîse ji nişka ve dest pê kir ku bi rengek çalaktir bike, wê hingê serîlêdanên din bandor hîs kirin.
- Bêkêmasî di hilanînê û pirsan de. Bi gelemperî data di hin avahiyek de hate hilanîn ku ji bo hin senaryoyan rehet bû lê ne ji bo yên din. Indeks hin operasyonan lez dikin, lê dikarin yên din hêdî bikin.
- Hin pirsgirêk bi kaş û kopiyên xwendinê yên li databasan hatin çareser kirin (ev ê di gotarek cûda de were nîqaş kirin), lê wan tenê destûr da me ku em wextê bi dest bixin û bi bingehîn pirsgirêk çareser nekir.
Pirsgirêk hebûna yekparêz bi xwe bû. Encam ev bûn:
- Weşanên bêhempa û kêm.
- Zehmetî di pêşkeftina hevkariyê ya hejmareke mezin a mirovan de ye.
- Nekarîna danasîna teknolojiyên nû, çarçove û pirtûkxaneyên nû.
Pirsgirêkên bi bingeh û monolîtê re gelek caran hatine vegotin, mînakî, di çarçoweya qezayên di destpêka 2018 de (, и ), ji ber vê yekê ez ê zêde nesekinim. Bihêle ez tenê bibêjim ku me dixwest dema pêşdebirina karûbaran bêtir nermbûnê bidin. Berî her tiştî, ev eleqedar bû yên ku di tevahiya pergalê de herî barkirî û root bûn - Auth û Tracker.
Rêya Ofîsa Paşe: Bingeh û Otobusa Veqetandî
Chapter Navîgasyon
Scheme of monolith 2016
Li vir blokên sereke yên monolîta Dodo IS ya 2016-an hene, û tenê li jêr veqetandinek karên wan ên sereke hene.
Maseya dravê Delivery. Hesabkirina kuryeyan, dayîna fermanan ji bo kuryeyan.
Navenda Têkilî. Qebûlkirina fermanan bi rêya operator.
Site. Malperên me (dodopizza.ru, dodopizza.co.uk, dodopizza.by, hwd.).
auth. Karûbarê destûrkirin û pejirandinê ji bo paşkêşkêşanê.
tracker. Kitchen order tracker. Karûbar ji bo nîşankirina statûyên amadebûnê dema ku fermanek amade dike.
maseya pere Restaurant. Ferman di xwaringehekê de digirin, navgînên dravê.
Eksport. Ji bo hesabkirinê raporên di 1C de barkirin.
Alerts û fatûreyên. Fermanên deng li metbexê (mînak, "Pîzza nû hat") + çapkirina fatûreyan ji bo kurye.
Rêveberê Shift. Navberên ji bo xebata rêveberê veguheztinê: navnîşa fermanan, nexşeyên hilberandinê, anîna karmendan berbi guhertinan.
Rêveberê Ofîsê. Navberên ji bo xebata franchisees û rêveberan: pêşwaziya karmendan, raporên li ser xebata pizzeria.
Lijneya Restaurant. Nîşandana menuyan li ser TV-yên li pizzeryayan.
Admin. Mîhengên ji bo pizzeriya taybetî: menu, biha, hesab, kodên danasînê, promosyonên, pankartên ji bo malperê, hwd.
Hesabê Kesane ya Karmend. Bernameyên xebata karmendan, agahdariya li ser karmendan.
Lijneya Motivasyona Metbexê. Ekranek veqetandî ya ku li metbexê daleqandî ye û leza çêkerên pizza nîşan dide.
Agahhesînî. Şandina sms û e-nameyê.
FileStorage. Xizmeta xwe ji bo wergirtin û weşandina pelên statîk.
Hewldanên pêşî yên ji bo çareserkirina pirsgirêkan alîkariya me kirin, lê ew tenê navberek demkî bûn. Ew nebûn çareseriyên sîstemê, ji ber vê yekê diyar bû ku divê tiştek bi bingehan were kirin. Mînakî, databasa gelemperî li çend pisporên bêtir dabeş bikin.
Em dest bi rakirina monolîtê dikin: veqetandina Auth û Tracker
Karûbarên sereke yên ku wê hingê ji yên din bêtir ji databasê nivîsandin û xwendin:
- Auth. Karûbarê destûrkirin û pejirandinê ji bo paşkêşkêşanê.
- Tracker. Kitchen order tracker. Karûbar ji bo nîşankirina statûyên amadebûnê dema ku fermanek amade dike.
Auth çi dike?
Auth karûbarek e ku bi navgîniya bikarhêner têkevin nivîsgeha paşîn (li hêla xerîdar ve têketinek serbixwe ya veqetandî heye). Her weha di daxwaznameyê de tê destnîşankirin ku mafên gihîştina rast hene û ev maf ji têketina paşîn ve nehatine guhertin. Amûr bi rêya wê dikevin pizeryayan.
Mînakî, em dixwazin li ser TV-ya ku li salonê daliqandî dîmenek bi rewşa fermanên qedandî vekin. Dûv re em auth.dodopizza.ru vedikin, "Têketin wekî amûrê" hilbijêrin, kodek xuya dike ku dikare di rûpelek taybetî ya li ser komputera rêveberê veguheztinê de têkevin, celebê amûrê (cîhaz) destnîşan dike. TV bixwe dê biçe navbeynkariya xwestî ya pizzeriya xwe û li wir dest pê bike navên xerîdarên ku fermanên wan amade ne nîşan bide.
Bar ji ku derê têne?
Her bikarhênerek backoffice-ya têketî ji bo her daxwazekê diçe databasê, li ser tabloya bikarhêner, bikarhêner ji wir bi pirsek sql derdixe û kontrol dike ka ew gihîştin û mafên pêwîst ji vê rûpelê re hene.
Her yek ji cîhazan tenê bi tabloya cîhazê re heman tiştî dike, rola xwe û gihîştina wê kontrol dike. Hejmarek mezin ji daxwaznameyên ji databasa sereke re dibe sedema barkirin û windakirina çavkaniyên daneya giştî li ser van operasyonan.
Daxistina Auth
Auth xwedan domainek veqetandî ye, ango daneyên li ser bikarhêner, têketin an cîhazan dikevin karûbarê (niha pêşerojê) û li wir dimîne. Ger kesek hewceyê wan be, ew ê ji bo daneyan biçin vê karûbarê.
BÛ. Rêya xebatê di destpêkê de wiha bû:
Ez dixwazim hinekî rave bikim ka ew çawa xebitî:
- Daxwazek ji derve tê piştê (Asp.Net MVC li wir), bi xwe re cookieyek danişînê tîne, ku ji bo wergirtina daneyên danişînê ji Redis(1) tê bikar anîn. Ew an agahdariya di derbarê gihîştinan de vedihewîne, û dûv re gihîştina kontrolker vekirî ye (3,4), an na.
- Heke gihîştin tune, hûn hewce ne ku hûn pêvajoya destûrnameyê derbas bikin. Li vir, ji bo sadebûnê, ew wekî beşek rêyê di heman taybetmendiyê de tê xuyang kirin, her çend ev veguheztinek berbi rûpela têketinê ye. Di rewşek senaryoyek erênî de, em ê danişînek rast dagirtî bistînin û biçin Backoffice Controller.
- Ger dane hene, wê hingê hûn hewce ne ku wê ji bo têkildariya di databasa bikarhêner de kontrol bikin. Gelo rola wî guherî, ma divê niha ew li ser rûpelê neyê hiştin? Di vê rewşê de, piştî wergirtina danişînê (1), hûn hewce ne ku rasterast biçin databasê û bi karanîna qata mentiqê ya pejirandinê (2) gihîştina bikarhêner kontrol bikin. Dûv re, an biçin rûpela têketinê an jî biçin kontrolkerê. Ev pergalek hêsan e, lê ne bi tevahî standard e.
- Ger hemî pêvajo qediyabin, wê hingê em di nav mantiqê de di kontrolker û rêbazan de bêtir derbas dibin.
Daneyên bikarhêner ji hemî daneyên din têne veqetandin, ew di tabloyek endametiya cihêreng de têne hilanîn, fonksiyonên ji qata mantiqa AuthService baş dibe ku bibin rêbazên API. Sînorên domainê bi zelalî têne destnîşan kirin: bikarhêner, rolên wan, daneyên gihîştinê, derxistin û betalkirina gihîştinê. Her tişt dixuye ku ew dikare ji bo karûbarek cûda were veguheztin.
BÛ. Ya ku wan kir ev e:
Ev nêzîkatî çend pirsgirêk hene. Mînakî, gazîkirina rêbazek di hundurê pêvajoyek de ne wekî bangkirina karûbarek derveyî bi riya http ye. Derengbûn, pêbawerî, piştgirî, û zelaliya operasyonê bi tevahî cûda ne. Andrey Morevsky di rapora xwe de bi berfirehî li ser van pirsgirêkan axifî .
Karûbarê erêkirinê û bi wê re karûbarê cîhazê ji bo nivîsgeha paşîn, ango ji bo karûbar û navberên ku di hilberînê de têne bikar anîn, têne bikar anîn. Nasname ji bo karûbarên xerîdar (wekî malperek an serîlêdana mobîl) bêyî karanîna Auth-ê ji hev cihê dibe. Veqetandin bi qasî salek girt, û naha em dîsa li ser vê mijarê dixebitin, pergalê veguhezînin karûbarên nûverastkirinê (bi protokolên standard).
Çima veqetîn ewqas dirêj girt?
Di rê de gelek pirsgirêk hebûn ku me sist kir:
- Me xwest ku daneyên di derbarê bikarhêner, cîhaz û erêkirinê de ji databasên welat veguhezînin yek. Ji bo kirina vê yekê, me neçar bû ku hemî tablo û karanîna ji nasnama int veguhezînin nasnama gerdûnî ya UUId (me vê dawiyê vê kodê ji nû ve xebitand û projeya çavkaniya vekirî ). Veguheztina daneyên bikarhêner (ji ber ku ev agahdariya kesane ye) sînorên wê hene û ji bo hin welatan pêdivî ye ku ew ji hev cuda werin hilanîn. Lê divê nasnameya bikarhênerek gerdûnî hebe.
- Gelek tabloyên di databasê de agahdariya kontrolê li ser bikarhênerê ku operasyon pêk aniye hene. Ji bo vê yekê mekanîzmayek zêde hewce dike ku hevgirtinê misoger bike.
- Piştî afirandina karûbarên API-ê, demek dirêj û gav bi gav veguheztina ber bi pergalek din ve hebû. Diviyabû ku guheztin ji bo bikarhêneran bêkêmasî çêbibin û hewcedariya xebata destan bikin.
Plana qeydkirina amûrekê li pizzeryayê:
Mîmariya gelemperî piştî veqetandina karûbarê Auth û Amûran:
bingotin. Ji bo 2020-an, em li ser guhertoyek nû ya Auth-ê dixebitin, ku li ser bingeha standarda destûrnameya OAuth 2.0-ê ye. Ev standard pir tevlihev e, lê ji bo pêşxistina karûbarek pejirandina dawî-bi-dawî bikêr e. Di gotara "» me Alexey Chernyaev hewl da ku bi qasî ku gengaz be li ser standardê bi hêsanî û zelal biaxivin da ku hûn wextê xwe li xwendina wê xilas bikin.
Tracker çi dike?
Naha li ser ya duyemîn ji karûbarên barkirî. Tracker rolek dualî pêk tîne:
- Ji aliyek ve, peywira wê ev e ku karmendan li metbexê nîşan bide ka çi ferman niha di pêş de ne, çi hilber divê niha werin amadekirin.
- Ji hêla din ve, hemî pêvajoyên di metbexê de dîjîtal bikin.
Dema ku hilberek nû (mînak, pizza) di fermanê de xuya dibe, ew diçe qereqola şopandinê "Rolling". Li vê qereqolê çêkerek pîzayê heye ku kulmek bi mezinahiya hewce hildide û derdixe, piştî ku ew li ser tableta şopandinê nîşan dide ku wî karê xwe qedandiye û bingeha hevîrê ya ku lê hatiye gerandin derbas dike stasyona din - "Dajî" .
Li wir, pizzaçêkerê din serê pîzayê datîne, dûv re li ser tabletê nîşan dide ku wî karê xwe qedandiye û pîzayê dixe firinê (ev jî stasyonek cihê ye ku divê li ser tabletê were nîşankirin). Sîstemek wiha ji destpêkê ve li Dodo û ji destpêka Dodo IS ve hebû. Ew dihêle hûn hemî operasyonan bi tevahî bişopînin û dîjîtal bikin. Wekî din, şopger pêşniyar dike ka meriv çawa hilberek taybetî amade dike, her celeb hilber li gorî nexşeyên hilberîna xwe pêk tîne, dema çêkirina çêtirîn ji bo hilberê hilîne, û hemî operasyonên li ser hilberê dişopîne.
Tiştê ku dîmendera tabletê li stasyona şopandina Raskatka xuya dike ev e.
Bar ji ku derê têne?
Her pîzzeryayek bi qasî pênc tabletan bi şopgerek heye. Di sala 2016-an de zêdetirî 100 pizeryayên me hebûn (û niha ji 600 zêdetir in). Her yek ji tabletan her 10 saniyeyan daxwazek ji paşînê dike û daneyan ji tabloya fermanê (girêdana bi xerîdar û navnîşanê re), berhevoka fermanê (girêdana hilberê û nîşana hejmarê), û tabloya motîvasyonê (ew dişopîne) berhev dike. dema zextê). Dema ku çêkerek pizza li ser hilberek li ser şoperê bitikîne, tomarên di van hemî tabloyan de têne nûve kirin. Tabloya fermanê gelemperî ye; ew di heman demê de gava ku fermanek qebûl dike, nûvekirinên ji beşên din ên pergalê, û gelek xwendin hene, mînakî, li ser TV-yek ku li pizzeryayê daleqandî ye û fermanên amadekirî ji xerîdaran re nîşan dide.
Di serdema tekoşîna bi bargiran de, dema ku her tişt û her kes hate cach kirin û veguheztin kopiyek asynkron a databasê, van operasyonên bi şopger re berdewam kirin ku biçin databasa masterê. Divê li vir dereng nemîne, divê dane nûjen be, ji hevdemkirinê nayê qebûlkirin.
Di heman demê de, nebûna tablo û navnîşên me yên li ser wan nehiştin ku em pirsên taybetî yên ku ji bo karanîna me hatine çêkirin binivîsin. Mînakî, dibe ku ji bo şopgerek bi bandor be ku li ser sifrê fermanên xwe indexek ji bo pizzeria hebe. Em her gav fermanên pizzeriyê ji databasa şopgerê vediqetînin. Di heman demê de, ji bo pejirandina fermanê, ne ew qas girîng e ku ew bikeve kîjan pizzeryayê, ya girîng ew e ku kîjan xerîdar ev ferman çêkiriye. Ev tê vê wateyê ku pêdivî ye ku li ser xerîdar navnîşek hebe. Di heman demê de ne hewce ye ku şopger nasnameya meqbûza çapkirî an promosyonên bonûsê yên ku bi fermanê re têkildar in di tabloya fermanê de hilîne. Xizmeta şopandina me bi vê agahiyê re eleqedar nabe. Di databasek monolîtîk a hevpar de, tablo tenê di navbera hemî bikarhêneran de lihevhatinek be. Ev yek ji pirsgirêkên bingehîn bû.
BÛ. Di destpêkê de mîmarî wiha bû:
Tewra piştî ku di pêvajoyên cihêreng de hate veqetandin, piraniya bingeha kodê ji karûbarên cûda re hevpar ma. Her tiştê li jêr kontrolkeran yekgirtî bû û di yek depo de dijiya. Rêbazên hevpar ên karûbaran, depo, û databasek hevpar a ku tabloyên hevpar vedihewîne hatin bikar anîn.
Daxistina Tracker
Pirsgirêka sereke ya şopînerê ev e ku pêdivî ye ku dane di navbera databasên cihêreng de hevdeng bibin. Ev di heman demê de cûdahiya wê ya sereke ye ji dabeşkirina karûbarê Auth; rêzik û statûya wê dikare biguhezîne û divê di karûbarên cihêreng de were xuyang kirin.
Em fermanan li Checkout Restaurant qebûl dikin (ev karûbarek e), ew di databasê de di statûya "Pêkûpêkirî" de tête hilanîn. Piştî wê, divê ew biçe şopgerê, li wir ew ê çend carên din statûya xwe biguhezîne: ji "Kitchen" berbi "Packed". Di vê rewşê de, dibe ku hin bandorên derve yên ji navbera Cashier an Gerînendeyê Shift bi fermanê re çêbibin. Ez ê di tabloyê de statûyên fermanê bi danasînên wan bidim:
Plana guhartina rewşa fermanê wiha xuya dike:
Statû di navbera pergalên cuda de diguhere. Û li vir şopger ne pergala dawîn e ku tê de dane girtî ne. Me di rewşek weha de ji bo veqetandinê çend nêzîkatiyên gengaz dîtin:
- Em hemî kiryarên fermanê di yek karûbar de kom dikin. Di rewşa me de, ev vebijark ji bo pêvajoykirina fermanê pir karûbar hewce dike. Ger em li wir rawestiyana, em ê bi yekdestdariya duyemîn bi dawî bibûna. Me pirsgirêkan çareser nedikir.
- Pergalek bangek din dike. Vebijarka duyemîn balkêştir e. Lê bi wê re, zincîrên bangan gengaz in (), girêdana pêkhateyan bilindtir e, û birêvebirina wê dijwartir e.
- Em bûyeran organîze dikin, û her karûbar bi van bûyeran bi ya din re diguhezîne. Wekî encamek, vebijarka sêyemîn hate hilbijartin, li gorî ku hemî karûbar dest bi danûstandina bûyeran bi hev re dikin.
Rastiya ku me vebijarka sêyem hilbijart tê vê wateyê ku şopkar dê databasa xwe hebe, û ji bo her guhartina rêzê ew ê bûyerek li ser vê yekê bişîne, ku dê karûbarên din jê re bibin abone û ya ku dê di databasa masterê de jî were bicîh kirin. Ji bo vê yekê, me hewceyê hin karûbarek bû ku dê gihandina peyaman di navbera karûbaran de misoger bike.
Wê demê, me berê RabbitMQ di stûyê de hebû, ji ber vê yekê biryara dawîn a ku wê wekî brokerek peyamê bikar bînin. Diagram derbasbûna fermanek ji Kaseya Restoranê bi navgîniya Şopger nîşan dide, li wir ew statûya xwe û pêşandana xwe li ser navbera Fermana Rêvebir diguhezîne. BÛ:
Rêya fermanê gav bi gav
Rêya fermanê li yek ji karûbarên çavkaniya fermanê dest pê dike. Li vir Cashier Restaurantê ye:
- Ferman li Checkout bi tevahî amade ye, û wextê şandina wê ji şopgerê re ye. Bûyera ku şopîner tê de ye tê avêtin.
- Şopdar, fermanek qebûl dike, wê di databasa xwe de hilîne, bûyera "Ferman ji hêla Tracker ve hatî pejirandin" çêdike û wê ji RMQ re dişîne.
- Gelek gerînendetkar berê xwe didin otobusa bûyera xwerû. Ji bo me, ya ku bi databasa monolîtîk re hevdeng dike girîng e.
- Desthilatdar bûyerê distîne, ji wê daneya ku ji bo wê girîng e hildibijêre: di rewşa me de, ev statûya fermanê "Ji hêla Tracker ve hatî pejirandin" e û sazûmana xwe ya fermanê di databasa bingehîn de nûve dike.
Ger kesek hewceyê fermanek taybetî ji tabloya fermanên yekparêz be, wê hingê ew dikare ji wir jî bixwîne. Mînakî, tiştê ku pêwendiya Fermanan di Gerînendeyê Shift de hewce dike ev e:
Hemî karûbarên din jî dikarin bibin abone da ku bûyeran ji şopgerê ferman bikin da ku wan ji bo xwe bikar bînin.
Ger piştî demekê fermanek were hilberandin, statûya wê pêşî di databasa wê de (danûstandina Tracker) diguhere, û dûv re bûyera "OrderInWork" tavilê tê çêkirin. Di heman demê de ew dikeve nav RMQ-ê, ji ku derê ew di databasek monolîtîk de tête hevdem kirin û radestî karûbarên din tê kirin. Di vê rêyê de dibe ku pirsgirêkên cûda hebin; hûrguliyên bêtir li ser wan dikarin di rapora Zhenya Peshkov de werin dîtin .
Mîmariya dawîn piştî guhertinên di Auth û Tracker de
Bi kurtasî: Di destpêkê de, fikra min hebû ku ez dîroka neh-salî ya pergala Dodo IS li yek gotarek pak bikim. Min xwest ez bi lez û bez behsa qonaxên peşveçûnê bikim. Lêbelê, ku ez rûniştim ku materyalê lêkolîn bikim, min fêm kir ku her tişt ji ya ku xuya dike pir tevlihevtir û balkêştir e.
Li ser feydeyên (an kêmbûna wê) materyalek weha, ez gihîştim wê encamê ku pêşkeftina domdar bêyî kronîkên tam ên bûyeran, paşverûyên hûrgulî û analîzkirina biryarên berê ne gengaz e.
Ez hêvî dikim ku we ew kêrhatî û balkêş dît ku li ser rêwîtiya me fêr bibin. Naha ez bi vebijarkek re rû bi rû me ku kîjan beşek ji pergala Dodo IS di gotara pêş de diyar bikim: di şîroveyan de binivîsim an deng bidim.
Tenê bikarhênerên qeydkirî dikarin beşdarî anketê bibin. ji kerema xwe.
Hûn dixwazin di gotara pêş de li ser kîjan beşê Dodo IS fêr bibin?
-
24,1%Yekdestiya destpêkê li Dodo IS (2011-2015)14
-
24,1%Pirsgirêkên yekem û çareseriyên wan (2015-2016)14
-
20,7%Rêya beşa xerîdar: rûya li jorê bingehê (2016-2017)12
-
36,2%Dîroka mîkroxizmetên rastîn (2018-2019)21
-
44,8%Qirkirina yekdestdar û stabîlkirina mîmariyê qediya26
-
29,3%Derbarê planên din ên ji bo pêşdebirina pergalê17
-
19,0%Ez naxwazim di derbarê Dodo IS11 de tiştek bizanim
58 bikarhêneran deng dan. 6 bikarhêner jî betal bûn.
Source: www.habr.com