Habr er að breyta heiminum. Við erum búin að vera að blogga í rúmt ár núna. Fyrir um sex mánuðum fengum við algjörlega rökrétt viðbrögð frá Khabrovites: „Dodo, þú segir alls staðar að þú sért með þitt eigið kerfi. Og hvað er þetta kerfi? Og hvers vegna þarf pizzakeðja það?
Við sátum, hugsuðum og komumst að því að þú hefur rétt fyrir þér. Við reynum að útskýra allt á fingrum okkar, en það kemur út í rifnum bútum og hvergi er til heildarlýsing á kerfinu. Þannig hófst langt ferðalag við að safna upplýsingum, leita að höfundum og skrifa greinaröð um Dodo IS. Förum!
Þakkir: Þakka þér fyrir að deila athugasemdum þínum með okkur. Þökk sé honum, lýstum við loksins kerfinu, tókum saman tæknilega ratsjá og munum fljótlega setja út stóra lýsingu á ferlum okkar. Án þín hefðum við setið þar í 5 ár í viðbót.
Greinaröð "Hvað er Dodo IS?" segir frá:
- Snemma monolith í Dodo IS (2011-2015). (Í vinnslu...)
- Bakstofustígurinn: aðskildar bækistöðvar og strætó. (þú ert hér)
- Slóð viðskiptavinarins: framhlið yfir grunninn (2016-2017). (Í vinnslu...)
- Saga sannrar örþjónustu. (2018-2019). (Í vinnslu...)
- Lokið við sagun á einlitum og stöðugleika arkitektúrsins. (Í vinnslu...)
Ef þú hefur áhuga á að vita eitthvað annað - skrifaðu í athugasemdirnar.
Álit á tímaröð lýsingu frá höfundi
Ég held reglulega fundi fyrir nýja starfsmenn um efnið "Kerfisarkitektúr". Við köllum það „Intro to Dodo IS Architecture“ og það er hluti af inngönguferli nýrra hönnuða. Með því að segja í einni eða annarri mynd frá arkitektúr okkar, frá einkennum hans, hef ég fædd ákveðna sögulega nálgun á lýsinguna.
Hefð er að líta á kerfið sem safn af íhlutum (tæknilegum eða hærra stigi), viðskiptaeiningum sem hafa samskipti sín á milli til að ná einhverju markmiði. Og ef slík skoðun er réttlætanleg fyrir hönnun, þá er það ekki alveg hentugur fyrir lýsingu og skilning. Það eru nokkrar ástæður hér:
- Raunveruleikinn er annar en á blaði. Ekki gengur allt eins og til var ætlast. Og við höfum áhuga á hvernig það reyndist í raun og veru.
- Stöðug framsetning upplýsinga. Reyndar er hægt að fara í tímaröð frá upphafi til núverandi ástands.
- Frá einföldum til flókinna. Ekki almennt, en í okkar tilfelli er það svo. Arkitektúrinn færðist frá einfaldari aðferðum yfir í flóknari. Oft með flækjum voru vandamál varðandi hraða og stöðugleika leyst, svo og tugir annarra eiginleika af listanum yfir óvirkar kröfur ( vel sagt um andstæðu flókið við aðrar kröfur).
Árið 2011 leit Dodo IS arkitektúrinn svona út:
Árið 2020 hefur þetta orðið aðeins flóknara og orðið svona:
Hvernig átti þessi þróun sér stað? Hvers vegna þarf mismunandi hluta kerfisins? Hvaða byggingarákvarðanir voru teknar og hvers vegna? Við skulum komast að því í þessari greinaröð.
Fyrstu vandamál ársins 2016: hvers vegna ætti þjónusta að yfirgefa monolith
Fyrstu greinarnar úr hringrásinni munu fjalla um þá þjónustu sem voru fyrstur til að aðskilja sig frá einliðanum. Til að setja þig í samhengi skal ég segja þér hvaða vandamál við áttum í kerfinu í byrjun árs 2016, að við þurftum að takast á við aðskilnað þjónustu.
Einn MySql gagnagrunnur, þar sem öll forrit sem voru til á þeim tíma í Dodo IS skrifuðu skrárnar sínar. Afleiðingarnar voru:
- Mikið álag (með 85% beiðna var lesið).
- Grunnurinn hefur stækkað. Vegna þessa varð kostnaður þess og stuðningur vandamál.
- Einn bilunarpunktur. Ef eitt forrit sem skrifar í gagnagrunninn byrjaði skyndilega að gera það virkari, þá fundu önnur forrit fyrir því.
- Óhagkvæmni í geymslu og fyrirspurnum. Oft voru gögnin geymd í einhverju skipulagi sem hentaði fyrir sumar aðstæður en hentaði ekki öðrum. Vísitölur flýta fyrir sumum aðgerðum en geta hægt á öðrum.
- Sum vandamálanna voru fjarlægð með skyndiminni sem voru búnar til og eftirlíkingar af lestri til stöðvanna (þetta verður sérstök grein), en þau leyfðu þeim aðeins að vinna tíma og leystu ekki vandamálið í grundvallaratriðum.
Vandamálið var tilvist einingjans sjálfs. Afleiðingarnar voru:
- Einstakar og sjaldgæfar útgáfur.
- Erfiðleikar við sameiginlegan þroska fjölda fólks.
- Vanhæfni til að koma með nýja tækni, nýja umgjörð og bókasöfn.
Vandamálum með grunninn og einlitinn hefur verið lýst mörgum sinnum, til dæmis í tengslum við hrun snemma árs 2018 (, и ), svo ég mun ekki dvelja of mikið. Ég vil bara segja að við vildum veita meiri sveigjanleika við þróun þjónustu. Í fyrsta lagi varðaði þetta þá sem voru mest hlaðnir og rót í öllu kerfinu - Auth og Tracker.
The Back Office Path: Aðskildar bækistöðvar og strætó
kafli Leiðsögn
Monolith kerfi 2016
Hér eru helstu blokkir Dodo IS 2016 einliða, og rétt fyrir neðan er afrit af helstu verkefnum þeirra.
Afhending gjaldkera. Bókhald fyrir sendiboða, gefa út pantanir til sendiboða.
Samskiptamiðstöð. Tekið við pöntunum í gegnum rekstraraðila.
Vefsíða. Vefsíður okkar (dodopizza.ru, dodopizza.co.uk, dodopizza.by osfrv.).
Auth. Heimildar- og auðkenningarþjónusta fyrir bakvaktina.
Tracker. Panta rekja spor einhvers í eldhúsinu. Þjónusta til að merkja viðbúnaðarstöðu við undirbúning pöntunar.
Afgreiðsluborð Veitingahússins. Að taka við pöntunum á veitingastað, viðmót gjaldkera.
útflutningur. Hleður upp skýrslum í 1C fyrir bókhald.
Tilkynningar og reikningar. Raddskipanir í eldhúsinu (til dæmis „Ný pizza komin“) + reikningsprentun fyrir sendiboða.
Vaktastjóri. Viðmót fyrir störf vaktstjóra: pantanalisti, árangurslínur, flutningur starfsmanna á vakt.
Skrifstofustjóri. Viðmót í starfi sérleyfishafa og framkvæmdastjóra: móttaka starfsmanna, skýrslur um starf pítsustaðarins.
Stigatafla veitingastaðar. Sýning á matseðlum í sjónvörpum á pítsustöðum.
admin. Stillingar á tilteknu pítsustað: matseðill, verð, bókhald, kynningarkóðar, kynningar, vefborðar osfrv.
Persónulegur reikningur starfsmanns. Vinnuáætlanir starfsmanna, upplýsingar um starfsmenn.
Hvatningarráð fyrir eldhús. Sér skjár sem hangir í eldhúsinu og sýnir hraða pizzugerðarmannanna.
Samskipti. Sendi sms og tölvupóst.
FileStorage. Eigin þjónusta til að taka á móti og gefa út truflanir skrár.
Fyrstu tilraunir til að leysa vandamálin hjálpuðu okkur, en þær voru aðeins tímabundinn frestur. Þær urðu ekki kerfislausnir og því ljóst að eitthvað þurfti að gera við grunnana. Til dæmis að skipta almennum gagnagrunni í nokkra sérhæfðari.
Byrjað að afferma Monolith: Auth and Tracker Separation
Helstu þjónusturnar sem síðan skráðu og las úr gagnagrunninum meira en aðrar:
- Auth. Heimildar- og auðkenningarþjónusta fyrir bakvaktina.
- Rekja spor einhvers. Panta rekja spor einhvers í eldhúsinu. Þjónusta til að merkja viðbúnaðarstöðu við undirbúning pöntunar.
Hvað gerir Auth?
Auth er þjónusta þar sem notendur skrá sig inn á bakskrifstofuna (það er sérstakur sjálfstæður inngangur viðskiptavinarmegin). Einnig er þess krafist í beiðninni að ganga úr skugga um að tilskilinn aðgangsréttur sé til staðar og að þessi réttindi hafi ekki breyst frá síðustu innskráningu. Í gegnum það fara tæki inn á pítsustaðinn.
Til dæmis viljum við opna skjá með stöðu fullunnar pantanir á sjónvarpinu sem hangir í salnum. Þá opnum við auth.dodopizza.ru, veldu "Innskráning sem tæki", kóði birtist sem hægt er að slá inn á sérstakri síðu á tölvu vaktstjórans, sem gefur til kynna tegund tækis (tæki). Sjónvarpið sjálft mun skipta yfir í það viðmót sem óskað er eftir á pítsustaðnum og byrjar að birta nöfn viðskiptavina sem panta pantanir þar.
Hvaðan eru hleðslur?
Hver innskráður notandi bakskrifstofu fer í gagnagrunninn, í notendatöfluna fyrir hverja beiðni, dregur notandann út í gegnum sql fyrirspurn og athugar hvort hann hafi nauðsynlegan aðgang og réttindi að þessari síðu.
Hvert tæki gerir það sama aðeins með tækjatöflunni, athugar hlutverk þess og aðgang. Mikill fjöldi beiðna til aðalgagnagrunnsins leiðir til hleðslu hans og sóun á auðlindum hins sameiginlega gagnagrunns fyrir þessar aðgerðir.
Affermingar Auth
Auth hefur einangrað lén, það er að gögn um notendur, innskráningar eða tæki fara inn í þjónustuna (í bili) og eru þar áfram. Ef einhver þarfnast þeirra mun hann fara í þessa þjónustu til að fá gögn.
VAR. Upprunalega vinnuáætlunin var sem hér segir:
Mig langar að útskýra aðeins hvernig þetta virkaði:
- Beiðni utan frá kemur til bakendans (það er Asp.Net MVC), kemur með sessuköku, sem er notuð til að fá lotugögn frá Redis(1). Það inniheldur annað hvort upplýsingar um aðgang og þá er aðgangur að stjórnanda opinn (3,4), eða ekki.
- Ef það er enginn aðgangur þarftu að fara í gegnum heimildarferlið. Hér, til einföldunar, er það sýnt sem hluti af slóðinni í sama eiginleika, þó það sé umskipti yfir á innskráningarsíðuna. Ef um jákvæða atburðarás er að ræða munum við fá rétt kláraða lotu og fara í Backoffice Controller.
- Ef það eru gögn, þá þarftu að athuga hvort þau séu mikilvæg í notendagrunninum. Hefur hlutverk hans breyst, á ekki að leyfa honum að vera á síðunni núna? Í þessu tilviki, eftir að hafa fengið lotuna (1), þarftu að fara beint í gagnagrunninn og athuga aðgang notandans með því að nota auðkenningarrökfræðilagið (2). Næst, annað hvort á innskráningarsíðuna, eða farðu á stjórnandann. Svo einfalt kerfi, en ekki alveg staðlað.
- Ef allar aðferðir eru samþykktar, þá sleppum við lengra í rökfræðinni í stýringar og aðferðum.
Notendagögn eru aðskilin frá öllum öðrum gögnum, þau eru geymd í sérstakri aðildartöflu, aðgerðir úr AuthService rökfræðilaginu gætu vel orðið api aðferðir. Lénsmörk eru skilgreind nokkuð skýrt: notendur, hlutverk þeirra, aðgangsgögn, veiting og afturköllun aðgangs. Allt lítur út fyrir að hægt sé að taka það út í sérstakri þjónustu.
VERÐA. Svo þeir gerðu:
Þessi nálgun hefur ýmis vandamál. Til dæmis, að hringja í aðferð inni í ferli er ekki það sama og að hringja í ytri þjónustu í gegnum http. Seinkun, áreiðanleiki, viðhaldshæfni, gagnsæi starfseminnar eru allt öðruvísi. Andrey Morevskiy talaði nánar um slík vandamál í skýrslu sinni. .
Auðkenningarþjónustan og þar með tækjaþjónustan eru notuð fyrir bakþjónustuna, það er fyrir þjónustu og viðmót sem notuð eru í framleiðslu. Auðkenning fyrir þjónustu viðskiptavina (eins og vefsíðu eða farsímaforrit) á sér stað sérstaklega án þess að nota Auth. Aðskilnaðurinn tók um eitt ár og nú erum við aftur að takast á við þetta efni, að flytja kerfið yfir í nýja auðkenningarþjónustu (með stöðluðum samskiptareglum).
Hvers vegna tók aðskilnaðurinn svona langan tíma?
Það voru mörg vandamál á leiðinni sem hægðu á okkur:
- Við vildum færa notenda-, tæki- og auðkenningargögn úr landssértækum gagnagrunnum í einn. Til að gera þetta þurftum við að þýða allar töflur og notkun úr int auðkenninu yfir í alþjóðlegt UUId auðkenni (nýlega endurunnið þennan kóða og opinn uppspretta verkefni ). Geymsla notendagagna (þar sem það eru persónulegar upplýsingar) hefur sínar takmarkanir og í sumum löndum er nauðsynlegt að geyma þau sérstaklega. En alþjóðlegt auðkenni notandans verður að vera.
- Margar töflur í gagnagrunninum hafa endurskoðunarupplýsingar um notandann sem framkvæmdi aðgerðina. Þetta krafðist viðbótarkerfis til samræmis.
- Eftir að api-þjónustur voru stofnaður var langur og hægfara tími umskipti yfir í annað kerfi. Skipting varð að vera óaðfinnanleg fyrir notendur og kröfðust handavinnu.
Skráningarkerfi tækja á pítsustað:
Almennur arkitektúr eftir útdrátt Auth and Devices þjónustu:
Athugið. Fyrir árið 2020 erum við að vinna að nýrri útgáfu af Auth, sem er byggð á OAuth 2.0 heimildarstaðlinum. Þessi staðall er nokkuð flókinn, en hann er gagnlegur til að þróa gegnumstreymis auðkenningarþjónustu. Í greininni "» við Alexey Chernyaev reyndum að segja frá staðlinum eins einfaldlega og skýrt og mögulegt var svo þú sparar tíma við að læra það.
Hvað gerir Tracker?
Nú um annað af hlaðna þjónustunni. Rekja spor einhvers gegnir tvöföldu hlutverki:
- Annars vegar er verkefni þess að sýna starfsmönnum í eldhúsinu hvaða pantanir eru í gangi núna, hvaða vörur þarf að elda núna.
- Á hinn bóginn að stafræna alla ferla í eldhúsinu.
Þegar ný vara birtist í pöntun (td pítsa) fer hún á eftirlitsstöðina Rolling out. Á þessari stöð er pizzugerðarmaður sem tekur bollu af tilskildri stærð og rúllar henni út, eftir það merkir hann á rekjaspjaldtölvuna að hann hafi klárað verkefnið sitt og flytur rúllaða deigbotninn á næstu stöð - "Initiation" .
Þar fyllir næsti pizzugerðarmaður pizzuna, skráir svo á spjaldtölvuna að hann hafi klárað verkefnið sitt og setur pizzuna í ofninn (þetta er líka sérstök stöð sem þarf að skrá á spjaldtölvuna). Slíkt kerfi var frá upphafi í Dodo og alveg frá upphafi tilvistar Dodo IS. Það gerir þér kleift að fylgjast með og stafræna öll viðskipti. Að auki bendir mælirinn á hvernig á að elda tiltekna vöru, leiðbeinir hverri vörutegund í samræmi við framleiðslukerfi hennar, geymir ákjósanlegan eldunartíma fyrir vöruna og fylgist með öllum aðgerðum á vörunni.
Svona lítur skjár spjaldtölvunnar út á stöð rekja spor einhvers "Raskatka"
Hvaðan eru hleðslur?
Hver pítsustaðurinn hefur um fimm töflur með rekja spor einhvers. Árið 2016 vorum við með meira en 100 pítsuhús (og nú meira en 600). Hver spjaldtölva sendir beiðni til bakendans einu sinni á 10 sekúndna fresti og skafar gögn úr pöntunartöflunni (tengingu við viðskiptavininn og heimilisfang), pöntunarsamsetningu (tengingu við vöruna og magnupplýsingar), hvatningarbókhaldstöflunni (þ. ýtingartími er rakinn í henni). Þegar pizzuframleiðandi smellir á vöru á rakningnum eru færslurnar í öllum þessum töflum uppfærðar. Pantanataflan er almenn, hún inniheldur einnig innlegg þegar tekið er við pöntun, uppfærslur frá öðrum hlutum kerfisins og fjölmargar upplestur, til dæmis á sjónvarpi sem hangir á pítsustað og sýnir fullbúnar pantanir til viðskiptavina.
Á tímabili baráttu við álag, þegar allt og allt var í skyndiminni og flutt yfir á ósamstillta eftirmynd stöðvarinnar, héldu þessar aðgerðir með rekja spor einhvers áfram til aðalstöðvarinnar. Það ætti ekki að vera nein töf, gögnin ættu að vera uppfærð, ósamstilltur er óviðunandi.
Einnig, skortur á eigin töflum og vísitölum á þeim leyfði ekki að skrifa nákvæmari fyrirspurnir sem voru sérsniðnar fyrir notkun þeirra. Til dæmis gæti verið hagkvæmt fyrir rekja spor einhvers að hafa vísitölu fyrir pítsustað á pöntunarborði. Við fjarlægjum alltaf pizzeriapantanir úr rekjabankagagnagrunninum. Á sama tíma, fyrir móttöku pöntunar, skiptir ekki svo miklu máli í hvaða pítsustað það fellur, það er mikilvægara hvaða viðskiptavinur gerði þessa pöntun. Og þýðir að þar er vísitalan á viðskiptavininn nauðsynleg. Það er heldur ekki nauðsynlegt fyrir rekjandann að geyma auðkenni prentaðrar kvittunar eða bónusakynninga sem tengjast pöntuninni í pöntunartöflunni. Þessar upplýsingar hafa ekki áhuga á rekjaþjónustunni okkar. Í sameiginlegum einhæfum gagnagrunni gætu töflur aðeins verið málamiðlun milli allra notenda. Þetta var eitt af upphaflegu vandamálunum.
VAR. Upprunalegur arkitektúr var:
Jafnvel eftir að hafa verið aðskilin í aðskilda ferla, var mestur kóðagrunnurinn áfram sameiginlegur fyrir mismunandi þjónustu. Allt fyrir neðan stýringarnar var einn og bjó í sömu geymslunni. Við notuðum algengar aðferðir við þjónustu, geymslur, sameiginlegan grunn, þar sem sameiginlegar töflur lágu.
Affermingarspori
Helsta vandamálið með rekja spor einhvers er að gögnin verða að vera samstillt á milli mismunandi gagnagrunna. Þetta er líka helsti munurinn á því frá aðskilnaði Auth þjónustunnar, pöntunin og staða hennar getur breyst og ætti að birtast í mismunandi þjónustum.
Við tökum við pöntun í kassa veitingastaðarins (þetta er þjónusta), hún er geymd í gagnagrunninum í stöðunni "Samþykkt". Eftir það ætti hann að komast að rekja spor einhvers, þar sem hann mun breyta stöðu sinni nokkrum sinnum í viðbót: úr „Eldhúsi“ í „Pakkað“. Á sama tíma geta einhver ytri áhrif frá gjaldkera eða Shift Manager viðmóti átt sér stað með pöntuninni. Ég mun gefa pöntunarstöðuna með lýsingu þeirra í töflunni:
Kerfið til að breyta pöntunarstöðu lítur svona út:
Staða breytast á milli mismunandi kerfa. Og hér er rekja spor einhvers endanlegt kerfi þar sem gögnunum er lokað. Við höfum séð nokkrar mögulegar aðferðir við skiptingu í slíku tilviki:
- Við sameinum allar pöntunaraðgerðir í eina þjónustu. Í okkar tilviki krefst þessi valkostur of mikillar þjónustu til að vinna með pöntunina. Ef við stoppuðum við það myndum við fá seinni einlitann. Við myndum ekki leysa vandamálið.
- Eitt kerfi hringir í annað. Seinni valkosturinn er nú þegar áhugaverðari. En með því eru símtalakeðjur mögulegar (), tenging íhlutanna er hærri, það er erfiðara að stjórna því.
- Við skipuleggjum viðburði og hver þjónusta hefur samskipti við aðra í gegnum þessa viðburði. Þar af leiðandi var það þriðji kosturinn sem varð fyrir valinu, en samkvæmt því byrja allar þjónustur að skiptast á atburðum sín á milli.
Það að við völdum þriðja valmöguleikann þýddi að rekja spor einhvers gagnagrunns og fyrir hverja breytingu á röðinni sendi hann viðburð um þetta sem aðrar þjónustur gerast áskrifendur að og fellur líka inn í aðalgagnagrunninn. Til þess þurftum við einhverja þjónustu sem myndi tryggja afhendingu skilaboða á milli þjónustu.
Á þeim tíma vorum við þegar með RabbitMQ í staflanum, þess vegna var lokaákvörðunin um að nota það sem skilaboðamiðlara. Skýringarmyndin sýnir skiptingu pöntunar frá gjaldkera veitingahúss í gegnum rekja spor einhvers, þar sem hún breytir stöðu sinni og birtingu hennar í pantanaviðmóti stjórnanda. VERÐA:
Pantaðu leið skref fyrir skref
Pöntunarslóðin byrjar á einni af pöntunaruppsprettuþjónustunum. Hér er gjaldkeri veitingastaðarins:
- Við kassann er pöntunin alveg tilbúin og það er kominn tími til að senda hana til rekjandans. Atburðinum sem rekja spor einhvers er áskrifandi að er kastað.
- Trackerinn, sem tekur við pöntun fyrir sig, vistar hana í eigin gagnagrunn, gerir viðburðinn „Pöntun samþykkt af rekja spor einhvers“ og sendir hana til RMQ.
- Það eru nokkrir umsjónarmenn nú þegar áskrifendur að viðburðarrútunni í hverri pöntun. Fyrir okkur er sá sem gerir samstillingu með einlitum grunni mikilvægur.
- Meðhöndlarinn tekur á móti atburði, velur úr honum gögn sem eru mikilvæg fyrir hann: í okkar tilviki er þetta staða pöntunarinnar "Samþykkt af rekja spor einhvers" og uppfærir pöntunareiningu sína í aðalgagnagrunninum.
Ef einhvern vantar pöntun úr einstæðu borðpöntunum, þá geturðu líka lesið hana þaðan. Til dæmis þarf pantanaviðmótið í Shift Manager þetta:
Öll önnur þjónusta getur líka gerst áskrifandi að pöntunum frá rekja spor einhvers til að nota þá fyrir sig.
Ef pöntunin er tekin í notkun eftir nokkurn tíma, þá breytist staða hennar fyrst í gagnagrunni hennar (Tracker gagnagrunnur), og þá myndast "OrderIn Progress" atburðurinn strax. Það kemst líka inn í RMQ, þaðan sem það er samstillt í einhæfan gagnagrunn og afhent til annarrar þjónustu. Það geta verið ýmis vandamál á leiðinni, nánari upplýsingar um þau er að finna í skýrslu Zhenya Peshkov .
Endanleg arkitektúr eftir breytingar á Auth og Tracker
Samantekt á milliniðurstöðu: Upphaflega fékk ég þá hugmynd að pakka níu ára sögu Dodo IS kerfisins í eina grein. Mig langaði til að tala hratt og einfaldlega um þróunarstig. Hins vegar, þegar ég settist niður fyrir efnið, áttaði ég mig á því að allt er miklu flóknara og áhugaverðara en það virðist.
Þegar ég velti fyrir mér ávinningi (eða skorti á) slíks efnis, komst ég að þeirri niðurstöðu að stöðug þróun er ómöguleg án fullgildra annála atburða, ítarlegra yfirlitsmynda og greiningar á fyrri ákvörðunum mínum.
Ég vona að það hafi verið gagnlegt og áhugavert fyrir þig að fræðast um leið okkar. Nú stendur ég frammi fyrir vali hvaða hluta Dodo IS kerfisins ég á að lýsa í næstu grein: skrifa í athugasemdir eða kjósa.
Aðeins skráðir notendur geta tekið þátt í könnuninni. , takk.
Hvaða hluta af Dodo IS myndir þú vilja vita um í næstu grein?
-
24,1%Snemma monolith í Dodo IS (2011-2015)14
-
24,1%Fyrstu vandamálin og lausnir þeirra (2015-2016)14
-
20,7%Slóð viðskiptavinarhliðar: framhlið yfir grunn (2016-2017)12
-
36,2%Saga raunverulegrar örþjónustu (2018-2019)21
-
44,8%Algjör saga einlitsins og stöðugleika arkitektúrsins26
-
29,3%Um frekari áætlanir um þróun kerfisins17
-
19,0%Ég vil ekki vita neitt um Dodo IS11
58 notendur kusu. 6 notendur sátu hjá.
Heimild: www.habr.com