Hei Habr!

Koronaviruksen aiheuttamien ajankohtaisten tapahtumien valossa useat verkkopalvelut ovat alkaneet saada lisää kuormitusta. Esimerkiksi, Yksi Yhdistyneen kuningaskunnan vähittäiskauppaketjuista yksinkertaisesti lopetti online-tilaussivustonsa., koska kapasiteetti ei riittänyt. Eikä aina ole mahdollista nopeuttaa palvelinta yksinkertaisesti lisäämällä tehokkaampia laitteita, mutta asiakkaiden pyynnöt on käsiteltävä (tai ne menevät kilpailijoille).

Tässä artikkelissa kerron lyhyesti suosituista käytännöistä, joiden avulla voit luoda nopean ja vikasietoisen palvelun. Mahdollisista kehityssuunnitelmista valitsin kuitenkin vain ne, jotka ovat tällä hetkellä helppokäyttöinen. Jokaiselle kohteelle sinulla on joko valmiit kirjastot tai sinulla on mahdollisuus ratkaista ongelma pilvialustan avulla.

Vaakasuora skaalaus

Yksinkertaisin ja tunnetuin kohta. Perinteisesti kaksi yleisintä kuormanjakomallia ovat vaaka- ja pystyskaalaus. Ensimmäisessä tapauksessa annat palveluiden toimia rinnakkain ja jaat siten kuorman niiden välillä. Toisessa tilaat tehokkaampia palvelimia tai optimoit koodin.

Otan esimerkiksi abstraktin pilvitallennustilan, toisin sanoen jonkin analogisen OwnCloudin, OneDriven ja niin edelleen.

Alla on vakiokuva tällaisesta piiristä, mutta se osoittaa vain järjestelmän monimutkaisuuden. Loppujen lopuksi meidän on jotenkin synkronoitava palvelut. Mitä tapahtuu, jos käyttäjä tallentaa tiedoston tabletista ja haluaa sitten tarkastella sitä puhelimella?

Lähestymistapojen ero: pystyskaalauksessa olemme valmiita lisäämään solmujen tehoa ja vaakasuuntaisessa skaalauksessa olemme valmiita lisäämään uusia solmuja jakamaan kuormitusta.

CQRS

Komentokyselyn vastuun erottelu Melko tärkeä malli, koska sen avulla eri asiakkaat voivat muodostaa yhteyden eri palveluihin, mutta myös vastaanottaa samoja tapahtumavirtoja. Sen edut eivät ole niin ilmeisiä yksinkertaisessa sovelluksessa, mutta se on erittäin tärkeä (ja yksinkertainen) kiireiselle palvelulle. Sen ydin: saapuvat ja lähtevät tietovirrat eivät saa risteä. Eli et voi lähettää pyyntöä ja odottaa vastausta, vaan lähetät pyynnön palveluun A, mutta vastaanotat vastauksen palvelulta B.

Tämän lähestymistavan ensimmäinen bonus on kyky katkaista yhteys (sanan laajassa merkityksessä) suoritettaessa pitkää pyyntöä. Otetaan esimerkiksi enemmän tai vähemmän standardi sekvenssi:

1. Asiakas lähetti pyynnön palvelimelle.
2. Palvelin aloitti pitkän käsittelyajan.
3. Palvelin vastasi asiakkaalle tuloksella.

Kuvitellaan, että kohdassa 2 yhteys katkesi (tai verkko yhdistettiin uudelleen tai käyttäjä meni toiselle sivulle katkaisemalla yhteyden). Tässä tapauksessa palvelimen on vaikea lähettää käyttäjälle vastausta siitä, mitä tarkalleen käsiteltiin. CQRS:ää käytettäessä järjestys on hieman erilainen:

1. Asiakas on tilannut päivitykset.
2. Asiakas lähetti pyynnön palvelimelle.
3. Palvelin vastasi "pyyntö hyväksytty".
4. Palvelin vastasi tuloksella kanavan kautta pisteestä "1".

