Hajautetut järjestelmät: milloin sinun pitäisi rakentaa ne, ja miten mitoitus. Vaiheittainen opas.

Kuva Jeremy McKnight on Unsplash

Minua huomaa aina, kuinka moni nuorempi kehittäjä kärsii huijareiden oireyhtymästä, kun he alkoivat luoda tuotteitaan.

Saan sen, että on olemassa monia mielenkiintoisia esimerkkejä huippuyrityksistä, joilla on uskomattoman monimutkaisia ​​hajautettuja järjestelmiä, jotka voivat käsitellä miljardeja pyyntöjä, päivittää satoja sovelluksia tyylikkäästi ilman seisokkeja, toipua katastrofista sekunneissa, vapauttaa 60 minuutin välein ja saada aikaan nopeuden vastausajat mistä päin maailmaa tahansa.

Nämä odotukset voivat olla melko ylivoimaisia, kun aloitat projektisi. Mutta kuten monet teistä jo tietävät, suurin osa näistä yrityksistä on aloittanut minimaalisen elinkelpoisella järjestelmällä ja erittäin huonolla tekniikkapinoilla. Tähän on yksinkertainen syy: he eivät tarvinnut sitä aloittaessaan. Jos järjestelmän suunnitteluun kulutetaan enemmän aikaa koodauksen sijasta, se saattaa aiheuttaa epäonnistumisen.

Tämä artikkeli on vaihe vaiheelta kuinka opastaa. Näytän sinulle, kuinka Visagessa aloitimme kaikkien aikojen pienimmästä järjestelmästä ja rakensimme perusvarusteena saatavuuden skaalautuvan hajautetun perusjärjestelmän. Tämä on todellinen tapaustutkimus komplekseidesi poistamiseksi, jos sinulla ei ole koskaan ollut mahdollisuutta tehdä sitä itse.

Kun saavuin Visageen ensimmäisen kerran CTO: na, olin ainoa insinööri. En tiennyt mitään tech-pinosta, mutta liittyin, koska pidin todella ajatuksesta, että voisin rekrytoida ilman sisäisiä rekrytoijia tai HR-palvelua. Tämä oli Visagen ydinajatus: joukkotuhoaminen, jota saavat paljon näkymättömiä rekrytoijia, jotka työskentelevät yhdessä rooliesi parissa ja jota avustaa keinotekoinen äly, joka etsisi sinulle sopivinta kykyä sinulle muutamassa päivässä. Sitten olette tekemisissä suoraan heidän kanssaan, ei keskimmäistä miestä.

Joukkotutkimuksen "väkijoukko" laukaisi heti insinöörini: siellä on paljon ihmisiä, jotka työskentelevät samanaikaisesti ja odottavat hyviä suorituksia mistä päin maailmaa tahansa. Pidin haasteesta.

Mutta järjestelmällisesti, asiat olivat huonoja, todella huonoja. Tämän löysin saapuessani:

  • Vaarannettu Wordpress-ilmentymä, joka käyttää satoja vanhentuneita virheellisiä laajennuksia, jotka toimivat jaetulla palvelimella olevassa VM: ssä
  • Vaaralliset postilaatikot
  • Roska tonni Google-dokumentteja ja laskentataulukoita.

Ja tämä on täysin normaalia. Jälleen kerran, joukkueessa ei ollut teknistä jäsentä, ja olin odottanut jotain tällaista. Silti joukkue oli keskittynyt liiketoimintamahdollisuuteen ja saanut tuotteen vaikuttamaan taianomaisesti tekevän kaiken käsin! (Väärennä se kunnes teet sen). Ja se oli todella hämmästyttävää.

Ensimmäinen järjestelmämme (Kyllä, se imi, mutta se teki työn)!

