Izkliedētās sistēmas: kad jums tās būtu jāveido un kā mērogot. Soli pa solim.

Jeremy McKnight foto vietnē Unsplash

Man vienmēr pārsteidz, cik daudz jaunāko izstrādātāju cieš no impostoru sindroma, kad viņi sāka radīt savu produktu.

Es to saprotu, ir daudz pārdomāto labāko uzņēmumu piemēru ar neticami sarežģītām izkliedētām sistēmām, kas var apmierināt miljardiem pieprasījumu, graciozi jaunināt simtiem lietojumprogrammu bez jebkādas dīkstāves, dažu sekunžu laikā atgūties no katastrofas, atbrīvot ik pēc 60 minūtēm un panākt nelielu ātrumu reakcijas laiki no jebkuras vietas pasaulē.

Šīs cerības var būt diezgan milzīgas, kad sākat savu projektu. Bet, kā daudzi no jums jau zina, vairums šo uzņēmumu ir sākuši ar minimālu dzīvotspējīgu sistēmu un ļoti sliktu tehnoloģiju paketi. Tam ir vienkāršs iemesls: kad viņi sāka, viņiem tas nebija vajadzīgs. Pavadot vairāk laika sistēmas projektēšanai kodēšanas vietā, tas faktiski var izraisīt jūsu neveiksmi.

Šis raksts ir soli pa solim, kā vadīt. Es jums parādīšu, kā vietnē Visage mēs sākām ar visu laiku smalkāko sistēmu un izveidojām pamata augstas pieejamības mērogojamu izplatīto sistēmu. Šis ir reāls gadījuma pētījums, lai noņemtu savus kompleksus, ja jums nekad nav bijusi iespēja to izdarīt pats.

Kad es pirmo reizi ierados Visage kā CTO, es biju vienīgais inženieris. Es neko nezināju par tehnoloģiju paketi, bet pievienojos, jo man ļoti patika ideja par iespēju pieņemt darbiniekus bez iekšējiem vervētājiem vai personāla atlases dienesta. Šī bija Visage galvenā ideja: pūļa meklēšana, ko darbina daudz neredzamu vervētāju, kas strādā kopā pie jūsu lomām, palīdz mākslīgais intelekts, kas dažu dienu laikā meklēs jums vispiemērotāko talantu. Tad jūs iesaistāties tieši ar viņiem, nav vidēja cilvēka.

“Pūlis” sabiedriskās domas meklējumos uzreiz iedarbināja manas inženierijas smadzenes: būs daudz cilvēku, kas strādā vienlaikus, gaidot labu sniegumu no jebkuras vietas pasaulē. Man patika izaicinājums.

Bet sistēmā gudri, lietas bija sliktas, patiesi sliktas. Šis ir tas, ko es atklāju, ierodoties:

  • Apdraudēts Wordpress eksemplārs, kurā darbojas simtiem novecojušu kļūdainu spraudņu, kas darbojas virtuālā mašīnā uz koplietota servera
  • Kompromitētas pastkastes
  • Neveiksmīgs daudzums Google dokumentu un izklājlapu.

Un tas ir pilnīgi normāli. Atkal komandā nebija neviena tehniskā dalībnieka, un es biju gaidījis kaut ko līdzīgu. Tomēr komanda bija pievērsusies biznesa iespējai un likusi produktam šķist, ka tas maģiski darbojas, vienlaikus visu darot manuāli! (Viltot, kamēr jūs to pagatavojat). Un tas bija patiešām pārsteidzoši.

Mūsu pirmā sistēma (Jā, tā iesūcās, bet paveica darbu)!

Nav pārsteigums, ka mans pirmais uzdevums bija no jauna izveidot VM, pārinstalēt atjauninātu Wordpress versiju, pārliecināties, vai visi maina savas paroles, izveido paroļu politiku un noņem desmitiem ļaunprogrammatūru uzņēmuma datoros ... bet pāriesim pie sistēmas apsvērumiem.

