Porazdeljeni sistemi: kdaj jih morate sestaviti in kako določiti obseg. Navodila po korakih.

Fotografiral Jeremy McKnight na spletni strani Unsplash

Vedno me preseneti, koliko mlajših razvijalcev trpi za sindromom prevare, ko so začeli ustvarjati svoj izdelek.

Razumem, obstaja veliko osupljivih primerov vrhunskih podjetij z neverjetno zapletenimi razporejenimi sistemi, ki lahko rešijo več milijard zahtev, brezhibno nadgradijo na stotine aplikacij, se v nekaj sekundah opomorejo, izpustijo vsakih 60 minut in imajo hitrost svetlobe odzivni časi od koder koli na svetu.

Ta pričakovanja so lahko zelo presenetljiva, ko začenjate svoj projekt. A kot mnogi že veste, je večina teh podjetij začela z minimalnim sistemom preživetja in zelo slabim tehnološkim naborom. Za to obstaja preprost razlog: tega, ko so začeli, niso potrebovali. Poraba več časa za oblikovanje vašega sistema namesto kodiranja bi dejansko lahko povzročila, da ne uspete.

Ta članek je korak za korakom, kako voditi. Pokazal vam bom, kako smo v podjetju Visage začeli z najtanjšim sistemom doslej in zgradili osnovni razširljivi sistem z visoko razpoložljivostjo. To je resnična študija primera za odstranjevanje kompleksov, če še nikoli niste imeli priložnosti.

Ko sem prvič prišel v Visage kot CTO, sem bil edini inženir. Nisem vedel nič o tehnološkem paketu, vendar sem se pridružil, ker mi je bila zelo všeč ideja, da se lahko zaposlim brez lastnih kadrovalcev ali kadrovske službe. To je bila osnovna ideja Visage: množično ustvarjanje, ki ga poganja veliko nevidnih najemnikov, ki skupaj sodelujejo na vaših vlogah, ki jim pomaga umetna inteligenca, ki bi v nekaj dneh iskala najbolj primeren talent za vas. Potem sodelujete neposredno z njimi, noben srednji mož.

"Množica" v crowdfucingu je v trenutku sprožila moje inženirske možgane: veliko ljudi, ki delajo sočasno, pričakujejo dobre rezultate od kjer koli na svetu. Všeč mi je bil izziv.

Toda sistemsko modre, stvari so bile slabe, resnično slabe. To sem ugotovil ob prihodu:

  • Kompromitiran primerek Wordpress, ki poganja stotine zastarelih napačnih vtičnikov, deluje v VM-ju na skupnem strežniku
  • Kompromitirani nabiralniki
  • Sranje za Google Dokumente in preglednice.

In to je povsem normalno. Spet v ekipi ni bilo tehničnega člana in pričakoval sem kaj takega. Kljub temu se je ekipa osredotočila na poslovno priložnost in videla, da je izdelek deloval čarobno, medtem ko je vse delal ročno! (Ponarejajte, dokler ga ne naredite). In to je bilo res neverjetno.

Naš prvi sistem (Da, zanič je, vendar je delo opravil)!

Ne preseneča, da je bila moja prva naloga ponovno ustvariti VM, znova namestiti posodobljeno različico Wordpressa, poskrbeti, da bodo vsi spremenili gesla, določili pravilnik o geslih in odstranili na desetine zlonamerne programske opreme v računalnikih podjetja ... ampak preidimo na sistemske premisleke.

Od Wordpressa do spletne aplikacije

Vaš prvi fokus, ko začnete graditi izdelek, morajo biti podatki. Podatki so tisto, kar prinaša vrednost vašega podjetja. To bo tisto, kar vsak dan uporabljate za sprejemanje odločitev, in tisto, kar pokažete svojim vlagateljem, da dokažejo napredek.

Svoje podatke morate imeti smiselne, zato vam bo odvzem podatkov iz različnih virov z različnimi formati pomenil veliko izgubo časa. Wordpress je lahko v mnogih primerih zelo dobra izbira, saj prihrani precej inženirskega časa, toda za svoje potrebe je morala ekipa Visage namestiti domišljijske vtičnike, ki niso več vzdrževani. Kot rezultat tega nismo imeli nadzora nad ustvarjenim modelom podatkov, podatki, ki niso mogli ustrezati modelu, pa so bili razpršeni po več deset dokumentov in preglednic.