Ei ole yllättävää, että ensimmäisenä tehtävänäni oli luoda virtuaalikommentti uudelleen, asentaa päivitetty Wordpress-versio uudelleen, varmistaa, että kaikki vaihtavat salasanansa, vahvistaa salasanasäännöt ja poistaa kymmeniä haittaohjelmia yrityksen tietokoneilta ... mutta siirrymme sitten järjestelmään liittyviin näkökohtiin.

Wordpressista verkkosovellukseen

Ensimmäisen painopisteen, kun aloitat tuotteen rakentamisen, on oltava tietoja. Tiedot ovat se, mikä lisää yrityksesi arvoa. Se on se, mitä käytät päivittäin päätöksenteossa, ja se, mitä näytät sijoittajillesi edistyksen osoittamiseksi.

Tietojen on oltava järkevää, ja tietojen palauttaminen eri lähteistä eri muodoissa on aikaa vievää tuhlausta. Wordpress voi olla erittäin hyvä valinta monissa tapauksissa säästämällä melko paljon suunnitteluaikaa, mutta heidän tarpeisiinsa Visage-tiimin oli asennettava hienoja laajennuksia, joita ei enää ylläpidetty. Seurauksena oli, että meillä ei ollut hallintaa luodusta datamallista, ja tiedot, jotka eivät mahdu malliin, hajallaan kymmeniin asiakirjoihin ja laskentataulukoihin.

Joten ellei siellä ole tuotetta, joka sopii jo 90% tarpeisiisi, ajattele ihanteellista tietomallia ja suunnittele ja ota käyttöön vähimmäiskykyinen tuote (MVP), joka pystyy pitämään kaikki tietosi.

Ajattele sitten API. Sovelluksellasi on oltava sovellusliittymä. Se tulee olemaan kriittinen, kun lopulta myyt sen. Älä skaalaa heti, mutta koodaa skaalautuvuuden mielessä. Tee sovellusliittymästäsi valtioton ja niin RESTful kuin mahdollista, koska kaikki odottavat pystyvänsä kysymään sitä tavallisilla HTTP-menetelmillä.

Valitsimme tapauksessamme NodeJS, koska suurin osa koodistamme käsittelisi vain tuloja ja lähtöjä. NodeJS ei estä, ja sen mukana tulee kirjasto, joka on kätevä suunnitella sovellusliittymiä: ExpressJS.

Jos tarvitset asiakaskohtaisia ​​verkkosivustoja, sinulla on useita vaihtoehtoja. Ensin voit luoda sovelluspalvelimelle tason, joka tuottaa sivusi, tai voit rakentaa Yhden sivun Javascript-sovelluksen, jota staattinen web-palvelin palvelee.

Visagessa me valitsimme toisen vaihtoehdon ja päätimme luoda yhden sovelluksen käyttäjille ja yhden järjestelmänvalvojille. Tämä johtui yksinkertaisesti siitä, että meillä olisi paljon suurempia odotuksia käyttäjille kuin mitä tarvitsimme ylläpitäjien kanssa, ja halusimme pitää molemmat koodipohjat yksinkertaisina (myös CORS-huomioista myöhemmin). Tämä näytti järjestelmältämme:

Kaikki tiedot yhdessä paikassa

Siirrä arkaluonteisen tiedon varastointi varhain

Ellei se ole kriittistä yrityksellesi, ei ole syytä tallentaa arkaluonteisia henkilötietoja järjestelmiin. Suojaus on monimutkainen asia, ja jos muutat koodiasi päivittäin, kunnes löydät tuotemarkkinat sopivaksi, se rikkoutuu. Oletetaan, että kuka tahansa huonosti tarkoitettu voi rikkoa hakemuksesi, jos he todella haluavat.

Tärkeää tässä on, ettei hallussa ole tietoja, jotka olisivat hakkereiden nopea voitto. Kukaan ei ryöstä pankkia, jolla ei ole rahaa. Jos suunnittelet SaaS-tuotetta, tarvitset todennäköisesti todennuksen ja online-maksun. On paljon kolmansia osapuolia, joihin voit integroida ja jotka käsittelevät sitä paljon paremmalla tavalla kuin mahdollista.

