Dodo IS -arkkitehtuurin historia: Varhainen monoliitti

Tai jokainen onneton yritys, jolla on monoliitti, on onneton omalla tavallaan.

Dodo IS -järjestelmän kehittäminen aloitettiin välittömästi, kuten Dodo Pizza -liiketoiminnan, vuonna 2011. Se perustui ajatukseen liiketoimintaprosessien täydellisestä ja täydellisestä digitalisoinnista yksinään, joka jo silloin vuonna 2011 aiheutti paljon kysymyksiä ja skeptisyyttä. Mutta nyt 9 vuotta olemme kulkeneet tätä polkua - omalla kehityksellämme, joka alkoi monoliitista.

Tämä artikkeli on "vastaus" kysymyksiin "Miksi kirjoittaa arkkitehtuuri uudelleen ja tehdä niin suuria ja pitkäaikaisia ​​muutoksia?" takaisin edelliseen artikkeliin "Dodo IS -arkkitehtuurin historia: Takatoimiston tie". Aloitan siitä, miten Dodo IS:n kehitys alkoi, miltä alkuperäinen arkkitehtuuri näytti, miten uudet moduulit ilmestyivät ja minkä ongelmien takia piti tehdä suuria muutoksia.

Artikkelisarja "Mikä on Dodo IS?" kertoo aiheesta:

1. Varhainen monoliitti Dodo IS:ssä (2011-2015). (sinä olet täällä)

2. Back Office -polku: erilliset tukikohdat ja bussi.

3. Asiakaspuolen polku: julkisivu pohjan yli (2016-2017). (Käynnissä...)

4. Todellisten mikropalvelujen historiaa. (2018-2019). (Käynnissä...)

5. Monoliitin sahaus ja arkkitehtuurin vakauttaminen valmis. (Käynnissä...)

Alkuperäinen arkkitehtuuri

Vuonna 2011 Dodo IS -arkkitehtuuri näytti tältä:

Ensimmäinen moduuli arkkitehtuurissa on tilausten hyväksyminen. Liiketoimintaprosessi oli:

• asiakas soittaa pizzeriaan;

• johtaja ottaa puhelimen;

• hyväksyy tilauksen puhelimitse;

• täyttää sen rinnakkain tilauksen vastaanottorajapinnassa: huomioidaan tiedot asiakkaasta, tiedot tilaustiedoista, toimitusosoite. 

Tietojärjestelmän käyttöliittymä näytti tältä...

Ensimmäinen versio lokakuusta 2011:

Hieman paranneltu tammikuussa 2012

Dodo Pizza Tietojärjestelmän toimitus Pizzaravintola

Resurssit ensimmäisen tilauksen vastaanottomoduulin kehittämiseen olivat rajalliset. Meidän piti tehdä paljon, nopeasti ja pienellä porukalla. Pienessä tiimissä on 2 kehittäjää, jotka loivat pohjan koko tulevalle järjestelmälle.

Heidän ensimmäinen päätöksensä määritti teknologiapinon kohtalon:

• Taustaohjelma ASP.NET MVC, C#-kieli. Kehittäjät olivat dotnetchiki, tämä pino oli heille tuttu ja miellyttävä.

• Käyttöliittymä Bootstrapissa ja JQueryssä: käyttöliittymät itse kirjoitetuille tyyleille ja komentosareille. 

• MySQL-tietokanta: ei lisenssikustannuksia, helppokäyttöinen.

• Palvelimet Windows Serverillä, koska .NET voisi silloin olla vain Windowsin alla (emme käsittele Monosta).

Fyysisesti kaikki tämä ilmaistiin "omistajalle omistautumisessa". 

Tilaa sisäänottosovellusarkkitehtuuri

Sitten kaikki puhuivat jo mikropalveluista, ja SOA:ta käytettiin suurissa projekteissa 5 vuoden ajan, esimerkiksi WCF julkaistiin vuonna 2006. Mutta sitten he valitsivat luotettavan ja todistetun ratkaisun.