Kuten näet, järjestelmä on hieman monimutkaisempi. Lisäksi intuitiivinen pyyntö-vastaus -lähestymistapa puuttuu tästä. Kuten näet, yhteyden katkeaminen pyynnön käsittelyn aikana ei kuitenkaan johda virheeseen. Lisäksi, jos käyttäjä itse asiassa on yhteydessä palveluun usealta laitteelta (esimerkiksi matkapuhelimesta ja tabletista), voit varmistaa, että vastaus tulee molemmille laitteille.

Mielenkiintoista on, että saapuvien viestien käsittelykoodista tulee sama (ei 100 %) sekä tapahtumille, joihin asiakas itse vaikutti, että muille tapahtumille, mukaan lukien muiden asiakkaiden tapahtumat.

Todellisuudessa saamme kuitenkin lisäbonuksen, koska yksisuuntainen virtaus voidaan käsitellä toiminnallisesti (käyttämällä RX:tä ja vastaavia). Ja tämä on jo vakava plus, koska pohjimmiltaan sovellus voidaan tehdä täysin reaktiiviseksi ja myös toiminnallista lähestymistapaa käyttämällä. Rasvojen ohjelmien osalta tämä voi säästää merkittävästi kehitys- ja tukiresursseja.

Jos yhdistämme tämän lähestymistavan horisontaaliseen skaalaukseen, niin bonuksena saamme mahdollisuuden lähettää pyyntöjä yhdelle palvelimelle ja vastaanottaa vastauksia toiselta. Näin asiakas voi valita itselleen sopivan palvelun ja sisällä oleva järjestelmä pystyy silti käsittelemään tapahtumia oikein.

Tapahtuman hankinta

Kuten tiedätte, yksi hajautetun järjestelmän pääpiirteistä on yhteisen ajan, yhteisen kriittisen osan puuttuminen. Yhdelle prosessille voit tehdä synkronoinnin (samoilla mutexeilla), jonka sisällä olet varma, että kukaan muu ei suorita tätä koodia. Tämä on kuitenkin vaarallista hajautetulle järjestelmälle, koska se vaatii ylimääräisiä kustannuksia ja myös tappaa kaiken skaalauksen kauneuden - kaikki komponentit odottavat silti yhtä.

Tästä saamme tärkeän tosiasian - nopeasti hajautettua järjestelmää ei voida synkronoida, koska silloin heikennämme suorituskykyä. Toisaalta tarvitsemme usein tiettyä johdonmukaisuutta komponenttien välillä. Ja tähän voit käyttää lähestymistapaa lopullinen johdonmukaisuus, jossa taataan, että jos tiedoissa ei tapahdu muutoksia jonkin aikaa viimeisen päivityksen jälkeen ("lopulta"), kaikki kyselyt palauttavat viimeksi päivitetyn arvon.

On tärkeää ymmärtää, että klassisissa tietokannoissa sitä käytetään melko usein vahva johdonmukaisuus, jossa jokaisella solmulla on samat tiedot (tämä saavutetaan usein, jos tapahtuma katsotaan toteutuneeksi vasta toisen palvelimen vastauksen jälkeen). Eristäytymistasoista johtuen täällä on jonkin verran rentoutumista, mutta yleinen ajatus pysyy samana - voit elää täysin harmonisoidussa maailmassa.

Palataan kuitenkin alkuperäiseen tehtävään. Jos osa järjestelmästä voidaan rakentaa lopullinen johdonmukaisuus, voimme rakentaa seuraavan kaavion.

Tämän lähestymistavan tärkeitä ominaisuuksia:

• Jokainen saapuva pyyntö asetetaan yhteen jonoon.
• Pyyntöä käsitellessään palvelu voi asettaa tehtäviä myös muihin jonoihin.
• Jokaisella saapuvalla tapahtumalla on tunniste (joka on välttämätön duplikoinnin poistamiseksi).
• Jono toimii ideologisesti "liitä vain" -mallin mukaan. Et voi poistaa elementtejä siitä tai järjestää niitä uudelleen.
• Jono toimii FIFO-kaavan mukaan (anteeksi tautologia). Jos sinun on suoritettava rinnakkainen suoritus, sinun tulee yhdessä vaiheessa siirtää objektit eri jonoihin.

Haluan muistuttaa, että harkitsemme online-tiedostojen tallennusta. Tässä tapauksessa järjestelmä näyttää suunnilleen tältä:

On tärkeää, että kaavion palvelut eivät välttämättä tarkoita erillistä palvelinta. Jopa prosessi voi olla sama. Toinen asia on tärkeä: ideologisesti nämä asiat on erotettu toisistaan ​​niin, että vaakasuora skaalaus on helppo soveltaa.

Ja kahdelle käyttäjälle kaavio näyttää tältä (eri käyttäjille tarkoitetut palvelut on merkitty eri väreillä):

Bonukset tällaisesta yhdistelmästä:

• Tietojenkäsittelypalvelut on erotettu toisistaan. Myös jonot on erotettu toisistaan. Jos meidän on lisättävä järjestelmän suorituskykyä, meidän on vain käynnistettävä enemmän palveluita useammille palvelimille.
• Kun saamme tietoja käyttäjältä, meidän ei tarvitse odottaa, kunnes tiedot on tallennettu kokonaan. Päinvastoin, meidän täytyy vain vastata "ok" ja sitten alkaa vähitellen työskennellä. Samalla jono tasoittaa huippuja, koska uuden kohteen lisääminen tapahtuu nopeasti, eikä käyttäjän tarvitse odottaa täydellistä läpikulkua koko syklin läpi.
• Esimerkkinä lisäsin päällekkäisyyden poistopalvelun, joka yrittää yhdistää identtiset tiedostot. Jos se toimii pitkään 1%:ssa tapauksista, asiakas tuskin huomaa sitä (katso yllä), mikä on iso plussa, koska meiltä ei enää vaadita XNUMX% nopeutta ja luotettavuutta.

Haitat näkyvät kuitenkin heti:

• Järjestelmämme on menettänyt tiukan johdonmukaisuuden. Tämä tarkoittaa, että jos esimerkiksi tilaat erilaisia ​​palveluita, voit teoriassa saada toisen tilan (koska yksi palveluista ei välttämättä ehdi vastaanottamaan ilmoitusta sisäisestä jonosta). Toisena seurauksena järjestelmällä ei ole nyt yhteistä aikaa. Eli on mahdotonta esimerkiksi lajitella kaikkia tapahtumia yksinkertaisesti saapumisajan mukaan, koska palvelimien väliset kellot eivät välttämättä ole synkronisia (lisäksi sama aika kahdella palvelimella on utopiaa).
• Mitään tapahtumia ei voi nyt yksinkertaisesti peruuttaa (kuten voitaisiin tehdä tietokannan kanssa). Sen sijaan sinun on lisättävä uusi tapahtuma − korvaustapahtuma, joka muuttaa viimeisen tilan vaadituksi. Esimerkkinä samanlaiselta alueelta: ilman historian uudelleenkirjoittamista (mikä on joissain tapauksissa huonoa) et voi peruuttaa gitissä tehtyä sitoumusta, mutta voit tehdä erityisen peruutussitoumus, joka käytännössä vain palauttaa vanhan tilan. Sekä virheellinen sitoutuminen että peruuttaminen jäävät kuitenkin historiaan.
• Tietoskeema voi muuttua julkaisusta toiseen, mutta vanhoja tapahtumia ei voida enää päivittää uuteen standardiin (koska tapahtumia ei periaatteessa voi muuttaa).