No Wordpress līdz tīmekļa lietojumprogrammai

Pirmajai uzmanībai, kad sākat veidot produktu, jābūt datiem. Dati ir tas, kas nosaka jūsu uzņēmuma vērtību. Tas būs tas, ko jūs ikdienā izmantojat lēmumu pieņemšanai, un tas, ko jūs parādīsit ieguldītājiem, lai parādītu progresu.

Jums ir jāizprot savi dati, un datu dublēšana no dažādiem avotiem ar dažādiem formātiem būs milzīga laika tērēšana. Wordpress daudzos gadījumos var būt ļoti laba izvēle, ietaupot diezgan daudz inženierijas laika, taču viņu vajadzībām Visage komandai bija jāinstalē iedomāti spraudņi, kas vairs netiek uzturēti. Rezultātā mums nebija iespējas kontrolēt ģenerēto datu modeli, un dati, kas nevarēja būt piemēroti modelim, tika izkaisīti desmitiem dokumentu un izklājlapu.

Tātad, ja vien nav kāda produkta, kas jau atbilst 90% jūsu vajadzībām, padomājiet par ideālu datu modeli un noformējiet un ieviesiet minimālo dzīvotspējīgo produktu (MVP), kas spēs glabāt visus jūsu datus.

Tad padomājiet par API. Jūsu lietojumprogrammai ir jābūt API, tā būs kritiska, kad galu galā to pārdosit. Neveiciet tūlītēju mērogu, bet kodējiet, ņemot vērā mērogojamību. Padariet savu API bezvalstnieku un pēc iespējas atjaunotāku, jo visi gaidīs, ka varēs to uzdot, izmantojot standarta HTTP metodes.

Mēs šajā gadījumā izvēlējāmies NodeJS, jo lielākā daļa mūsu koda būtu tikai ieeju un izeju apstrāde. NodeJS nav bloķējošs, un tas nāk ar bibliotēku, kuru ir ērti veidot API: ExpressJS.

Ja jums nepieciešama vietne, ar kuru saskaras klients, jums ir vairākas iespējas. Vispirms lietojumprogrammu serverī varat izveidot slāni, kas ģenerēs jūsu lapas, vai arī varat izveidot vienotās lapas Javascript lietojumprogrammu, kuru apkalpos statisks tīmekļa mitināšanas serveris.

Vietnē Visage mēs izvēlējāmies otro iespēju un nolēmām izveidot vienu lietojumprogrammu lietotājiem un vienu administratoriem. Tas bija vienkārši tāpēc, ka mums būtu daudz lielākas cerības uz lietotājiem, nekā mums vajadzēja ar administratoriem, un mēs vēlējāmies saglabāt abas kodeksa bāzes vienkāršas (arī CORS apsvērumiem vēlāk). Šādi izskatījās mūsu sistēma:

Visi dati vienā vietā

Deleģējiet sensitīvu datu glabāšanu jau agri

Ja tas nav kritisks jūsu biznesam, nav pamatota iemesla slepenu personas datu glabāšanai savās sistēmās. Drošība ir sarežģīts jautājums, un, ja jūs katru dienu modificējat savu kodu, līdz atrodat savu produktu tirgu piemērotu, tas sabojāsies. Pieņemsim, ka ikviens, kas nav domājis, varētu pārkāpt jūsu pieteikumu, ja viņi patiešām to vēlētos.

Šeit galvenais ir nevis turēt datus, kas hakeram būtu ātra uzvara. Neviens neaplaupa banku, kurai nav naudas. Ja jūs izstrādājat SaaS produktu, jums, iespējams, nepieciešama autentifikācija un tiešsaistes maksājums. Ir daudz trešo personu, kuras varat integrēt un kas ar to nodarbosies daudz labāk, nekā jūs, iespējams, varētu.