Esimerkiksi Auth0 on tunnetuin kolmas osapuoli, joka käsittelee todennusta. Raita on myös hyvä vaihtoehto verkkomaksuihin. He omistavat kaikki voimavaransa ja maapallon parhaat tietotekniikkatiimit tietojen pitämiseksi turvassa - tai heillä ei ole yritystä.

Varsinainen merkki autossa san Franciscossa

Pilvipalvelut ovat parhaita ystäviäsi

Joten tässä vaiheessa meillä oli tapa tallentaa kaikki tietomme, todennus, online-maksut ja verkkosovellus, jota asiakkaat voivat käyttää, yhdessä sovellusliittymän kanssa, jota voimme myydä kumppaneille erilaisissa käyttötapauksissa. Käyttäjäkuntamme kasvoi ja kävi ilmeiseksi, että he halusivat pääsyn sovellukseen milloin tahansa. Joten oli aika miettiä skaalautuvuudesta ja saatavuudesta.

Luotimme yhteen palvelimeen, mutta se pystyi käsittelemään vain niin monia pyyntöjä, ja palvelimien vaihtaminen tai uuden version julkaiseminen tarkoittaisi sovelluksen poistamista julkaisun aikana. Seuraava painopistealueemme olivat: kuormituksen tasapainotus, automaattinen skaalaaminen, kirjaaminen, toisintaminen ja automatisoidut varmuuskopiot. Tietysti, jos olet yrityksesi ainoa insinööri, yrittää puuttua kaikkiin näihin asioihin yksin olisi täydellinen hulluus.

Elämme onneksi ajalla, jolloin vain yksi hyvin pyöristetty insinööri voi helposti rakentaa tällaisen järjestelmän muutamassa päivässä käyttämällä pilvipalveluita, kuten Amazon Web Services, Google Cloud Services tai Azure. Päätimme siirtää järjestelmämme AWS: ään, koska se oli tuolloin kaikkein täydellisin ratkaisu ja meillä oli 2 vuotta ilmaisia ​​krediittejä.