Torej, če tam ni izdelka, ki bi že ustrezal 90% vaših potreb, razmislite o idealnem podatkovnem modelu in zasnovi ter uvedite minimalno uporaben izdelek (MVP), ki bo lahko hranil vse vaše podatke.

Nato pomislite na API. Vaša aplikacija mora imeti API, ključnega pomena bo, ko ga boste na koncu prodali. Ne povečajte takoj, vendar ga označite s prilagodljivostjo. Naj bo vaš API brez državljanstva in čim bolj RESTful, saj bodo vsi pričakovali, da ga bodo lahko poizvedovali po standardnih metodah HTTP.

V našem primeru smo izbrali NodeJS, saj bi večina naše kode ravno obdelala vhode in izhode. NodeJS ne blokira in ima knjižnico, ki je primerna za oblikovanje API-jev: ExpressJS.

Če potrebujete spletno stran s strankami, imate več možnosti. Najprej lahko v aplikacijskem strežniku ustvarite sloj, ki bo ustvaril vaše strani, ali pa sestavite aplikacijo JavaScript na eni strani, ki jo bo stregel statični strežnik spletnega gostovanja.

V Visageu smo se podali na drugo možnost in se odločili, da bomo ustvarili eno aplikacijo za uporabnike in eno za skrbnike. To je bilo preprosto zato, ker bi imeli veliko večja pričakovanja do uporabnikov, kot smo jih potrebovali pri skrbnikih, in želeli smo ohraniti obe zbirki baz enostavnih (tudi pozneje zaradi premislekov CORS). Tako je izgledal naš sistem:

Vsi podatki na enem mestu

Zgodaj prenesite občutljivo shranjevanje podatkov

Če ni ključnega pomena za vaše podjetje, ni pravega razloga za shranjevanje občutljivih osebnih podatkov v vaše sisteme. Varnost je zapletena zadeva, in če vsakodnevno spreminjate kodo, dokler ne ugotovite, da je vaš izdelek ustrezen, se bo zlomil. Predpostavimo, da bi kdo naklepno lahko kršil vašo prijavo, če bi si to res želel.

Ključno pri tem je, da ne hranite nobenih podatkov, ki bi za hekerja hitro dobili. Nihče ne oropa banke, ki nima denarja. Če oblikujete izdelek SaaS, verjetno potrebujete avtentikacijo in spletno plačilo. Obstaja veliko tretjih oseb, s katerimi se lahko vključite, ki se bodo s tem ukvarjali na veliko boljši način, kot bi morda lahko.

Na primer, Auth0 je najbolj znana tretja oseba, ki upravlja avtentikacijo. Stripe je tudi dobra možnost za spletno plačevanje. Vse svoje vire in najboljše varnostne inženirske ekipe na planetu bodo namenili za varovanje vaših podatkov - ali pa nimajo posla.

Dejanski znak na avtomobilu v San Franciscu

Storitve v oblaku so vaši najboljši prijatelji

Na tej točki smo imeli način, kako shraniti vse naše podatke, avtentikacijo, spletno plačilo in spletno aplikacijo, ki bi jo lahko stranke uporabljale skupaj z API-jem, ki bi ga lahko prodali partnerjem za različne primere uporabe. Naša uporabniška baza je rasla in postalo je očitno, da želijo kadar koli dostopati do aplikacije. Torej je bil čas za razmislek o razširljivosti in razpoložljivosti.

Zanašali smo se na en strežnik, vendar je lahko obravnaval le toliko zahtev, menjava strežnikov ali izdaja nove različice pa bi pomenila, da se aplikacija sprosti med izdajo. Naslednje prednostne naloge so bile: izravnava obremenitve, samodejno skaliranje, beleženje, podvajanje in samodejne varnostne kopije. Seveda, če ste edini inženir v svojem podjetju, bi poskušali sami rešiti vsa ta vprašanja, bi bila popolna norost.

Na srečo živimo v času, ko lahko samo en dobro zaobljen inženir z lahkoto zgradi tak sistem v nekaj dneh z uporabo storitev v oblaku, kot so Amazon Web Services, Google Cloud Services ali Azure. Odločili smo se, da bomo svoje sisteme preselili v AWS, ker je bila takrat najbolj popolna rešitev in smo imeli dve leti brezplačnih kreditov.