Tässä se on.

Asp.Net MVC on Razor, joka lomakkeen tai asiakkaan pyynnöstä renderöi HTML-sivun palvelimen renderöinnillä. Asiakkaalla CSS- ja JS-skriptit näyttävät jo tietoja ja suorittavat tarvittaessa AJAX-pyyntöjä JQueryn kautta.

Pyynnöt palvelimella päätyvät *Controller-luokkiin, joissa menetelmässä tapahtuu lopullisen HTML-sivun käsittely ja luominen. Ohjaimet tekevät pyyntöjä logiikkakerrokselle nimeltä *Services. Jokainen palvelu vastasi jotakin liiketoiminnan osa-aluetta:

• Esimerkiksi DepartmentStructureService jakoi tietoa pizzerioista, osastoista. Osasto on ryhmä pizzerioita, joita ylläpitää yksi franchising-saaja.

• ReceivingOrdersService hyväksyi ja laski tilauksen koostumuksen.

• Ja SmsService lähetti tekstiviestejä soittamalla API-palveluihin tekstiviestien lähettämiseksi.

Palvelut käsittelivät tietoja tietokannasta, tallentivat liiketoimintalogiikkaa. Jokaisella palvelulla oli yksi tai useampi *arkisto sopivalla nimellä. Ne sisälsivät jo kyselyitä tietokantaan tallennettuihin proseduureihin ja kartoittajien kerrokseen. Varastoissa oli liikelogiikkaa, varsinkin niissä, jotka antoivat raportointitietoja. ORM:ää ei käytetty, kaikki luottivat käsinkirjoitettuun sql:iin. 

Siellä oli myös verkkoaluemallin kerros ja yleisiä auttajaluokkia, esimerkiksi tilausluokka, joka tallensi tilauksen. Samassa paikassa kerroksessa oli apulainen näyttötekstin muuntamiseen valitun valuutan mukaan.

Kaikki tämä voidaan esittää tällaisella mallilla:

Tilaustapa

Harkitse yksinkertaistettua alkutapaa luoda tällainen tilaus.

Aluksi sivusto oli staattinen. Siinä oli hinnat, ja päällä - puhelinnumero ja merkintä "Jos haluat pizzan - soita numeroon ja tilaa." Tilausta varten meidän on toteutettava yksinkertainen kulku: 

• Asiakas vierailee staattisella sivustolla, jossa on hinnat, valitsee tuotteet ja soittaa sivustolla olevaan numeroon.

• Asiakas nimeää tuotteet, jotka hän haluaa lisätä tilaukseen.

• Antaa osoitteensa ja nimensä.

• Operaattori hyväksyy tilauksen.

• Tilaus näkyy hyväksyttyjen tilausten käyttöliittymässä.

Kaikki alkaa valikon näyttämisestä. Sisäänkirjautunut käyttäjä-operaattori hyväksyy vain yhden tilauksen kerrallaan. Siksi kärryn luonnos voidaan tallentaa hänen istuntoonsa (käyttäjän istunto tallennetaan muistiin). Siellä on ostoskori-objekti, joka sisältää tuotteet ja asiakastiedot.

Asiakas nimeää tuotteen, operaattori klikkaa sitä + tuotteen vieressä, ja pyyntö lähetetään palvelimelle. Tuotetiedot vedetään tietokannasta ja tuotteen tiedot lisätään ostoskoriin.

Huomata. Kyllä, täällä et voi noutaa tuotetta tietokannasta, vaan siirtää sen käyttöliittymästä. Mutta selvyyden vuoksi näytin tarkalleen polun tietokannasta. 

Kirjoita seuraavaksi asiakkaan osoite ja nimi. 

Kun napsautat "Luo tilaus":

• Pyyntö lähetetään osoitteeseen OrderController.SaveOrder().

• Saamme ostoskorin istunnosta, tuotteita on tarvittava määrä.

• Täydennämme Ostoskoria asiakastiedoilla ja välitämme sen ReceivingOrderService-luokan AddOrder-menetelmään, jossa se tallennetaan tietokantaan. 