Kuten näet, tapahtuman hankinta toimii hyvin CQRS:n kanssa. Lisäksi järjestelmän toteuttaminen tehokkailla ja kätevillä jonoilla, mutta ilman tietovirtojen erottamista, on jo sinänsä vaikeaa, koska joudut lisäämään synkronointipisteitä, jotka neutraloivat jonojen koko positiivisen vaikutuksen. Käyttäen molempia lähestymistapoja kerralla, on tarpeen säätää hieman ohjelmakoodia. Meidän tapauksessamme lähetettäessä tiedostoa palvelimelle vastaus tulee vain "ok", mikä tarkoittaa vain, että "tiedoston lisäystoiminto on tallennettu". Muodollisesti tämä ei tarkoita, että tiedot olisivat jo saatavilla muissa laitteissa (esimerkiksi kopioiden purkupalvelu voi rakentaa indeksin uudelleen). Jonkin ajan kuluttua asiakas saa kuitenkin ilmoituksen, jonka tyyli on "tiedosto X on tallennettu".

Tuloksena:

• Tiedostojen lähetystilojen määrä kasvaa: perinteisen "tiedosto lähetetty" sijaan saamme kaksi: "tiedosto on lisätty palvelimen jonoon" ja "tiedosto on tallennettu varastoon". Jälkimmäinen tarkoittaa, että muut laitteet voivat jo alkaa vastaanottaa tiedostoa (joita on säädetty sillä, että jonot toimivat eri nopeuksilla).
• Koska lähetystiedot tulevat nyt eri kanavien kautta, meidän on keksittävä ratkaisuja tiedoston käsittelyn tilan vastaanottamiseksi. Tämän seurauksena: toisin kuin klassisessa pyyntö-vastauksessa, asiakas voidaan käynnistää uudelleen tiedoston käsittelyn aikana, mutta itse käsittelyn tila on oikea. Lisäksi tämä tuote toimii pohjimmiltaan pakkauksesta käsin. Seurauksena: olemme nyt suvaitsevaisempia epäonnistumisia kohtaan.

Sharding

Kuten edellä on kuvattu, tapahtuman hankintajärjestelmiltä puuttuu tiukka johdonmukaisuus. Tämä tarkoittaa, että voimme käyttää useita tallennusvälineitä ilman synkronointia niiden välillä. Lähestyessämme ongelmaamme voimme:

• Erottele tiedostot tyypin mukaan. Esimerkiksi kuvia/videoita voidaan purkaa ja tehokkaampi formaatti voidaan valita.
• Erilliset tilit maittain. Monien lakien vuoksi tämä saattaa olla tarpeen, mutta tämä arkkitehtuurimalli tarjoaa tällaisen mahdollisuuden automaattisesti

Jos haluat siirtää tietoja tallennustilasta toiseen, tavalliset keinot eivät enää riitä. Valitettavasti tässä tapauksessa sinun on pysäytettävä jono, suoritettava siirto ja aloitettava se. Yleensä dataa ei voi siirtää "lennossa", mutta jos tapahtumajono on tallennettu kokonaan ja sinulla on tilannekuvia aiemmista tallennustiloista, voimme toistaa tapahtumat seuraavasti:

• Tapahtumalähteessä jokaisella tapahtumalla on oma tunniste (mieluiten ei-laskeva). Tämä tarkoittaa, että voimme lisätä tallennustilaan kentän - viimeksi käsitellyn elementin id:n.
• Monistamme jonon, jotta kaikki tapahtumat voidaan käsitellä useille itsenäisille tallennusvälineille (ensimmäinen on se, johon tiedot on jo tallennettu, ja toinen on uusi, mutta vielä tyhjä). Toista jonoa ei tietenkään vielä käsitellä.
• Käynnistämme toisen jonon (eli alamme toistaa tapahtumia).
• Kun uusi jono on suhteellisen tyhjä (eli elementin lisäämisen ja noutamisen välinen keskimääräinen aikaero on hyväksyttävä), voit aloittaa lukijoiden vaihtamisen uuteen tallennustilaan.