Zato bom v tej objavi večinoma govoril o rešitvah AWS, na drugih platformah pa obstajajo enakovredne storitve. To je tudi čas, ko smo se odločili, da bomo začeli z izvajanjem svojih modulov v Docker posodah iz številnih drugih razlogov, ki ne bodo zajeti v tej objavi (ta članek si lahko ogledate za več informacij: https://medium.freecodecamp.org / amazon-fargate-zbogom-infrastruktura-3b66c7e3e413).

Kako se boste odločili za zagon aplikacij, je res odvisno od primera uporabe, kot je potrebna prilagodljivost in čas, ki ga lahko porabite za upravljanje svoje infrastrukture.

Ni dobrega ali slabega odgovora.

Izberete lahko, da posodobite vse svoje module in uporabite sistem za upravljanje vsebnikov, kot sta ECS / EKS v AWS ali Kubernetesov motor v GCP. Če ne in se nočete sami ukvarjati s stvarmi, kot sta samodejno skaliranje in uravnavanje obremenitve, lahko uporabite Elastic Beanstalk ali App Engine.

Če želite polno strežnika brez strežnika, lahko uporabite tudi Lambda funkcije in API Gateway. Odločili smo se za ECS. Razporedili smo 3 primerke na treh območjih razpoložljivosti, sredstvo za uravnavanje obremenitve, nastavitev samodejnega skaliranja, odvisno od uporabe procesorja, integrirali vse dnevnike naših zabojnikov z Cloudwatchom in nastavitvenimi metrikami za gledanje napak, zunanjih klicev in odzivnega časa API-ja.

Velika razpoložljivost: Ste vedeli, da žirafe skoraj nikoli ne spijo? 99% podaljška

Za našo zbirko podatkov smo uporabili MongoDB, ker je naš model dobro primeren za bazo podatkov NoSQL in njegova visoka doslednost. Odločili smo se, da bomo izkoristili MongoDB Atlas in uporabili 3 replike, da smo omogočili visoko razpoložljivost. Med drugimi storitvami Atlas ponuja samodejno spreminjanje, avtomatsko varnostno kopiranje in vam omogoča, da se v primeru nesreče brez težav vrnete v čas.

Odločili smo se tudi, da bomo gostili vse naše statične spletne datoteke v S3 in uporabljali Cloudfront kot CDN, tako da se naše aplikacije JS lahko zelo hitro naložijo kjer koli na svetu in nam jih lahko postrežejo tolikokrat, kot je zahtevano. Cloudflare je tudi dobra možnost in nudi DDOS zaščito izven škatle.

Zaradi poenostavitve smo se odločili, da bomo uporabili Route 53 kot naš DNS z uporabo njihovih imenskih strežnikov za vse naše domene. To je ena izmed mojih najljubših storitev na AWS. To vam olajša življenje. Vsakič, ko želite nekaj uporabiti prek imena domene, pa naj bo to primer EC2, elastični IP, uravnotežilec obremenitve, distribucija Cloudfront ali kaj drugega, zasebno ali javno, vam vzame nekaj minut, ker je tako dobro povezan z vsemi druge storitve.

To združite z upraviteljem potrdil, ki vam omogoča, da v nekaj minutah brezplačno dobite SSL certifikate (vključeni nadomestni znaki) in jih namestite na vse svoje strežnike tako, da potrdite polje, in imate najhitrejši in najbolj zanesljiv način, kako omogočiti HTTPS na vseh svojih modulih. Zbogom "Šifrirajmo" potrdila SSL, ki sem jih morala obnavljati in nameščati na svoje strežnike vsake 3 mesece ali tako .

Začeti videti spodobno

Odločite se za strategijo predpomnjenja

Vsi sovražijo upravljanje predpomnjenja, predpomnjenje se lahko zgodi na več različnih slojih, težave s predpomnilnikom pa je težko reproducirati in nočna mora odpraviti napake.

Žal se učinkovitost distribuiranih sistemov močno opira na dobro strategijo predpomnjenja. Obstaja veliko dobrih člankov o dobrih strategijah predpomnjenja, zato se ne bom spuščal v podrobnosti. Samo vedite, da če so vaši statistični viri v spletu težki, boste verjetno želeli izkoristiti predpomnilnik svojega brskalnika, tako da spretno uporabite glavo predpomnilnika.

Če se obrnjene strani vašega uporabnika ustvarjajo na aplikacijskih strežnikih znova in znova, uporabite predpomnilnik proxy, kot je Squid. Najpomembneje pa je, da obstaja velika verjetnost, da boste vsakič znova in znova pošiljali iste zahteve v svojo bazo podatkov. Če želite zmanjšati obremenitev baze podatkov in prihraniti čas prenosa podatkov, uporabite sistem za predpomnjenje pomnilniških predmetov, kot je shranjen za predmete, ki se pogosto uporabljajo in redko posodabljajo.

Začeli smo razmišljati o uporabi memcacheda, ker smo pogosto znova in znova zahtevali iste iskalne profile in ponudbe za zaposlitev. Z uporabo na pomnilniško optimiziranem stroju smo povečali uspešnost API-ja za več kot 30%, ko povprečno odmerimo vse odzivne čase na dan. Memcached je razporejen tudi tako, da lahko deluje na različnih strežnikih, vendar kljub temu deluje kot da je le en velik pomnilniški prostor za shranjevanje predmetov.

predpomnilnik, predpomnilnik povsod

Lokacija, lokacija, lokacija

Zdaj imamo porazdeljen sistem, ki nima niti ene točke napake (če upoštevate AWS ELBs in porazdeljeni memcached) in lahko samodejno spreminja velikost navzgor in navzdol. Predpomnilnik uporabljamo tudi za zmanjšanje omrežnih prenosov. Izgleda precej dobro. V tistem trenutku boste verjetno radi pregledali svoje tretje osebe, da bi videli, ali bodo prevzeli tovor tako kot vi.

A kljub temu so se nekateri naši uporabniki pritoževali, da je aplikacija zanje nekoliko počasnejša, še posebej pri nalaganju datotek. Tudi če so naše statične spletne datoteke predpomnjene po vsem svetu (z dovoljenjem CDN), so bili vsi naši aplikacijski strežniki nameščeni samo na zahodu ZDA. Uporabniki iz vzhodne Azije so imeli veliko več zamud, zlasti za velike prenose podatkov.

Rešitev je bila enostavna: namestite popolnoma isto skupino ECS na novo regijo v Aziji skupaj z novim izravnalnikom obremenitve in se zanesite na pot 53. Geoproxicity Routing, da uporabnike usmerite do »najbližjega« regulatorja obremenitve. MongoDB Atlas vam omogoča tudi, da svoje replike razporedite po regijah, tako da ni bilo potrebno dodatno delo.

In tu smo! Naš porazdeljeni sistem je pripravljen.

Zaključek

Medtem ko je bil distribucijski sistem, ki ga vidite tukaj, za to objavo poenostavljen, smo pregledali dele, ki jih najverjetneje vidite v številnih sodobnih spletnih aplikacijah. Druge teme, ki so povezane z, vendar niso zajete, so arhitektura mikroservisov, shranjevanje datotek in šifriranje, strjevanje baze podatkov, načrtovana opravila, asinhrono vzporedno računanje… morda v naslednji objavi!

Moje glavno mnenje je: ne zaženite zgraditi popolnega sistema, ko zaženete svoj izdelek. Večina vaših oblikovalskih odločitev bo temeljila na tem, kaj vaš izdelek počne in kdo ga uporablja. Vedeli boste le, da ko dosežete tržno ponudbo izdelkov in začnete imeti dober pregled nad svojo uporabniško bazo, in to lahko traja mesece, leta.

Osredotočite se na ugotovitev, kaj ljudje potrebujejo, in poskusite najti rešitev za njihovo težavo, tudi če ima veliko ročnih korakov. Nato razmislite o načinih avtomatizacije, porabite čas za kodiranje in uničevanje ter uporabite tretje osebe, kjer je to smiselno.

Ne merite, ampak vedno razmišljajte, kodirajte in načrtujte velikost. Korak za korakom gradite sistem, ne lotevajte se vprašanja zasnove sistema na podlagi funkcij, ki še niso zrele, in na koncu vedno poskusite najti najboljše kompromise med časom, ki ga boste porabili, in dobičkom v učinkovitosti, denarju in nižjimi tveganje.

Če vam je bil ta članek všeč in se vam je zdel uporaben, pritisnite ta gumb in spremljajte me za več člankov o arhitekturi in razvoju!