• Tietokannassa on taulukot tilauksesta, tilauksen koostumuksesta, asiakkaasta, ja ne ovat kaikki yhteydessä toisiinsa.

• Tilausten näyttöliittymä avaa uusimmat tilaukset ja näyttää ne.

Uudet moduulit

Tilauksen ottaminen oli tärkeää ja tarpeellista. Et voi tehdä pizzaliikettä, jos sinulla ei ole myyntitilausta. Siksi järjestelmä alkoi hankkia toimintoja - noin vuosina 2012-2015. Tänä aikana ilmestyi monia erilaisia ​​​​järjestelmän lohkoja, joita kutsun moduulit, toisin kuin palvelun tai tuotteen käsite. 

Moduuli on joukko toimintoja, joita yhdistää jokin yhteinen liiketoimintatavoite. Samaan aikaan ne ovat fyysisesti samassa sovelluksessa.

Moduuleja voidaan kutsua järjestelmälohkoiksi. Tämä on esimerkiksi raportointimoduuli, järjestelmänvalvojan käyttöliittymät, ruokaseuranta keittiössä, valtuutus. Nämä ovat kaikki erilaisia ​​käyttöliittymiä, joistakin jopa erilaisia ​​visuaalisia tyylejä. Samaan aikaan kaikki on yhden sovelluksen, yhden käynnissä olevan prosessin puitteissa. 

Teknisesti moduulit suunniteltiin Areaksi (sellainen idea jäi jopa sisälle asp.net ydin). Siellä oli erilliset tiedostot käyttöliittymälle, malleille sekä niiden omille ohjainluokille. Tämän seurauksena järjestelmä muutettiin tästä ...

...tähän:

Jotkut moduulit toteutetaan erillisillä sivustoilla (suoritettava projekti), johtuen täysin erillisestä toiminnallisuudesta ja osittain hieman erillisestä, fokusoidummasta kehityksestä. Tämä:

• paikka - ensimmäinen versio sivusto dodopizza.ru.

• Vie: raporttien lataaminen Dodo IS:stä 1C:lle. 

• Henkilökohtainen - työntekijän henkilökohtainen tili. Se kehitettiin erikseen, ja sillä on oma sisääntulopiste ja erillinen muotoilu.

• fs — Statiikan isännöintiprojekti. Myöhemmin muutimme pois siitä siirtämällä kaikki staattiset asiat Akamai CDN:ään. 

Loput lohkot olivat BackOffice-sovelluksessa. 

Nimen selitys:

• Kassa - Ravintolan kassa.

• ShiftManager - käyttöliittymät "Shift Manager" -rooliin: pizzerioiden myyntitilastot, mahdollisuus laittaa tuotteita stop-listalle, muuttaa järjestystä.

• OfficeManager - rajapinnat "Pizzeria Manager"- ja "Franchisee"-rooleille. Täällä on koottu toimintoja pizzerian perustamiseen, sen bonuskampanjat, työntekijöiden vastaanottaminen ja työskentely, raportit.

• PublicScreens - rajapinnat pizzerioissa roikkuville televisioille ja tableteille. Televisiot näyttävät valikot, mainostiedot, tilauksen tilan toimituksen yhteydessä. 

He käyttivät yhteistä palvelukerrosta, yhteistä Dodo.Core-verkkoalueluokkalohkoa ja yhteistä kantaa. Joskus ne saattoivat silti johtaa siirtymiä pitkin toisiinsa. Yksittäiset sivustot mukaan lukien, kuten dodopizza.ru tai personal.dodopizza.ru, menivät yleisiin palveluihin.

Uusien moduulien ilmestyessä yritimme hyödyntää tietokantaan jo luotua palvelukoodia, tallennettuja proseduureja ja taulukoita mahdollisimman paljon. 

Jotta ymmärtäisit paremmin järjestelmään tehtyjen moduulien mittakaavan, tässä on kaavio vuodelta 2012 kehityssuunnitelmineen:

Vuoteen 2015 mennessä kaikki oli kartalla ja vielä enemmän oli tuotannossa.

• Tilausten vastaanottaminen on kasvanut erilliseksi Yhteyskeskuksen lohkoksi, jossa operaattori hyväksyy tilauksen.

• Pizzerioissa oli julkisia näyttöjä ruokalistoilla ja tiedoilla.

• Keittiössä on moduuli, joka soittaa automaattisesti ääniviestin "Uusi Pizza" kun uusi tilaus saapuu ja tulostaa myös laskun kuriirille. Tämä yksinkertaistaa huomattavasti keittiön prosesseja, antaa työntekijöille mahdollisuuden olla häiritsemättä lukuisia yksinkertaisia ​​​​toimintoja.

• Toimitusyksiköstä tuli erillinen Delivery Checkout, jossa tilaus lähetettiin aiemmin vuorossa olleelle kuriirille. Hänen työaikansa otettiin huomioon palkanlaskennassa. 

Samaan aikaan vuosina 2012–2015 ilmestyi yli 10 kehittäjää, 35 pizzeriaa avattiin, otettiin käyttöön järjestelmän Romaniaan ja valmisteltiin myyntipisteiden avaamista Yhdysvalloissa. Kehittäjät eivät enää käsitelleet kaikkia tehtäviä, vaan heidät jaettiin ryhmiin. jokainen on erikoistunut omaan järjestelmän osaansa. 

Ongelmat

Mukaan lukien arkkitehtuurin takia (mutta ei vain).

Kaaos pohjassa

Yksi pohja on kätevä. Johdonmukaisuus voidaan saavuttaa siinä ja relaatiotietokantoihin rakennettujen työkalujen kustannuksella. Työskentely sen kanssa on tuttua ja kätevää, varsinkin jos taulukoita on vähän ja dataa on vähän.

Mutta neljän vuoden kehitystyön aikana tietokannassa osoittautui olevan noin 4 taulukkoa, 600 tallennettua menettelyä, joista monissa oli myös logiikkaa. Valitettavasti tallennetut menettelyt eivät tuota paljon etua työskennellessäsi MySQL:n kanssa. Tukiasema ei tallenna niitä välimuistiin, ja logiikan tallentaminen niihin vaikeuttaa kehitystä ja virheenkorjausta. Myös koodin uudelleenkäyttö on vaikeaa.

Monissa taulukoissa ei ollut sopivia indeksejä, jossain päinvastoin, indeksejä oli paljon, mikä vaikeutti lisäämistä. Jouduttiin muokkaamaan noin 20 taulukkoa - tapahtuma tilauksen luomiseksi kesti noin 3-5 sekuntia. 

Taulukoiden tiedot eivät aina olleet sopivimmassa muodossa. Jossain oli tarpeen tehdä denormalisointi. Osa säännöllisesti vastaanotetusta tiedosta oli XML-rakenteen muodossa olevassa sarakkeessa, mikä lisäsi suoritusaikaa, pidensi kyselyitä ja vaikeutti kehitystä.

Samoihin pöytiin tuotettiin hyvin heterogeeniset pyynnöt. Erityisesti suositut pöydät kärsivät, kuten yllä mainittu taulukko. määräys tai taulukoita pizzeria. Niitä käytettiin näyttämään keittiön käyttöliittymiä, analytiikkaa. Toinen sivusto otti heihin yhteyttä (dodopizza.ru), johon voi milloin tahansa yhtäkkiä tulla paljon pyyntöjä. 

Tietoja ei ole yhdistetty ja monet laskelmat tehtiin lennossa käyttäen tukikohtaa. Tämä aiheutti tarpeettomia laskelmia ja lisäkuormitusta. 

Usein koodi meni tietokantaan, kun se ei olisi voinut tehdä niin. Jossain bulkkioperaatioita ei ollut tarpeeksi, jossain olisi tarpeen jakaa yksi pyyntö useaan koodin kautta nopeuttamiseksi ja luotettavuuden lisäämiseksi. 