Kuten näette, järjestelmässämme ei ollut eikä ole edelleenkään tiukkaa johdonmukaisuutta. On olemassa vain mahdollinen johdonmukaisuus, eli takuu siitä, että tapahtumat käsitellään samassa järjestyksessä (mutta mahdollisesti eri viiveillä). Ja tätä käyttämällä voimme suhteellisen helposti siirtää tietoja pysäyttämättä järjestelmää toiselle puolelle maapalloa.

Jatkamme siis esimerkkiämme tiedostojen online-tallennustilasta, tällainen arkkitehtuuri tarjoaa jo meille useita bonuksia:

• Voimme siirtää esineitä lähemmäksi käyttäjiä dynaamisella tavalla. Näin voit parantaa palvelun laatua.
• Saatamme tallentaa joitakin tietoja yritysten sisällä. Esimerkiksi yrityskäyttäjät vaativat usein tietojensa tallentamista valvottuihin tietokeskuksiin (tietovuotojen välttämiseksi). Shardingin avulla voimme helposti tukea tätä. Ja tehtävä on vielä helpompi, jos asiakkaalla on yhteensopiva pilvi (esim. Azure itseisännöity).
• Ja mikä tärkeintä, meidän ei tarvitse tehdä tätä. Loppujen lopuksi olisimme aluksi melko tyytyväisiä yhteen tallennustilaan kaikille tileille (jotta voisimme aloittaa työskentelyn nopeasti). Ja tämän järjestelmän pääominaisuus on, että vaikka se on laajennettavissa, se on alkuvaiheessa melko yksinkertainen. Sinun ei vain tarvitse heti kirjoittaa koodia, joka toimii miljoonan erillisen itsenäisen jonon kanssa jne. Tarvittaessa tämä voidaan tehdä tulevaisuudessa.

Staattisen sisällön hosting

Tämä kohta voi tuntua melko ilmeiseltä, mutta se on silti välttämätön enemmän tai vähemmän tavalliselle ladatulle sovellukselle. Sen olemus on yksinkertainen: kaikkea staattista sisältöä ei jaeta samalta palvelimelta, jossa sovellus sijaitsee, vaan erityisiltä, ​​​​että tätä tehtävää varten. Tämän seurauksena nämä toiminnot suoritetaan nopeammin (ehdollinen nginx palvelee tiedostoja nopeammin ja halvemmalla kuin Java-palvelin). Plus CDN-arkkitehtuuri (Content Delivery Network) antaa meille mahdollisuuden paikantaa tiedostomme lähemmäs loppukäyttäjiä, millä on positiivinen vaikutus palvelun kanssa työskentelyn mukavuuteen.

Yksinkertaisin ja tavallisin esimerkki staattisesta sisällöstä on joukko skriptejä ja kuvia verkkosivustoa varten. Kaikki on yksinkertaista heidän kanssaan - ne tunnetaan etukäteen, sitten arkisto ladataan CDN-palvelimille, josta ne jaetaan loppukäyttäjille.

Todellisuudessa staattisen sisällön osalta voit kuitenkin käyttää lähestymistapaa, joka on hieman samanlainen kuin lambda-arkkitehtuuri. Palataan tehtäväämme (online-tiedostojen tallennus), jossa meidän on jaettava tiedostoja käyttäjille. Yksinkertaisin ratkaisu on luoda palvelu, joka tekee jokaisen käyttäjän pyynnöstä kaikki tarvittavat tarkistukset (valtuutus jne.) ja lataa sitten tiedoston suoraan varastostamme. Tämän lähestymistavan suurin haittapuoli on, että staattista sisältöä (ja tietyllä versiolla varustettu tiedosto on itse asiassa staattista sisältöä) jakaa sama palvelin, joka sisältää liiketoimintalogiikan. Sen sijaan voit tehdä seuraavan kaavion:

• Palvelin tarjoaa lataus-URL-osoitteen. Se voi olla muotoa file_id + key, jossa avain on pieni digitaalinen allekirjoitus, joka antaa oikeuden käyttää resurssia seuraavan XNUMX tunnin ajan.
• Tiedostoa jakaa yksinkertainen nginx seuraavilla vaihtoehdoilla:
  • Sisällön välimuisti. Koska tämä palvelu voi sijaita erillisellä palvelimella, olemme jättäneet itsellemme varauksen tulevaisuutta varten, jossa on mahdollisuus tallentaa kaikki uusimmat ladatut tiedostot levylle.
  • Tarkistetaan avainta yhteyden luomisen yhteydessä
• Valinnainen: suoratoistosisällön käsittely. Jos esimerkiksi pakkaamme kaikki palvelun tiedostot, voimme purkaa sen suoraan tässä moduulissa. Seurauksena: IO-toiminnot tehdään siellä, missä ne kuuluvat. Java-arkistointiohjelma varaa helposti paljon ylimääräistä muistia, mutta liiketoimintalogiikkapalvelun uudelleenkirjoittaminen Rust/C++-ehtoihin voi myös olla tehotonta. Meidän tapauksessamme käytetään erilaisia ​​prosesseja (tai jopa palveluita), joten voimme varsin tehokkaasti erottaa liiketoimintalogiikan ja IO-toiminnot.

Tämä menetelmä ei ole kovin samanlainen kuin staattisen sisällön jakaminen (koska emme lataa koko staattista pakettia jonnekin), mutta todellisuudessa tämä lähestymistapa koskee nimenomaan muuttumattoman datan jakamista. Lisäksi tämä menetelmä voidaan yleistää muihin tapauksiin, joissa sisältö ei ole vain staattista, vaan se voidaan esittää muuttumattomien ja ei-poistettavien lohkojen joukkona (vaikka niitä voidaan lisätä).

Toinen esimerkki (vahvistukseksi): jos olet työskennellyt Jenkinsin/TeamCityn kanssa, tiedät, että molemmat ratkaisut on kirjoitettu Java-kielellä. Molemmat ovat Java-prosesseja, jotka hoitavat sekä rakentamisen orkestroinnin että sisällönhallinnan. Erityisesti niillä molemmilla on tehtäviä, kuten "siirrä tiedosto/kansio palvelimelta". Esimerkkinä: artefaktien myöntäminen, lähdekoodin siirto (kun agentti ei lataa koodia suoraan arkistosta, vaan palvelin tekee sen hänen puolestaan), pääsy lokeihin. Kaikki nämä tehtävät eroavat IO-kuormituksestaan. Toisin sanoen käy ilmi, että monimutkaisesta liiketoimintalogiikasta vastaavan palvelimen on samalla kyettävä työntää tehokkaasti läpi suuria tietovirtoja. Ja mikä mielenkiintoisinta on, että tällainen toiminto voidaan delegoida samalle nginxille täsmälleen saman järjestelmän mukaisesti (paitsi että tietoavain pitäisi lisätä pyyntöön).

Jos kuitenkin palaamme järjestelmäämme, saamme samanlaisen kaavion:

Kuten näette, järjestelmästä on tullut radikaalisti monimutkaisempi. Nyt se ei ole vain miniprosessi, joka tallentaa tiedostoja paikallisesti. Nyt ei vaadita yksinkertaisinta tukea, API-version hallintaa jne. Siksi, kun kaikki kaaviot on piirretty, on parasta arvioida yksityiskohtaisesti, onko laajennettavuus hintansa arvoinen. Jos kuitenkin haluat laajentaa järjestelmää (mukaan lukien työskennellä entistä suuremman käyttäjien määrän kanssa), sinun on valittava samanlaisia ​​ratkaisuja. Mutta sen seurauksena järjestelmä on arkkitehtonisesti valmis lisääntyneeseen kuormitukseen (melkein jokainen komponentti voidaan kloonata vaakasuuntaista skaalausta varten). Järjestelmä voidaan päivittää pysäyttämättä sitä (vain jotkin toiminnot hidastuvat hieman).