Piemēram, Auth0 ir vispazīstamākā trešā puse, kas apstrādā autentifikāciju. Svītra ir arī laba iespēja tiešsaistes maksājumiem. Viņi veltīs visus savus resursus un labākās planētas drošības tehnikas komandas, lai jūsu dati būtu droši - vai viņiem nav uzņēmuma.

Faktiska zīme uz automašīnas Sanfrancisko

Mākonis pakalpojumi ir tavi labākie draugi

Tātad šajā brīdī mums bija veids, kā saglabāt visus mūsu datus, autentifikāciju, tiešsaistes maksājumus un tīmekļa lietotni, ko klienti varēja izmantot, kopā ar API, kuru mēs varētu pārdot partneriem dažādiem lietošanas gadījumiem. Mūsu lietotāju skaits auga, un kļuva acīmredzams, ka viņi vēlas piekļūt lietotnei jebkurā laikā. Tāpēc bija laiks domāt par mērogojamību un pieejamību.

Mēs paļāvāmies uz vienu serveri, taču tas varēja apstrādāt tikai tik daudz pieprasījumu, un serveru maiņa vai jaunas versijas izlaišana nozīmētu programmas noņemšanu izlaišanas laikā. Nākamās mūsu prioritātes bija: slodzes līdzsvarošana, automātiska mērogošana, reģistrēšana, atkārtošana un automatizētas rezerves kopijas. Protams, ja jūs esat vienīgais inženieris jūsu uzņēmumā, mēģināt visus šos jautājumus risināt pats par sevi būtu pilnīgs neprāts.

Par laimi mēs dzīvojam laikā, kad tikai viens labi noapaļots inženieris var viegli izveidot šādu sistēmu pāris dienu laikā, izmantojot mākoņa pakalpojumus, piemēram, Amazon Web Services, Google Cloud Services vai Azure. Mēs nolēmām pārcelt savas sistēmas uz AWS, jo tajā laikā tas bija vispilnīgākais risinājums, un mums bija 2 gadu bezmaksas kredīti.