Koheesio ja hämärtyminen koodissa

Moduulit, joiden piti olla vastuussa omasta osasta liiketoimintaa, eivät tehneet sitä rehellisesti. Joillakin heistä oli päällekkäisiä tehtäviä rooleja varten. Esimerkiksi paikallinen markkinoija, joka vastaa verkoston markkinointitoiminnasta kaupungissaan, joutui käyttämään sekä "Admin"-käyttöliittymää (promootioiden luomiseen) että "Office Manager" -käyttöliittymää (nähdäkseen kampanjoiden vaikutusta liiketoimintaan). Tietenkin molemmissa moduuleissa käytettiin samaa palvelua, joka toimi bonuskampanjoiden kanssa.

Palvelut (luokat yhden monoliittisen suuren projektin sisällä) voisivat soittaa toisilleen rikastaakseen tietojaan.

Itse malliluokilla, jotka tallentavat tietoja, koodissa tehty työ tehtiin eri tavalla. Jossain oli rakentajia, joiden kautta oli mahdollista määrittää pakollisia kenttiä. Jossain tämä tehtiin julkisten kiinteistöjen kautta. Tietenkin tiedon saaminen ja muuntaminen tietokannasta oli vaihtelevaa. 

Logiikka oli joko ohjaimissa tai palveluluokissa. 

Nämä näyttävät olevan pieniä ongelmia, mutta ne hidastivat suuresti kehitystä ja heikensivät laatua, mikä johti epävakauteen ja virheisiin. 

Suuren kehityksen monimutkaisuus

Vaikeuksia ilmeni itse kehityksessä. Järjestelmästä piti tehdä erilaisia ​​lohkoja ja rinnakkain. Kunkin komponentin tarpeiden sovittaminen yhteen koodiin tuli yhä vaikeammaksi. Ei ollut helppoa olla samaa mieltä ja miellyttää kaikkia komponentteja samanaikaisesti. Tähän lisättiin tekniikan rajoituksia, erityisesti mitä tulee pohjaan ja käyttöliittymään. JQuerysta oli luopuminen korkean tason kehyksiä kohti, erityisesti asiakaspalvelujen (verkkosivusto) osalta.

Joissakin järjestelmän osissa voitaisiin käyttää tähän paremmin soveltuvia tietokantoja.. Esimerkiksi myöhemmin meillä oli käyttötapaus siirtyä Rediksestä CosmosDB:hen varastoimaan tilauskoria. 

Oman alansa tiimit ja kehittäjät halusivat selvästi enemmän itsenäisyyttä palveluilleen sekä kehityksen että käyttöönoton suhteen. Yhdistä konflikteja, vapauta ongelmia. Jos 5 kehittäjälle tämä ongelma on merkityksetön, niin 10:llä ja vielä enemmän suunnitellulla kasvulla kaikki muuttuisi vakavammaksi. Ja edessä oli mobiilisovelluksen kehittäminen (se alkoi vuonna 2017, ja vuonna 2018 se oli iso syksy). 

Järjestelmän eri osat vaativat erilaista vakautta, mutta järjestelmän vahvan liitettävyyden vuoksi emme voineet tarjota tätä. Virhe uuden toiminnon kehittämisessä admin-paneelissa saattoi hyvinkin tapahtua tilauksen hyväksymisessä sivustolla, koska koodi on yhteinen ja uudelleenkäytettävä, tietokanta ja tiedot ovat myös samat.

Tällaisen monoliittisesti modulaarisen arkkitehtuurin puitteissa nämä virheet ja ongelmat olisi todennäköisesti mahdollista välttää: tehdä vastuunjako, heijastaa sekä koodi että tietokanta, erottaa kerrokset selkeästi toisistaan, seurata laatua päivittäin. Mutta valitut arkkitehtoniset ratkaisut ja keskittyminen järjestelmän toiminnallisuuden nopeaan laajentamiseen johtivat vakavuusongelmiin.