Kuten alussa sanoin, nyt useat Internet-palvelut ovat alkaneet saada lisää kuormitusta. Ja jotkut heistä alkoivat yksinkertaisesti lakata toimimasta oikein. Itse asiassa järjestelmät epäonnistuivat juuri sillä hetkellä, kun yrityksen piti tehdä rahaa. Toisin sanoen järjestelmä sanoi yksinkertaisesti "mene kilpailijoille" sen sijaan, että se ehdottaisi asiakkaille "suunnittele toimitusta tuleville kuukausille" lykätyn toimituksen sijaan. Itse asiassa tämä on alhaisen tuottavuuden hinta: tappioita syntyy juuri silloin, kun voitot olisivat suurimmat.

Johtopäätös

Kaikki nämä lähestymistavat tunnettiin aiemmin. Sama VK on pitkään käyttänyt Static Content Hosting -ideaa kuvien näyttämiseen. Monet verkkopelit käyttävät Sharding-järjestelmää pelaajien jakamiseen alueisiin tai pelipaikkojen erottamiseen (jos maailma itse on sellainen). Event Sourcing -lähestymistapaa käytetään aktiivisesti sähköpostissa. Suurin osa kaupankäyntisovelluksista, joissa tietoja vastaanotetaan jatkuvasti, on itse asiassa rakennettu CQRS-lähestymistapalle, jotta vastaanotetut tiedot voidaan suodattaa. No, vaakaskaalausta on käytetty monissa palveluissa jo pitkään.

Mutta mikä tärkeintä, kaikista näistä kuvioista on tullut erittäin helppo soveltaa nykyaikaisissa sovelluksissa (jos ne ovat tietysti sopivia). Pilvet tarjoavat Shardingin ja horisontaalisen skaalauksen heti, mikä on paljon helpompaa kuin tilata itse erilaisia ​​dedikoituja palvelimia eri palvelinkeskuksiin. CQRS:stä on tullut paljon helpompaa, jos vain RX:n kaltaisten kirjastojen kehityksen vuoksi. Noin 10 vuotta sitten harvinainen verkkosivusto saattoi tukea tätä. Event Sourcing on myös uskomattoman helppo asentaa Apache Kafkan valmiiden konttien ansiosta. 10 vuotta sitten tämä olisi ollut innovaatio, nyt se on arkipäivää. Sama pätee staattisen sisällön isännöintiin: kätevämpien teknologioiden ansiosta (mukaan lukien se, että on olemassa yksityiskohtainen dokumentaatio ja laaja tietokanta vastauksia), tämä lähestymistapa on tullut entistä yksinkertaisemmiksi.

Tämän seurauksena useiden melko monimutkaisten arkkitehtonisten kuvioiden toteuttamisesta on nyt tullut paljon yksinkertaisempaa, mikä tarkoittaa, että on parempi tarkastella sitä tarkemmin etukäteen. Jos kymmenen vuotta vanhassa sovelluksessa jompikumpi yllä olevista ratkaisuista hylättiin korkean toteutus- ja käyttökustannusten vuoksi, voit nyt uudessa sovelluksessa tai refaktoroinnin jälkeen luoda palvelun, joka on jo arkkitehtonisesti sekä laajennettavissa ( suorituskyvyn kannalta) ja valmiina asiakkaiden uusiin pyyntöihin (esimerkiksi henkilötietojen lokalisointiin).

Ja mikä tärkeintä: älä käytä näitä lähestymistapoja, jos sinulla on yksinkertainen sovellus. Kyllä, ne ovat kauniita ja mielenkiintoisia, mutta 100 ihmisen huippuvierailupaikalla pärjää usein klassisella monoliitilla (ainakin ulkopuolelta kaikki sisällä voidaan jakaa moduuleiksi jne.).

Lähde: will.com