Habr muuttaa maailmaa. Olemme pitäneet blogia nyt yli vuoden. Noin puoli vuotta sitten saimme Khabrovitesilta täysin loogisen palautteen: ”Dodo, sanot kaikkialla, että sinulla on oma järjestelmäsi. Ja mikä tämä järjestelmä on? Ja miksi pizzaketju tarvitsee sitä?
Istuimme, ajattelimme ja ymmärsimme, että olet oikeassa. Yritämme selittää kaiken sormillamme, mutta se tulee repeytyneiksi paloiksi, eikä missään ole täydellistä kuvausta järjestelmästä. Siitä alkoi pitkä matka tiedon keräämiseen, tekijöiden etsimiseen ja artikkelisarjan kirjoittamiseen Dodo IS:stä. Mennään!
Kiitokset: Kiitos palautteestasi kanssamme. Hänen ansiosta kuvailimme lopulta järjestelmän, kokosimme teknisen tutkan ja julkaisemme pian laajan kuvauksen prosesseistamme. Ilman teitä olisimme istuneet siellä vielä viisi vuotta.
Artikkelisarja "Mikä on Dodo IS?" kertoo aiheesta:
- Varhainen monoliitti Dodo IS:ssä (2011-2015). (Käynnissä...)
- Takatoimistopolku: erilliset tukikohdat ja bussi. (sinä olet täällä)
- Asiakaspuolen polku: julkisivu pohjan yli (2016-2017). (Käynnissä...)
- Todellisten mikropalvelujen historiaa. (2018-2019). (Käynnissä...)
- Monoliitin sahaus ja arkkitehtuurin vakauttaminen valmis. (Käynnissä...)
Jos olet kiinnostunut tietämään jotain muuta - kirjoita kommentteihin.
Kirjoittajan mielipide kronologisesta kuvauksesta
Pidän säännöllisesti kokouksen uusille työntekijöille aiheesta "Järjestelmäarkkitehtuuri". Kutsumme sitä "Intro to Dodo IS Architecture" ja se on osa uusien kehittäjien perehdytysprosessia. Kerroen tavalla tai toisella arkkitehtuuristamme, sen piirteistä, olen synnyttänyt kuvaukseen tietyn historiallisen lähestymistavan.
Perinteisesti katsomme järjestelmää joukoksi komponentteja (teknisiä tai korkeamman tason), liiketoimintamoduuleja, jotka ovat vuorovaikutuksessa toistensa kanssa jonkin tavoitteen saavuttamiseksi. Ja jos tällainen näkemys on perusteltu suunnittelulle, se ei ole aivan sopiva kuvausta ja ymmärtämistä varten. Tässä on useita syitä:
- Todellisuus on eri asia kuin paperilla. Kaikki ei mene suunnitelmien mukaan. Ja olemme kiinnostuneita siitä, kuinka se todellisuudessa osoittautui ja toimii.
- Johdonmukainen tiedon esittäminen. Itse asiassa voit siirtyä kronologisesti alusta nykyiseen tilaan.
- Yksinkertaisesta monimutkaiseen. Ei yleisesti, mutta meidän tapauksessamme. Arkkitehtuuri siirtyi yksinkertaisemmista lähestymistavoista monimutkaisempiin. Usein monimutkaisuuden kautta ratkaistiin toteutuksen nopeuden ja vakauden ongelmat sekä kymmeniä muita ominaisuuksia ei-toiminnallisten vaatimusten luettelosta ( hyvin sanottu monimutkaisuuden vastakohtana muihin vaatimuksiin).
Vuonna 2011 Dodo IS -arkkitehtuuri näytti tältä:
Vuoteen 2020 mennessä siitä on tullut hieman monimutkaisempi ja siitä on tullut tällainen:
Miten tämä kehitys tapahtui? Miksi järjestelmän eri osia tarvitaan? Mitä arkkitehtonisia päätöksiä tehtiin ja miksi? Selvitetään tässä artikkelisarjassa.
Vuoden 2016 ensimmäiset ongelmat: miksi palveluiden pitäisi jättää monoliitti?
Syklin ensimmäiset artikkelit kertovat palveluista, jotka erosivat ensimmäisenä monoliitista. Laitan teidät kontekstiin, kerron teille, mitä ongelmia meillä oli järjestelmässä vuoden 2016 alkuun mennessä, että jouduimme käsittelemään palvelujen erottamista.
Yksi MySql-tietokanta, johon kaikki Dodo IS:ssä tuolloin olemassa olleet sovellukset kirjoittivat tietueensa. Seuraukset olivat:
- Raskas kuorma (85 % pyynnöistä oli lukemista).
- Pohja on kasvanut. Tämän vuoksi sen kustannuksista ja tuesta tuli ongelma.
- Yksi epäonnistumispiste. Jos yksi tietokantaan kirjoittava sovellus alkoi yhtäkkiä tehdä sitä aktiivisemmin, muut sovellukset tunsivat sen itsestään.
- Tehottomuus varastoinnissa ja kyselyissä. Usein tiedot tallennettiin johonkin rakenteeseen, joka oli kätevä joillekin skenaarioille, mutta ei sovellu muille. Indeksit nopeuttavat joitain toimintoja, mutta voivat hidastaa toisia.
- Osa ongelmista poistettiin hätäisesti tehdyillä välimuistilla ja luku-kopioilla tukikohtiin (tämä tulee olemaan erillinen artikkeli), mutta ne antoivat heille vain aikaa eivätkä ratkaisseet ongelmaa pohjimmiltaan.
Ongelmana oli itse monoliitin läsnäolo. Seuraukset olivat:
- Yksittäisiä ja harvinaisia julkaisuja.
- Vaikeus monien ihmisten yhteisessä kehittämisessä.
- Kyvyttömyys tuoda uusia teknologioita, uusia kehyksiä ja kirjastoja.
Pohjan ja monoliitin ongelmia on kuvattu useaan otteeseen, esimerkiksi vuoden 2018 alussa tapahtuneiden törmäysten yhteydessä (, и ), joten en viivyttele liikaa. Sanon vain, että halusimme antaa enemmän joustavuutta palvelujen kehittämisessä. Ensinnäkin tämä koski niitä, jotka olivat ladatuimpia ja pääkäyttäjän koko järjestelmässä - Auth ja Tracker.
Back Office -polku: erilliset tukikohdat ja bussi
Luku Navigointi
Monolith-ohjelma 2016
Ennen kuin olet Dodo IS 2016 -monoliitin päälohkot, ja juuri alla on transkriptio heidän päätehtävistään.
Kassa Toimitus. Kuririen kirjanpito, tilausten antaminen kuriireille.
Yhteyskeskus. Tilausten vastaanotto operaattorin kautta.
paikka. Verkkosivustomme (dodopizza.ru, dodopizza.co.uk, dodopizza.by jne.).
auth. Valtuutus- ja todennuspalvelu taustatoimistolle.
Трекер. Tilausseuranta keittiössä. Palvelu valmiustilojen merkitsemiseen tilausta valmisteltaessa.
Ravintolan kassa. Tilausten vastaanotto ravintolassa, kassan käyttöliittymät.
Vie. Raporttien lataaminen 1C:ssä kirjanpitoa varten.
Ilmoitukset ja laskut. Äänikomennot keittiössä (esim. "Uusi pizza saapui") + laskun tulostus kuriireille.
Vuoropäällikkö. Vuoropäällikön työhön liittyvät rajapinnat: tilauslista, suorituskaaviot, työntekijöiden siirto vuoroon.
Toimistopäällikkö. Liitännät franchising-ottajan ja johtajan työhön: työntekijöiden vastaanotto, raportit pizzerian työstä.
Ravintolan tulostaulu. Valikkonäyttö pizzerioiden televisioissa.
järjestelmänvalvoja. Asetukset tietyssä pizzeriassa: ruokalista, hinnat, kirjanpito, tarjouskoodit, tarjoukset, verkkosivustojen bannerit jne.
Työntekijän henkilökohtainen tili. Työntekijöiden työaikataulut, tiedot työntekijöistä.
Keittiön motivaatiolautakunta. Erillinen näyttö, joka roikkuu keittiössä ja näyttää pizzanvalmistajien nopeuden.
Viestintä. SMS ja sähköpostin lähettäminen.
FileStorage. Oma palvelu staattisten tiedostojen vastaanottamiseen ja antamiseen.
Ensimmäiset yritykset ongelmien ratkaisemiseksi auttoivat meitä, mutta ne olivat vain väliaikainen hengähdystauko. Niistä ei tullut järjestelmäratkaisuja, joten oli selvää, että kannaksille oli tehtävä jotain. Esimerkiksi jakaa yleinen tietokanta useisiin erikoistuneempiin tietokantoihin.
Monolithin purkamisen aloittaminen: Auth and Tracker Separation
Tärkeimmät palvelut, jotka sitten tallensivat ja lukivat tietokannasta enemmän kuin muut:
- Tod. Valtuutus- ja todennuspalvelu taustatoimistolle.
- Tracker. Tilausseuranta keittiössä. Palvelu valmiustilojen merkitsemiseen tilausta valmisteltaessa.
Mitä Auth tekee?
Auth on palvelu, jonka kautta käyttäjät kirjautuvat sisään taustatoimistoon (asiakaspuolella on erillinen itsenäinen sisäänkäynti). Pyynnössä pyydetään myös varmistamaan, että vaaditut käyttöoikeudet ovat olemassa ja että nämä oikeudet eivät ole muuttuneet edellisen kirjautumisen jälkeen. Sen kautta laitteet tulevat pizzeriaan.
Haluamme esimerkiksi avata aulassa roikkuvalle televisiolle näytön valmiiden tilausten tiloista. Sitten avaamme auth.dodopizza.ru, valitse "Kirjaudu sisään laitteena", näkyviin tulee koodi, joka voidaan syöttää vuoropäällikön tietokoneen erityiselle sivulle, joka osoittaa laitteen (laitteen) tyypin. Televisio vaihtaa itse pizzeriansa haluttuun käyttöliittymään ja alkaa näyttää asiakkaiden nimiä, joiden tilaukset ovat siellä valmiina.
Mistä kuormat ovat?
Jokainen sisäänkirjautunut back office -käyttäjä menee tietokantaan, käyttäjätaulukkoon jokaisen pyynnön kohdalla, hakee käyttäjän sql-kyselyn kautta ja tarkistaa, onko hänellä tarvittavat käyttöoikeudet ja oikeudet tälle sivulle.
Kukin laitteista tekee saman vain laitetaulukon kanssa ja tarkistaa sen roolin ja pääsyn. Suuri määrä pyyntöjä päätietokantaan johtaa sen latautumiseen ja yhteisen tietokannan resurssien tuhlaamiseen näitä toimintoja varten.
Puretaan Auth
Authilla on eristetty verkkotunnus, eli tiedot käyttäjistä, kirjautumisista tai laitteista tulevat palveluun (toistaiseksi) ja pysyvät siellä. Jos joku tarvitsee niitä, hän hakee tietoja tästä palvelusta.
OLI. Alkuperäinen työsuunnitelma oli seuraava:
Haluaisin selittää hieman, kuinka se toimii:
- Ulkopuolelta tuleva pyyntö tulee taustajärjestelmään (on Asp.Net MVC), tuo mukanaan istuntoevästeen, jota käytetään istuntotietojen hakemiseen Redisistä(1). Se sisältää joko tietoja käyttöoikeuksista ja sitten pääsy ohjaimeen on auki (3,4) tai ei.
- Jos pääsyä ei ole, sinun on suoritettava valtuutusmenettely. Tässä yksinkertaisuuden vuoksi se näytetään osana polkua samassa määritteessä, vaikka se on siirtymä kirjautumissivulle. Positiivisen skenaarion tapauksessa saamme oikein suoritetun istunnon ja siirrymme Backoffice Controlleriin.
- Jos tietoja on, sinun on tarkistettava niiden relevanssi käyttäjätietokannasta. Onko hänen roolinsa muuttunut, eikö hänen pitäisi päästää sivulle nyt? Tässä tapauksessa istunnon vastaanottamisen (1) jälkeen sinun on mentävä suoraan tietokantaan ja tarkistettava käyttäjän pääsy autentikointilogiikkakerroksen (2) avulla. Seuraavaksi joko kirjautumissivulle tai ohjaimeen. Tällainen yksinkertainen järjestelmä, mutta ei aivan vakio.
- Jos kaikki proseduurit on läpäisty, ohitamme pidemmälle ohjaimien ja menetelmien logiikan.
Käyttäjätiedot erotetaan kaikesta muusta tiedosta, ne tallennetaan erilliseen jäsentaulukkoon, AuthService-logiikkakerroksen funktioista voi tulla api-menetelmiä. Toimialueen rajat on määritelty melko selkeästi: käyttäjät, heidän roolinsa, pääsytiedot, käyttöoikeuksien myöntäminen ja peruuttaminen. Kaikki näyttää siltä, että se voidaan ottaa pois erillisessä palvelussa.
TULLA. Joten he tekivät:
Tällä lähestymistavalla on useita ongelmia. Esimerkiksi menetelmän kutsuminen prosessin sisällä ei ole sama asia kuin ulkoisen palvelun kutsuminen http:n kautta. Latenssi, luotettavuus, ylläpidettävyys, toiminnan läpinäkyvyys ovat täysin erilaisia. Andrey Morevskiy puhui yksityiskohtaisemmin tällaisista ongelmista raportissaan. .
Todennuspalvelua ja sen mukana laitepalvelua käytetään taustatoimistoon eli tuotannossa käytettäviin palveluihin ja liitäntöihin. Asiakaspalveluiden (kuten verkkosivuston tai mobiilisovelluksen) todennus tapahtuu erikseen ilman todennusta. Erottelu kesti noin vuoden, ja nyt ollaan taas tämän aiheen parissa siirtämällä järjestelmän uusiin todennuspalveluihin (vakioprotokollien kanssa).
Miksi ero kesti niin kauan?
Matkan varrella oli monia ongelmia, jotka hidastivat meitä:
- Halusimme siirtää käyttäjä-, laite- ja todennustiedot maakohtaisista tietokannoista yhdeksi. Tätä varten meidän piti kääntää kaikki taulukot ja käyttö int-tunnisteesta globaaliksi UUId-tunnisteeksi (äskettäin muokattu tämä koodi ja avoimen lähdekoodin projekti ). Käyttäjätietojen säilyttämisellä (koska ne ovat henkilökohtaisia tietoja) on rajoituksensa ja joissakin maissa ne on tallennettava erikseen. Mutta käyttäjän globaalin tunnuksen on oltava.
- Monissa tietokannan taulukoissa on tarkastustietoja toiminnon suorittaneesta käyttäjästä. Tämä vaati ylimääräistä mekanismia johdonmukaisuuden takaamiseksi.
- Api-palvelujen luomisen jälkeen oli pitkä ja asteittainen siirtyminen toiseen järjestelmään. Vaihtamisen tuli olla käyttäjille saumatonta ja vaatia manuaalista työtä.
Laitteen rekisteröintisuunnitelma pizzeriassa:
Yleinen arkkitehtuuri Auth and Devices -palvelun purkamisen jälkeen:
Huomata. Vuodelle 2020 kehitämme uutta Auth-versiota, joka perustuu OAuth 2.0 -valtuutusstandardiin. Tämä standardi on melko monimutkainen, mutta se on hyödyllinen läpivientitodennuspalvelun kehittämisessä. Artikkelissa "» me Aleksei Chernyaev yritimme kertoa standardista mahdollisimman yksinkertaisesti ja selkeästi, jotta säästät aikaa sen tutkimiseen.
Mitä Tracker tekee?
Nyt noin toisesta ladatusta palvelusta. Seuraajalla on kaksi roolia:
- Toisaalta sen tehtävänä on näyttää keittiössä oleville työntekijöille, mitä tilauksia on tällä hetkellä töissä, mitä tuotteita pitää kypsentää nyt.
- Toisaalta digitalisoida kaikki keittiön prosessit.
Kun tilaukseen ilmestyy uusi tuote (esimerkiksi pizza), se siirtyy Rolling Out Tracker -asemalle. Tällä asemalla on pizzantekijä, joka ottaa halutun kokoisen sämpylän ja kaulii sen, minkä jälkeen hän merkitsee seurantatablettiin, että hän on suorittanut tehtävänsä ja siirtää kaulitun taikinapohjan seuraavalle asemalle - "Aloitus" .
Siellä seuraava pizzantekijä täyttää pizzan, sitten kirjoittaa tablettiin, että hän on suorittanut tehtävänsä ja laittaa pizzan uuniin (tämä on myös erillinen asema, joka on merkittävä tablettiin). Tällainen järjestelmä oli Dodossa alusta alkaen ja Dodo IS:n olemassaolon alusta lähtien. Sen avulla voit seurata ja digitalisoida kaikkia tapahtumia. Lisäksi seurantalaite ehdottaa, miten tietty tuote kypsennetään, ohjaa jokaista tuotetyyppiä sen valmistussuunnitelmien mukaisesti, tallentaa tuotteen optimaalisen kypsennysajan ja seuraa kaikkia tuotteella suoritettavia toimintoja.
Tältä tabletin näyttö näyttää seurantalaitteen "Raskatka" asemalla
Mistä kuormat ovat?
Jokaisessa pizzeriassa on noin viisi tablettia, joissa on seurantalaite. Vuonna 2016 meillä oli yli 100 pizzeriaa (ja nyt yli 600). Jokainen tabletti tekee pyynnön taustajärjestelmälle 10 sekunnin välein ja raapui tiedot tilaustaulukosta (yhteys asiakkaaseen ja osoite), tilauksen koostumuksesta (yhteys tuotteeseen ja määrän ilmoittaminen), motivaatiolaskentataulukosta ( siinä seurataan painamisaikaa). Kun pizzantekijä napsauttaa tuotetta seurantalaitteella, kaikkien näiden taulukoiden merkinnät päivitetään. Tilaustaulukko on yleinen, se sisältää myös liitteitä tilauksen hyväksymisen yhteydessä, päivityksiä järjestelmän muista osista ja lukuisia lukemia esimerkiksi pizzeriassa roikkuvasta televisiosta, joka näyttää valmiita tilauksia asiakkaille.
Kuormien kamppailun aikana, kun kaikki ja kaikki oli välimuistissa ja siirretty tukikohdan asynkroniseen kopioon, nämä toiminnot seurannan kanssa jatkuivat päätukikohtaan. Ei saa olla viivettä, tietojen tulee olla ajan tasalla, synkronointia ei voida hyväksyä.
Myöskään omien taulukoiden ja niihin liittyvien hakemistojen puute ei mahdollistanut niiden käyttöön räätälöityjen tarkempien kyselyjen kirjoittamista. Seuraajan voi esimerkiksi olla tehokasta, jos tilaustaulukossa on pizzerian indeksi. Poistamme pizzeriatilaukset aina seurantatietokannasta. Samaan aikaan tilauksen vastaanottamisen kannalta ei ole niin tärkeää, mihin pizzeriaan se osuu, vaan tärkeämpää on se, mikä asiakas tämän tilauksen teki. Ja tarkoittaa, että asiakkaan indeksi on välttämätön. Seuraajan ei myöskään tarvitse tallentaa tilaukseen liittyvän painetun kuitin tai bonustarjousten tunnusta tilaustaulukkoon. Nämä tiedot eivät kiinnosta seurantapalveluamme. Yleisessä monoliittisessa tietokannassa taulukot voisivat olla vain kompromissi kaikkien käyttäjien välillä. Tämä oli yksi alkuperäisistä ongelmista.
OLI. Alkuperäinen arkkitehtuuri oli:
Jopa erillisiin prosesseihin jakamisen jälkeen suurin osa koodikannasta säilyi yhteisenä eri palveluille. Kaikki ohjainten alapuolella oli sinkkua ja asui samassa arkistossa. Käytimme yhteisiä palvelumenetelmiä, arkistoja, yhteistä pohjaa, jossa yhteiset taulukot olivat.
Trackerin purkaminen
Trackerin suurin ongelma on, että tiedot on synkronoitava eri tietokantojen välillä. Tämä on myös sen tärkein ero Auth-palvelun erottelusta, tilaus ja sen tila voivat muuttua ja ne tulisi näyttää eri palveluissa.
Hyväksymme tilauksen Ravintolan Kassalla (tämä on palvelu), se on tallennettu tietokantaan Hyväksytty-tilassa. Sen jälkeen hänen pitäisi päästä jäljittimeen, jossa hän muuttaa tilaansa vielä useita kertoja: "Keittiöstä" "Pakattu". Samanaikaisesti tilaukseen voi tulla ulkoisia vaikutteita kassa- tai vuoropäällikköliittymästä. Annan tilausten tilat ja niiden kuvaukset taulukossa:
Kaava tilausten tilan muuttamiseen näyttää tältä:
Tilat vaihtelevat eri järjestelmien välillä. Ja tässä seuranta ei ole lopullinen järjestelmä, jossa tiedot on suljettu. Olemme nähneet useita mahdollisia lähestymistapoja osiointiin tällaisessa tapauksessa:
- Keskitämme kaikki tilaustoimenpiteet yhteen palveluun. Meidän tapauksessamme tämä vaihtoehto vaatii liian paljon palvelua toimiakseen tilauksen kanssa. Jos pysähtyisimme siihen, saisimme toisen monoliitin. Emme ratkaisisi ongelmaa.
- Yksi järjestelmä soittaa toiselle. Toinen vaihtoehto on jo mielenkiintoisempi. Mutta sen avulla kutsuketjut ovat mahdollisia (), komponenttien liitettävyys on korkeampi, sitä on vaikeampi hallita.
- Järjestämme tapahtumia ja jokainen palvelu kommunikoi toistensa kanssa näiden tapahtumien kautta. Tämän seurauksena valittiin kolmas vaihtoehto, jonka mukaan kaikki palvelut alkavat vaihtaa tapahtumia keskenään.
Se, että valitsimme kolmannen vaihtoehdon, merkitsi sitä, että jäljittimellä olisi oma tietokanta, ja jokaisesta tilauksen muutoksesta se lähettäisi tapahtuman tästä tapahtumasta, johon muut palvelut tilaavat ja joka myös kuuluu päätietokantaan. Tätä varten tarvitsimme jonkin palvelun, joka varmistaisi viestien toimituksen palveluiden välillä.
Siihen mennessä meillä oli jo RabbitMQ pinossa, joten lopullinen päätös käyttää sitä viestivälittäjänä. Kaavio näyttää tilauksen siirtymisen ravintolan kassasta Trackerin kautta, jossa se muuttaa tilaansa ja sen näyttöä Esimiehen tilaukset -liittymässä. TULLA:
Tilaa polku askel askeleelta
Tilauspolku alkaa yhdestä tilauslähdepalvelusta. Tässä ravintolan kassa:
- Kassalla tilaus on täysin valmis, ja on aika lähettää se seurantaan. Tapahtuma, johon seurantalaite on tilattu, heitetään.
- Tracker, joka hyväksyy tilauksen itselleen, tallentaa sen omaan tietokantaansa, tekee tapahtuman "Tilaus on Trackerin hyväksymä" ja lähettää sen RMQ:lle.
- Tapahtumaväylään on jo tilattu useita käsittelijöitä tilausta kohden. Meille se, joka tekee synkronoinnin monoliittisen pohjan kanssa, on tärkeä.
- Käsittelijä vastaanottaa tapahtuman, valitsee siitä sen kannalta merkitykselliset tiedot: tämä on meidän tapauksessamme tilauksen tila "Trackerin hyväksymä" ja päivittää tilauskokonaisuuden päätietokannassa.
Jos joku tarvitsee tilauksen monoliittipöydän tilauksista, voit lukea sen myös sieltä. Esimerkiksi Shift Managerin Tilaukset-käyttöliittymä tarvitsee tämän:
Kaikki muut palvelut voivat myös tilata tilaustapahtumia trackeristä käyttääkseen niitä itse.
Jos tilaus otetaan käyttöön jonkin ajan kuluttua, sen tila muuttuu ensin tietokannassaan (Tracker-tietokanta), minkä jälkeen "OrderIn Progress" -tapahtuma generoidaan välittömästi. Se pääsee myös RMQ:han, josta se synkronoidaan monoliittiseen tietokantaan ja toimitetaan muihin palveluihin. Matkan varrella voi olla erilaisia ongelmia, lisätietoja niistä löytyy Zhenya Peshkovin raportista .
Lopullinen arkkitehtuuri Auth- ja Tracker-muutosten jälkeen
Yhteenveto välituloksesta: Aluksi minulla oli ajatus pakata Dodo IS -järjestelmän yhdeksän vuoden historia yhteen artikkeliin. Halusin puhua nopeasti ja yksinkertaisesti evoluution vaiheista. Kuitenkin istuen alas materiaalin ääressä tajusin, että kaikki on paljon monimutkaisempaa ja mielenkiintoisempaa kuin miltä näyttää.
Pohdiskellessani tällaisen aineiston etuja (tai sen puutetta) tulin siihen tulokseen, että jatkuva kehitys on mahdotonta ilman täysimittaista tapahtumakirjaa, yksityiskohtaisia retrospektiivisiä tutkimuksia ja aiempien päätösteni analysointia.
Toivon, että oli hyödyllistä ja mielenkiintoista oppia tiestämme. Nyt olen valinnan edessä, mitä Dodo IS -järjestelmän osaa kuvaan seuraavassa artikkelissa: kirjoita kommentteihin tai äänestä.
Vain rekisteröityneet käyttäjät voivat osallistua kyselyyn. , ole kiltti.
Mistä Dodo IS:n osasta haluaisit tietää seuraavassa artikkelissa?
-
24,1%Varhainen monoliitti Dodo IS:ssä (2011-2015)14
-
24,1%Ensimmäiset ongelmat ja niiden ratkaisut (2015-2016)14
-
20,7%Asiakaspuolen polku: julkisivu pohjan yli (2016-2017)12
-
36,2%Todellisten mikropalvelujen historia (2018-2019)21
-
44,8%Monoliitin täydellinen sahaus ja arkkitehtuurin stabilointi26
-
29,3%Tietoja järjestelmän kehittämisen jatkosuunnitelmista17
-
19,0%En halua tietää mitään Dodo IS11:stä
58 käyttäjää äänesti. 6 käyttäjää pidättyi äänestämästä.
Lähde: will.com