Miten mielen voima -blogi laittoi ravintoloiden kassakoneet

Jos pizzeriaverkoston (ja kuormituksen) kasvu jatkuisi samaa vauhtia, niin putoukset olisivat hetken kuluttua sellaisia, ettei järjestelmä nousisi. Havainnollistaa hyvin ongelmia, joita aloimme kohdata vuoteen 2015 mennessä, tässä on tällainen tarina. 

Blogissa"Mielen voima” oli widget, joka näytti tietoja koko verkon vuoden liikevaihdosta. Widget käytti Dodo julkista APIa, joka tarjoaa nämä tiedot. Tämä tilasto on tällä hetkellä saatavilla osoitteessa http://dodopizzastory.com/. Widget näytettiin joka sivulla ja se teki ajastimella pyyntöjä 20 sekunnin välein. Pyyntö meni osoitteeseen api.dodopizza.ru ja pyysi:

• pizzerioiden lukumäärä verkossa;

• verkon kokonaistuotot vuoden alusta lähtien;

• tämän päivän tulot.

Tulotilastopyyntö meni suoraan tietokantaan ja aloitti tilaustietojen pyytämisen, tietojen kokoamisen lennossa ja määrän ilmoittamisen. 

Ravintoloiden kassat menivät samaan tilaustaulukkoon, purkivat tänään vastaanotettujen tilausten listan ja siihen lisättiin uusia tilauksia. Kassakoneet tekivät pyyntönsä 5 sekunnin välein tai sivun päivitys.

Kaavio näytti tältä:

Eräänä syksynä Fjodor Ovchinnikov kirjoitti pitkän ja suositun artikkelin blogiinsa. Monet ihmiset tulivat blogiin ja alkoivat lukea kaikkea huolellisesti. Kun jokainen tulija luki artikkelia, tulowidget toimi oikein ja pyysi API:ta 20 sekunnin välein.

API kutsui tallennetun prosessin laskeakseen kaikkien verkoston pizzerioiden kaikkien tilausten summan vuoden alusta. Aggregointi perustui tilaustaulukkoon, joka on erittäin suosittu. Kaikkien tuolloin avoinna olevien ravintoloiden kaikki kassat menevät siihen. Kassat lakkasivat vastaamasta, tilauksia ei otettu vastaan. Niitä ei myöskään hyväksytty sivustolta, ne eivät näkyneet jäljittimessä, vuoropäällikkö ei nähnyt niitä käyttöliittymässään. 

Tämä ei ole ainoa tarina. Syksyllä 2015 joka perjantai järjestelmän kuormitus oli kriittinen. Useita kertoja sammutimme julkisen API:n ja kerran jouduimme jopa sammuttamaan sivuston, koska mikään ei auttanut. Siellä oli jopa luettelo palveluista, joissa oli seisokkimääräys raskaan kuorman alla.

Tästä eteenpäin kamppailumme kuormien kanssa ja järjestelmän vakauttamiseksi alkaa (syksystä 2015 syksyyn 2018). Silloin se tapahtui"mahtava syksy". Lisäksi joskus tapahtui myös vikoja, joista osa oli erittäin herkkiä, mutta yleinen epävakausjakso voidaan nyt katsoa ohitetuksi.

Liiketoiminnan nopea kasvu

Miksi sitä ei voitu tehdä heti? Katso vain seuraavat kaaviot.

Myös vuosina 2014-2015 avajaiset olivat Romaniassa ja avajaisia ​​USA:ssa valmistellaan.

Verkosto kasvoi erittäin nopeasti, uusia maita avattiin, uusia pizzeriaformaatteja ilmestyi, esimerkiksi ruokasaliin avattiin pizzeria. Kaikki tämä vaati merkittävää huomiota erityisesti Dodo IS -toimintojen laajentamiseen. Ilman kaikkia näitä toimintoja, ilman seurantaa keittiössä, tuotteiden ja hävikkien kirjanpitoa järjestelmässä, tilauksen antamisen näyttämistä ruokasalissa, tuskin puhuisimme "oikeasta" arkkitehtuurista ja "oikeasta" lähestymistavasta kehitystä nyt.