Tāpēc šajā amatā es galvenokārt runāšu par AWS risinājumiem, taču citās platformās ir līdzvērtīgi pakalpojumi. Šis ir arī laiks, kad mēs izvēlējāmies sākt darbināt mūsu moduļus Docker konteineros daudz dažādu citu iemeslu dēļ, kas netiks apskatīti šajā ierakstā (lai iegūtu vairāk informācijas, skatiet šo rakstu: https://medium.freecodecamp.org / amazon-fargate-goodbye-infrastruktūra-3b66c7e3e413).

Tas, kā jūs nolemjat palaist savas lietojumprogrammas, patiešām ir atkarīgs no izmantošanas gadījuma, piemēram, no nepieciešamās elastības salīdzinājumā ar laiku, ko varat pavadīt savas infrastruktūras pārvaldīšanai.

Nav ne labas, ne sliktas atbildes.

Varat izvēlēties visus moduļus konteineros un izmantot tādu konteineru pārvaldības sistēmu kā ECS / EKS AWS vai Kubernetes motoru GCP. Ja nē un jūs nevēlaties pats risināt tādas lietas kā automātiska mērogošana un slodzes līdzsvarošana, varat izmantot Elastic Beanstalk vai App Engine.

Ja vēlaties darboties pilnībā bez servera, varat arī apvienot Lambda funkciju un API vārtejas izmantošanu. Mēs nolēmām doties uz ECS. Mēs izvietojām 3 gadījumus 3 pieejamības zonās, slodzes līdzsvarotāju, iestatītu automātisko mērogošanu atkarībā no CPU izmantošanas, integrējām visus konteineru žurnālus ar Cloudwatch un iestatīšanas metriku, lai skatītos kļūdas, ārējos zvanus un API reakcijas laiku.

Augsta pieejamība: vai jūs zinājāt, ka žirafes gandrīz nekad negulē? 99% uptime

Savā datu bāzē mēs izmantojām MongoDB, jo mūsu modelis ir piemērots gan NoSQL datu bāzei, gan tās augstajai konsekvencei. Mēs nolēmām izmantot MongoDB Atlas un izmantojām 3 kopijas, lai nodrošinātu augstu pieejamību. Citu pakalpojumu starpā Atlas nodrošina automātisku mērogošanu, automatizētas dublējumkopijas un ļauj katastrofas gadījumā nemanāmi atgriezties laikā.

Mēs arī nolēmām visus savus statiskos tīmekļa failus S3 mitināt un izmantojām Cloudfront kā CDN, lai mūsu JS lietotnes varētu ļoti ātri ielādēt visā pasaulē un tikt apkalpotas tik reižu, cik tiek prasīts. Cloudflare ir arī labs risinājums, un tas piedāvā DDOS aizsardzību ārpus kastes.

Vienkāršības labad mēs nolēmām izmantot Route 53 kā mūsu DNS, izmantojot viņu vārdu serverus visiem mūsu domēniem. Šis ir viens no maniem iecienītākajiem pakalpojumiem AWS. Tas padara jūsu dzīvi tik daudz vieglāku. Katru reizi, kad vēlaties kaut ko apkalpot, izmantojot domēna vārdu, neatkarīgi no tā, vai tas ir EC2 piemērs, elastīgs IP, slodzes līdzsvarotājs, Cloudfront izplatīšana vai kaut kas patiešām, privāti vai publiski, tas prasa minūtes, jo tas ir tik labi integrēts ar visiem citi pakalpojumi.

Apvieno to ar sertifikātu pārvaldnieku, kas ļauj dažās minūtēs bez maksas iegūt SSL sertifikātus (ieskaitot aizstājējzīmes) un izvietot tos visos serveros, atzīmējot rūtiņu, un jums ir ātrākais, visuzticamākais veids, kā iespējot HTTPS visos jūsu moduļos. Labdien, “Let’s Encrypt” SSL sertifikāti, kas man bija jāatjauno un jāinstalē savos serveros ik pēc 3 mēnešiem months.

Sāk izskatīties pieklājīgi

Izlemiet par kešatmiņas saglabāšanas stratēģiju

Visi ienīst kešatmiņas pārvaldību, kešatmiņa var notikt daudzos dažādos slāņos, un ar kešatmiņu saistītās problēmas ir grūti atkārtojamas, un tās ir murgs.

Diemžēl sadalīto sistēmu veiktspēja lielā mērā ir atkarīga no labas kešatmiņas saglabāšanas stratēģijas. Ir daudz labu rakstu par labu kešatmiņas saglabāšanas stratēģiju, tāpēc es neiedziļināšos sīkumos. Tikai zināt, ka, ja jūsu statiskā tīmekļa resursi ir lieli, jūs, iespējams, vēlēsities izmantot sava lietotāja pārlūka kešatmiņas priekšrocības, gudri izmantojot kešatmiņas vadības galveni.

Ja jūsu lietotāja lappuses atkal un atkal tiek ģenerētas lietojumprogrammu serveros, izmantojiet kešatmiņas starpniekserveri, piemēram, Kalmāru. Bet pats galvenais - pastāv liela iespēja, ka jūs atkal un atkal iesniegsit tos pašus pieprasījumus savai datu bāzei. Lai samazinātu datu bāzes slodzi un ietaupītu datu pārsūtīšanas laiku, izmantojiet atmiņas objektu kešatmiņas saglabāšanas sistēmu, piemēram, saglabātu atmiņā objektus, kurus bieži izmanto un reti atjauno.

Mēs sākām apsvērt iespēju izmantot atmiņas karti, jo mēs atkal un atkal pieprasījām tos pašus kandidātu profilus un darba piedāvājumus. Ieviešot to atmiņā optimizētā mašīnā, mūsu API veiktspēja palielinājās par vairāk nekā 30%, kad vidējais visu pieprasījuma atbilžu laiks dienā. Memcached tiek izplatīts arī, tāpēc tas var darboties dažādos serveros, taču joprojām darbojas tā, it kā tā būtu tikai viena liela atmiņas vieta jūsu objektu glabāšanai.

kešatmiņa, kešatmiņa visur

Atrašanās vieta, atrašanās vieta, atrašanās vieta

Tagad mums ir sadalīta sistēma, kurai nav neviena kļūmes punkta (ja ņem vērā AWS ELB un sadalītu atmiņu), un tā var automātiski palielināt mērogu uz augšu un uz leju. Mēs arī izmantojam kešatmiņu, lai samazinātu tīkla datu pārsūtīšanu. Izskatās diezgan labi. Tajā brīdī jūs, iespējams, vēlaties pārbaudīt savas trešās puses, lai redzētu, vai tās absorbēs kravu tikpat labi kā jūs.

Bet tomēr daži no mūsu lietotājiem sūdzējās, ka lietotne viņiem bija nedaudz lēnāka, it īpaši, kad viņi augšupielādēja failus. Pat ja mūsu statiskie tīmekļa faili visā pasaulē tika saglabāti kešatmiņā (ar CDN atbalstu), visi mūsu lietojumprogrammu serveri tika izvietoti tikai ASV rietumos. Lietotāji no Austrumāzijas piedzīvoja daudz lielāku latentumu, īpaši lielu datu pārsūtīšanai.

Risinājums bija vienkāršs: precīzi to pašu ECS kopu izvietojiet jaunā Āzijas reģionā kopā ar jaunu slodzes līdzsvarotāju un paļaujieties uz 53. maršruta ģeoproximity Routing, lai maršrutētu lietotājus uz “tuvāko” kravas līdzsvarotāju. MongoDB Atlas arī ļauj izvietot replikas reģionos, tāpēc nebija nepieciešams papildu darbs.

Un šeit mēs esam! Mūsu izplatītā sistēma ir gatava.

Secinājums

Kaut arī šeit redzamā izplatītā sistēma šai ziņai ir vienkāršota, mēs pārbaudījām daļas, kuras jūs, visticamāk, redzat daudzās mūsdienu tīmekļa lietojumprogrammās. Citas tēmas, kas saistītas ar, bet uz kurām neattiecas, ir mikroservisu arhitektūra, failu glabāšana un šifrēšana, datu bāzes sharding, plānotie uzdevumi, asinhrona paralēlā skaitļošana… varbūt nākamajā ierakstā!

Mans galvenais jautājums ir: nemēģiniet izveidot perfektu sistēmu, kad sākat produktu. Lielāko daļu jūsu dizaina izvēles noteiks tas, ko jūsu produkts dara un kurš to izmanto. Jūs uzzināsit tikai to, ka, nonākot produktu tirgū, jūs iegūsit labu pārskatu par savu lietotāju bāzi, un tas var ilgt mēnešus, pat gadus.

Koncentrējieties uz to, kā izdomāt, kas cilvēkiem ir nepieciešams, un mēģiniet rast savas problēmas risinājumu, pat ja tam ir daudz manuālu darbību. Tad padomājiet par veidiem, kā automatizēt, tērēt laiku kodēšanai un iznīcināšanai, kā arī izmantot trešās puses, kur tas ir jēga.

Ne mērogojiet, bet vienmēr domājiet, kodējiet un plānojiet mērogošanu. Veidojiet sistēmu soli pa solim, nerisiniet sistēmas projektēšanas problēmas, pamatojoties uz funkcijām, kuras vēl nav nobriedušas, un beidzot vienmēr mēģiniet atrast vislabāko kompromisu starp pavadīto laiku un veiktspējas, naudas un pazeminātās vērtības pieaugumu. risks.

Ja jums patika šis raksts un jūs uzskatījāt, ka kāds no tiem ir noderīgs, nospiediet šo pļaušanas pogu un sekojiet man, lai skatītu vairāk arhitektūras un attīstības rakstu!