Tästä syystä aion lähinnä puhua AWS-ratkaisuista tässä viestissä, mutta muilla alustoilla on vastaavia palveluita. Tänä aikana olemme myös päättäneet aloittaa moduulien ajamisen Docker-säilöissä monista muista syistä, joita ei käsitellä tässä viestissä (lisätietoja saat artikkelista: https://medium.freecodecamp.org / Amazon-fargate-näkemiin-infrastruktuuri-3b66c7e3e413).

Se, kuinka päätät käyttää sovelluksiasi, riippuu todella käyttökohteestasi, kuten tarvitsemasi joustavuus verrattuna siihen aikaan, jonka voit käyttää infrastruktuurin hallintaan.

Ei ole hyvää tai huonoa vastausta.

Voit valita, että säilytät kaikki moduulit ja käyttää säilönhallintajärjestelmää, kuten ECS / EKS AWS: ssä tai Kubernetes-moottoria GCP: ssä. Jos ei ja et halua itse käsitellä esimerkiksi automaattista skaalausa ja kuorman tasapainotusta, voit käyttää Elastic Beanstalk- tai App Engine -sovellusta.

Jos haluat mennä täydelliseksi palvelimettomaksi, voit myös yhdistää Lambda-toimintojen ja API-yhdyskäytävän käytön. Päätimme mennä ECS: hen. Käyttöönotimme 3 tapausta kolmella saatavuusvyöhykkeellä, kuormituksen tasapainottajalle, automaattisen skaalauksen asettamiselle prosessorin käytöstä riippuen, integroimme kaikki konttien lokit Cloudwatchiin ja asennusmetriikoihin virheiden, ulkoisten puheluiden ja API-vastausajan seuraamiseksi.

Korkea saatavuus: Tiesitkö, että kirahveja melkein ei koskaan nukku? 99% käyttöaika

Tietokannassamme käytimme MongoDB: tä, koska mallimme sopii hyvin NoSQL-tietokantaan ja sen korkeaan johdonmukaisuuteen. Päätimme hyödyntää MongoDB Atlas -sovellusta ja otimme käyttöön 3 kopioita korkean saatavuuden mahdollistamiseksi. Muiden palvelujen joukossa Atlas tarjoaa automaattisen skaalauksen, automatisoidut varmuuskopiot ja antaa sinun palata ajassa saumattomasti katastrofitilanteissa.

Päätimme myös isännöidä kaikkia staattisia verkkotiedostojamme S3: ssa ja käytimme Cloudfrontia CDN-muodossa, jotta JS-sovelluksemme latautuvat erittäin nopeasti kaikkialle maailmaan ja niitä voidaan palvella niin monta kertaa kuin pyydetään. Cloudflare on myös hyvä vaihtoehto ja tarjoaa DDOS-suojan laatikosta.

Yksinkertaisuuden vuoksi päätimme käyttää Route 53: aa DNS: nämme käyttämällä heidän nimipalvelintaan kaikissa verkkotunnuksissamme. Tämä on yksi suosikki palveluni AWS: llä. Se tekee elämästäsi paljon helpompaa. Aina kun haluat palvella jotain verkkotunnuksen kautta, on se sitten EC2-ilmentymää, joustavaa IP: tä, kuormituksen tasapainottajaa, Cloudfront-jakelua tai jotain todella, yksityisesti tai julkisesti, se vie minuutteja, koska se on niin hyvin integroitu kaikkiin muut palvelut.

Yhdistä tämä varmennehallintaohjelmaan, jonka avulla voit saada SSL-varmenteita (mukana jokerimerkit) ilmaiseksi muutamassa minuutissa ja ottaa ne käyttöön kaikilla palvelimillasi napsauttamalla ruutua. Sinulla on nopein ja luotettavin tapa ottaa HTTPS käyttöön kaikissa moduuleissa. Hyvä "Let 's Encrypt" SSL-varmenteet, jotka minun piti uusia ja asentaa palvelimilleni noin joka kolmas kuukausi .

Alkaa näyttää kunnolliselta

Päätä välimuististrategia

Kaikki vihaavat välimuistin hallintaa, välimuisti voi tapahtua monilla eri tasoilla, ja välimuistiin liittyviä ongelmia on vaikea toistaa, ja painajainen on korjattava.

Valitettavasti hajautettujen järjestelmien suorituskyky riippuu suuresti hyvästä välimuististrategiasta. Hyvistä välimuististrategioista on monia hyviä artikkeleita, joten en aio mennä yksityiskohtiin. Vain tiedä, että jos staattiset Web-resurssit ovat raskaita, haluat todennäköisesti hyödyntää käyttäjän selaimen välimuistia hyödyntämällä taitavasti välimuistin hallintaotsikkoa.

Jos käyttäjän sivut, jotka ilmestyvät sovelluspalvelimilla, uudestaan ​​ja uudestaan, käytä välimuistipalvelinta, kuten Squid. Mutta mikä tärkeintä, on suuri mahdollisuus, että teet samat pyynnöt tietokantaasi yhä uudelleen. Voit vähentää tietokannan kuormitusta ja säästää tiedonsiirtoaikaa käyttämällä muistiobjektien välimuistijärjestelmää, kuten tallennettua kohteisiin, joita käytetään usein ja päivitetään harvoin.

Aluksemme harkita muistion käyttämistä, koska pyysimme usein samoja ehdokasprofiileja ja työtarjouksia yhä uudelleen. Sen käyttöönotto muistioptimoidulla koneella lisäsi API-suorituskykyämme yli 30%, kun keskiarvotamme kaikki pyyntöjen vastausajat päivässä. Memcached on myös jaettu, joten se voi toimia eri palvelimilla, mutta toimii silti kuin se, että se on vain yksi iso muistitila objekteillesi.

välimuisti, välimuisti kaikkialla

Sijainti, sijainti, sijainti

Nyt meillä on hajautettu järjestelmä, jossa ei ole yhtä virhekohta (jos otat huomioon AWS ELB: t ja hajautettu muisti), ja se voi skaalata automaattisesti ylös ja alas. Käytä välimuistia myös minimoidaksesi verkon tiedonsiirrot. Näyttää aika hyvältä. Tässä vaiheessa haluat todennäköisesti tarkastaa kolmannet osapuolet nähdäksesi, imevätkö ne kuorman yhtä hyvin kuin sinä.

Mutta silti jotkut käyttäjistämme valittivat sovelluksen olevan hiukan hitaampi heille, etenkin kun he lähettivät tiedostoja. Tosiaankin, vaikka staattiset verkkotiedostomme olisivat tallennettu välimuistiin kaikkialla maailmassa (CDN: n suosituksella), kaikki sovelluspalvelimemme olivat käytössä vain Yhdysvaltojen länsipuolella. Itä-Aasian käyttäjillä oli huomattavasti enemmän viivettä etenkin suurten tiedonsiirtojen yhteydessä.

Ratkaisu oli helppo: ota täsmälleen sama ECS-klusteri uudelle Aasian alueelle yhdessä uuden kuormituksen tasapainottajan kanssa ja luota Route 53: n geoproximity-reititykseen käyttäjien reitittämiseksi “lähimpään” kuormituksen tasapainottajaan. MongoDB Atlas antaa sinun myös käyttää kopioita alueiden välillä, joten lisätyötä ei tarvita.

Ja tässä me olemme! Hajautettu järjestelmämme on valmis.

johtopäätös

Vaikka täällä näkemääsi hajautettua järjestelmää on yksinkertaistettu tähän viestiin, tutkimme niitä osia, jotka todennäköisimmin näet monissa nykyaikaisissa verkkosovelluksissa. Muita aiheita, joita ei käsitellä, ovat mikropalveluarkkitehtuuri, tiedostojen tallennus ja salaus, tietokannan varjostus, ajoitetut tehtävät, asynkroninen rinnakkaislaskenta… ehkä seuraavassa viestissä!

Tärkein huomautukseni on: älä yritä rakentaa täydellistä järjestelmää, kun aloitat tuotteesi. Suurinta osaa suunnitteluvalinnoista ohjaa se, mitä tuotteesi tekee ja kuka sitä käyttää. Tiedät vain, että kun saavut tuotemarkkinoille sopivuuden ja alat saada hyvän yleiskatsauksen käyttäjäkannastasi, ja se voi viedä kuukausia, jopa vuosia.

Keskity selvittämään, mitä ihmiset tarvitsevat, ja yritä löytää ratkaisu heidän ongelmaansa, vaikka siinä olisi paljon manuaalisia vaiheita. Mieti sitten tapoja automatisoida, viettää aikaa koodaamiseen ja tuhoamiseen ja käyttää kolmansia osapuolia siellä, missä se on järkevää.

Älä mittakaavaa, mutta aina miettiä, koodata ja suunnitella skaalaus. Suunnittele järjestelmäsi askel askeleelta, älä käsittele järjestelmän suunnittelukysymyksiä ominaisuuksien perusteella, jotka eivät ole vielä kypsiä, ja yritä lopulta löytää paras vaihtoehtosi vietetyn ajan ja suorituskyvyn, rahan ja alennetun hyötyn välillä riski.

Jos pidit tästä artikkelista ja pidit siitä jotain hyödyllistä, paina kyseistä napituspainiketta ja seuraa minua saadaksesi lisää arkkitehtuuri- ja kehitysartikkeleita!