Toinen este arkkitehtuurin oikea-aikaiselle uudistamiselle ja yleisesti teknisiin ongelmiin kiinnittämiselle oli vuoden 2014 kriisi. Tämänkaltaiset asiat vaikuttavat voimakkaasti tiimien kasvumahdollisuuksiin, erityisesti Dodo Pizzan kaltaiselle nuorelle yritykselle.

Nopeat ratkaisut, jotka auttoivat

Ongelmat vaativat ratkaisuja. Perinteisesti ratkaisut voidaan jakaa kahteen ryhmään:

• Nopeat, jotka sammuttavat palon ja antavat pienen turvamarginaalin ja antavat meille aikaa muuttua.

• Järjestelmällinen ja siksi pitkä. Useiden moduulien uudelleensuunnittelu, monoliittisen arkkitehtuurin jakaminen erillisiin palveluihin (useimmat eivät ole ollenkaan mikro-, vaan makropalveluita, ja siinä on jotain Andrei Morevskin raportti). 

Kuiva lista nopeista muutoksista on seuraava:

Skaalaa perusmestari

Tietenkin ensimmäinen asia, joka tehdään kuormituksen käsittelemiseksi, on lisätä palvelimen kapasiteettia. Tämä tehtiin päätietokannan ja web-palvelimien osalta. Valitettavasti tämä on mahdollista vain tiettyyn rajaan asti, jolloin siitä tulee liian kallista.

Vuodesta 2014 lähtien olemme muuttaneet Azureen, kirjoitimme aiheesta myös tuolloin artikkelissa "Kuinka Dodo Pizza toimittaa pizzaa Microsoft Azure Cloudin avulla". Mutta sen jälkeen, kun tukikohtaa oli lisätty useaan otteeseen, he kohtasivat kustannukset. 

Peruskopiot lukemista varten

Pohjalle tehtiin kaksi kopiota:

Lue Replika viitepyyntöjä varten. Sitä käytetään lukemaan hakemistoja, tyyppiä, kaupunkia, katua, pizzeria, tuotteita (hitaasti muuttunut verkkotunnus) ja niissä liitännöissä, joissa pieni viive on hyväksyttävä. Näitä replikoita oli 2 kpl, varmistimme niiden saatavuuden samalla tavalla kuin mestarit.

ReadReplica raporttipyyntöjä varten. Tämän tietokannan saatavuus oli heikompi, mutta kaikki raportit menivät siihen. Antakaa niille raskaita pyyntöjä valtavia tietojen uudelleenlaskentaa varten, mutta ne eivät vaikuta päätietokantaan ja käyttöliittymiin. 

Välimuistit koodissa

Koodissa ei ollut välimuistia missään (ei ollenkaan). Tämä johti ylimääräisiin, ei aina tarpeellisiin pyyntöihin ladatun tietokantaan. Välimuistit olivat ensin sekä muistissa että ulkoisessa välimuistipalvelussa, joka oli Redis. Kaikki mitätöi ajan, asetukset määritettiin koodissa.

Useita taustapalvelimia

Myös sovelluksen taustaosa piti skaalata lisääntyneen työmäärän käsittelemiseksi. Yhdestä iis-palvelimesta piti tehdä klusteri. Olemme muuttaneet aikataulua hakemusistunto muistista RedisCacheen, mikä mahdollisti useiden palvelimien tekemisen yksinkertaisen kuormituksen tasapainottimen taakse round robinilla. Aluksi käytettiin samaa Redistä kuin välimuistissa, sitten se jaettiin useisiin. 

Tämän seurauksena arkkitehtuuri on monimutkaistunut ...

… mutta osa jännityksestä poistui.

Ja sitten oli tarpeen tehdä ladatut komponentit uudelleen, minkä teimme. Puhumme tästä seuraavassa osassa.

Lähde: will.com