paint-brush
Kaip pasirinkti serverio krūvą gaminio pristatymo metupateikė@gnovikov
109,422 skaitymai
109,422 skaitymai

Kaip pasirinkti serverio krūvą gaminio pristatymo metu

pateikė Grigorii Novikov9m2024/03/01
Read on Terminal Reader
Read this story w/o Javascript

Per ilgai; Skaityti

Produkto kūrimo srityje serverio rinkinio pasirinkimas turi didžiulę reikšmę, formuojant ne tik pradinį diegimą, bet ir ilgalaikį jūsų programos gyvybingumą bei efektyvumą. Grigorijus Novikovas, patyręs vyresnysis backend kūrėjas, semiasi savo patirties, kad pateiktų neįkainojamų įžvalgų apie sudėtingą idealaus serverio krūvos atrankos procesą.
featured image - Kaip pasirinkti serverio krūvą gaminio pristatymo metu
Grigorii Novikov HackerNoon profile picture
0-item


Tobulos serverio rinkinio pasirinkimas produktui paleisti yra labai svarbus sprendimas. Šis pasirinkimas turi įtakos ne tik pradiniam diegimui, bet ir ilgalaikiam programos pritaikymui bei efektyvumui. Jei esate vyresnysis kūrėjas arba vadovaujate komandai, jūs prisiimate atsakomybę už šiuos architektūros sprendimus, ieškodami daugybės kalbų ir sistemų, kad surastumėte tinkamiausią jūsų projekto unikaliems poreikiams. Jūsų užduotis čia yra padaryti svarbų pasirinkimą, kuris išliks jūsų projektui tobulėjant ir plečiantis.


Esu Grigorii Novikov, vyresnysis backend kūrėjas, turintis ilgametę patirtį kuriant ir diegiant programinės įrangos architektūras. Per visą savo karjerą aš susidūriau su daugybe svarbių sprendimų, susijusių su serverio dėklo pasirinkimu. Kiekvienas sprendimas papildė mano supratimą apie tai, kaip suderinti technologiją su augančio projekto reikalavimais. Šiame straipsnyje pasidalinsiu su jumis kai kuriomis sunkiai uždirbtomis įžvalgomis, padėsiančiomis išsirinkti serverių krūvą, kuri atitiks dabartinius jūsų projekto poreikius ir palaikys jo augimą ateityje. Kviečiu kartu su manimi išnagrinėti techninių sprendimų priėmimo subtilybes, kurios atveria kelią į sėkmę, ir įsitikinkite, kad jūsų projektas yra subrendęs augimui, lankstumui ir naujovėms.


Jei esate vyresnysis kūrėjas arba vadovaujate komandai, jūs prisiimate atsakomybę už šiuos architektūros sprendimus, ieškodami daugybės kalbų ir sistemų, kad surastumėte tinkamiausią jūsų projekto unikaliems poreikiams.


1. Automatiškai generuojanti dokumentacija

Nors ir nesusijęs su kodu per se, šis punktas yra toks svarbus, kad jį reikėtų aptarti pirmiausia. Tvirta dokumentacija yra veiksmingo kūrimo kertinis akmuo, ypač kai kalbama apie kliento pusės kūrimą ir programų testavimą. Automatinio dokumentacijos generavimo įrankiai pakeitė šį procesą, užtikrindami, kad dokumentacija neatsiliktų nuo naujausių API pakeitimų, supaprastina kūrimo darbo eigą ir sumažino rankinio darbo pastangų, kad jūsų projekto dokumentacija būtų atnaujinta.


Tarp kūrėjui prieinamų įrankių rekomenduoju „Swagger“ dėl jo universalumo, plačiai paplitusio pritaikymo ir galingo bendruomenės palaikymo. Kita populiari parinktis yra „Redoc“, kuri siūlo patrauklią, tinkinamą API dokumentacijos sąsają. Projektams, kuriems reikalingas išsamesnis pritaikymas, tokie įrankiai kaip Apiary suteikia lankstumo kartu su dokumentavimo galimybėmis, nors jiems gali prireikti daugiau pradinės sąrankos.


Kad ir kurį įrankį pasirinktumėte, tikslas turėtų būti optimizuoti dokumentavimo procesą, kad jis būtų efektyvus, neleidžiant pačiam įrankiui tapti reikšmingu laiko praradimu. Pasirinkite sprendimą, kuris sumažina rankinio dokumentavimo pastangas ir suteikia galimybę lanksčiai prisitaikyti prie unikalių jūsų projekto reikalavimų.


2. Klaidų sekimo palaikymas

Veiksmingas klaidų stebėjimas yra labai svarbus norint išlaikyti jūsų programos būklę. Veiksmingam klaidų stebėjimo integravimui naudoju tokius įrankius kaip „Jira“ ir „Bugzilla“, kurie gali pasigirti gausiu funkcijų rinkiniu ir lankstumu. Jira ypač siūlo tvirtas integravimo galimybes su daugeliu kūrimo aplinkų; Kita vertus, „Bugzilla“ yra žinomas dėl savo paprastumo ir efektyvumo, ypač atvirojo kodo projektuose, kur paprastas klaidų sekimas yra prioritetas.


Štai jums įžvalga: klaidų stebėjimo priemonių integravimas su momentiniais pranešimais ir versijų valdymo sistemomis padidins jūsų komandos bendradarbiavimą ir efektyvumą. Pavyzdžiui, „Jira+Bitbucket“ derinys supaprastina darbo eigą ir leidžia sklandžiai sekti problemas versijos valdymo aplinkoje. Šis susiejimas palengvina skaidrų, judrų kūrimo procesą, kai kodo atnaujinimai ir problemų sprendimai yra glaudžiai susiję, todėl galima greičiau iteruoti ir pagerinti kodo kokybę.


Kita galinga integracija yra Mattermost+Focalboard, kuri siūlo visapusišką bendradarbiavimo platformą. Jis sujungia tiesioginio „Mattermost“ komunikacijos privalumus su „Focalboard“ projektų ir užduočių valdymo galimybėmis, įgalindamas komandas gauti naujinius apie klaidų stebėjimą realiuoju laiku, taip pat lanksčiai valdyti užduotis ir darbo eigas vieningoje sąsajoje. Tokios integracijos ne tik optimizuoja klaidų sprendimo procesą, bet ir skatina darnesnę bei judresnę kūrimo aplinką, galiausiai didindamos produktyvumą ir projektų rezultatus.


3. Mastelio keitimas augant

Kai jūsų produktas pradės populiarėti, susidursite su mastelio didinimo iššūkiu. Ir aš neturiu omenyje tiesiog didėjančio vartotojų skaičiaus. Mastelio keitimas apima naujų funkcijų pritaikymą, augančios duomenų bazės tvarkymą ir optimalaus kodų bazės bei duomenų bazės našumo lygio palaikymą. Tai yra tada, kai architektūra, kurią pasirinkote savo serverio kaminui, iš tikrųjų pradeda veikti.


Pavyzdžiui, pradedant projektą, monolitinės architektūros pasirinkimas gali atrodyti kaip subalansuotas požiūris. Tačiau kai jūsų produktas auga ir keičiasi, pradėsite matyti, kur jis nepasiekia. Pereinant prie mikropaslaugų architektūros arba įtraukus keičiamo dydžio debesies paslaugas, galite daug tiksliau valdyti įvairius programos aspektus.


Dėl keičiamo dydžio serverio krūvos sprendimų renkuosi tokias technologijas kaip „Kubernetes“ ir „Docker“. Šie įrankiai suteiks jums lankstumo savarankiškai keisti paslaugų mastą, efektyviai valdyti diegimą ir užtikrinti nuoseklumą jūsų aplinkoje. Be to, debesų paslaugų teikėjai, tokie kaip „Amazon Web Services“, „Google Cloud“ ir „Microsoft Azure“, siūlo puikiai valdomas paslaugas, kurios gali iš tikrųjų supaprastinti jūsų mastelio keitimo kelionę.


Pasirinkus keičiamo dydžio architektūrą, reikia suderinti mastelio privalumus ir paskirstytos sistemos valdymo sudėtingumą. Galų gale, jūsų tikslas yra pasirinkti serverių paketą, kuris atitiktų jūsų dabartinius poreikius ir būtų lankstus, kad galėtų valdyti būsimą augimą.


4. Idealiai tinkančios vietos radimas: tarp bendruomenės ir saugumo

Netrūksta programavimo kalbų ir sistemų, kurių kiekviena turi savo privilegijų, tokių kaip bendruomenės palaikymas, išteklių prieinamumas ir net saugos funkcijos. Dėl šios įvairovės galima rinktis iš daugybės sprendimų, kurie ne tik sprendžia tiesioginius plėtros iššūkius, bet ir atitinka ilgalaikius projekto tikslus, įskaitant saugumą ir mastelį .


Technologijos, kurias palaiko didelės bendruomenės ir gausūs ištekliai, pvz., Python ir JavaScript, ir atitinkamos jų sistemos šiose kalbose, pvz., Django ar React, suteikia daug žinių ir paruoštų naudoti kodų pavyzdžių. Šis turtas žymiai sumažina laiką, kurį kitu atveju praleistumėte trikčių šalinimui, atsižvelgiant į mažą tikimybę susidurti su problema, kurios niekas neišsprendė anksčiau nei jūs. Ir atvirkščiai, naujesnės arba nišinės technologijos gali suteikti unikalių privilegijų, tačiau dažnai teks pasiruošti sunkesniam laikui, kai reikia rasti greitus sprendimus.


Kitas svarbus momentas – suderinti saugumą ir patogumą. Projektams, kuriuose pirminio kodo apsauga yra pagrindinis rūpestis, apsvarstykite galimybę naudoti kalbas ir technologijas, kurios palaiko lengvą užmaskavimą ir saugų pakavimą. Pavyzdžiui, „Java“ ir „.NET“ sukūrė įrankius ir ekosistemas kodui užmaskuoti. Čia taip pat padės konteinerių talpinimo technologijos, tokios kaip „Docker“. Supakuodami programą ir jos aplinką į konteinerį, užtikrinate, kad klientas gaus viską, ko reikia programai paleisti, tiesiogiai nepasiekdamas jūsų kodo. Šis metodas ne tik apsaugo kodą, bet ir supaprastina diegimo procesą.


5. Kaina

Renkantis technologijų paketą labai svarbu atsižvelgti į išlaidas. Kalbama tik apie pradinės sąrankos išlaidas, taip pat turite ilgai galvoti apie tai, kiek kainuos sistemos priežiūra ir mastelio keitimas .


Atvirojo kodo technologijoms suteikiama maloni privilegija – nuliniai išankstiniai licencijavimo mokesčiai. Pradedantiesiems ar bet kuriam projektui, turinčiam ribotą biudžetą, tai gali būti didelis pritraukimas. Be to, daugybė patyrusių kūrėjų padės lengviau valdyti darbo sąnaudas.


Kita vertus, sudėtingesnėms ir specializuotoms technologijoms, tokioms kaip „blockchain“ arba pažangios duomenų analizės platformos, gali prireikti didesnių pradinių investicijų. Nors jie siūlo reikšmingų pranašumų našumo ir saugumo požiūriu, turėtumėte palyginti visas nuosavybės išlaidas ir numatomą naudą.


Be to, debesijos paslaugos, nors ir sumažina fizinės infrastruktūros poreikį, patiria savo sąnaudas. Aukščiau paminėti AWS, Google Cloud ir Azure siūlo įvairius kainodaros modelius, kurie gali keistis atsižvelgiant į jūsų naudojimą; tačiau be kruopštaus valdymo šios išlaidos gali padidėti jūsų projektui augant.


6. Kodo pristatymas

Užtikrinant veiksmingą kodo pristatymą, dėmesys sutelkiamas į diegimo procesą, visų pirma naudojant nuolatinio integravimo / nuolatinio diegimo (CI / CD) vamzdynus. Šis metodas pabrėžia kodo perdavimo į įvairias aplinkas automatizavimo, kūrimo ir gamybos darbo eigos supaprastinimo svarbą.


Tokie įrankiai kaip „GitLab CI“ ir „CircleCI“ siūlo patikimus sprendimus automatizuoti testavimo ir diegimo procesus. Be to, naudojant scenarijaus įrankius, pvz., Ansible ir Terraform, šis automatizavimas dar labiau pagerinamas, leidžiantis aprūpinti ir valdyti infrastruktūrą naudojant kodą.


Šios technologijos padės sukurti vientisą vamzdyną, kuris tiksliai ir patikimai perkelia kodą nuo kūrimo iki gamybos. Integruodami šiuos įrankius į savo darbo eigą sukuriate sistemą, kuri ne tik pagreitina kūrimo ciklus, bet ir užtikrina nuoseklumą bei stabilumą įvairiose aplinkose.


7. Aplinka

Kūrimo aplinkos kūrimas ir valdymas yra esminis, tačiau sudėtingas bet kurio projekto gyvavimo ciklo aspektas. Kurti keičiamo dydžio ir prižiūrimą aplinką gali atrodyti bauginanti, ypač komandoms, kuriose nėra specialaus DevOps specialisto.


Daugeliui komandų atsakymas į klausimą apie geriausią požiūrį į aplinkos valdymą slypi debesyje pagrįstų paslaugų ir konteinerių panaudojime. Vėlgi, AWS, Google Cloud ir Azure siūlo daugybę paslaugų, kurias galima pritaikyti pagal jūsų projekto dydį ir sudėtingumą. Šios platformos suteikia įrankius, reikalingus kuriant lanksčią, keičiamo dydžio aplinką, nereikalaujant plataus infrastruktūros valdymo. Be to, įdiegus tokias technologijas kaip „Docker“ ir „Kubernetes“, diegimas įvairiuose kūrimo, testavimo ir gamybos etapuose tampa nuoseklus ir patikimas.


Veiksmingos ir patogios aplinkos kūrimas yra susijęs ne tik su serverio sąranka, bet ir su vietinės aplinkos konfigūravimu kūrėjams . Šis aspektas yra labai svarbus „DevOps“, nes jie dažnai kuria scenarijus, kad supaprastintų projektų paleidimo procesą vietoje. Tačiau ši užduotis ne visada yra lengva. Pavyzdžiui, vietinės aplinkos paruošimas .NET gali būti gana sudėtingas, todėl reikia pasirinkti technologijas ir įrankius, kurie supaprastina serverio ir vietines sąrankas. Norint išlaikyti produktyvumą ir palengvinti sklandžią darbo eigą, būtina užtikrinti sklandžią kūrėjų prieigą prie veiksmingos vietinės plėtros aplinkos.


Tinkamo serverio paketo pasirinkimas projektui yra tarsi pastato pamatų nustatymas: reikia kruopštaus svarstymo, numatymo ir pusiausvyros tarp esamų poreikių ir būsimo augimo. Kiekvienas jūsų pasirinkimas turi įtakos jūsų projekto sėkmei ir jo gebėjimui prisitaikyti bei klestėti dinamiškoje technologijų aplinkoje. Šiuo straipsniu siekiau padėti jums priimti šiuos svarbius sprendimus ir suteikti jums įžvalgų, kaip susidoroti su būsimais sunkumais. Tikiuosi, kad šiandien įgytos įžvalgos padės priimti pagrįstus sprendimus, kurie paskatins jūsų dabartinių ir būsimų projektų sėkmę!



ATVEJO TYRIMAS A: MASĖS MELO DETEKTORIAUS PROJEKTAS

Kuriant novatorišką melo detektorių, skirtą masiniam testavimui, kuris buvo pirmasis tokio pobūdžio projektas Rytų Europoje, aš susidūriau su serverio dėklo pasirinkimu kaip kūrėjų komandos vadovu. Pagrindiniai projekto reikalavimai – daugybė mikro paslaugų jungčių ir daugybė failų operacijų, skirtų įvairiems jutiklių išvestims apdoroti – reikalavo tvirto, bet lankstaus užpakalinio sprendimo.


Mes pasirinkome Python su FastAPI, o ne kitus konkurentus, tokius kaip Python / Django ir Go / Fiber. Sprendimas priklausė nuo aukščiausios kokybės „FastAPI“ asinchroninio programavimo palaikymo, kuris yra labai svarbus veiksnys norint efektyviai tvarkyti projekto intensyvius duomenų apdorojimo poreikius. „Django“, nors ir galingas, buvo pašalintas dėl sinchroninio pobūdžio, kuris negalėjo atitikti mūsų reikalavimų dėl didelio lygiagretumo ir duomenų tvarkymo realiuoju laiku. Panašiai buvo atsižvelgta į „Go“ našumą, tačiau galiausiai buvo atsisakyta greito „FastAPI“ kūrimo galimybių ir įmontuoto „Swagger“ dokumentacijos palaikymo, o tai buvo neįkainojama dėl mūsų griežto MVP kūrimo laiko juostos.


Tuo pačiu metu projektas reikalavo sukurti programinės įrangos kameros funkciją, galinčią valdyti internetinės kameros ryšius ir nukreipti vaizdo srautą įvairiais kanalais. Dėl neprilygstamo vykdymo greičio ir kelių platformų suderinamumo C++ tapo pasirinkta kalba šiai užduočiai atlikti.


Mūsų priimti sprendimai dėl šio projekto ne tik palengvino pradinę projekto sėkmę, bet ir padėjo tvirtą pagrindą jo nuolatiniam augimui ir prisitaikymui.

B ATVEJO TYRIMAS: KOVOS MENŲ KLUBAS CRM

Šiam projektui iš pradžių pasirinkau Python ir Django , pasirinkdamas juos dėl greito tobulėjimo galimybių, būtinų greitam paleidimui. Šis pasirinkimas pasirodė veiksmingas ankstyvaisiais etapais, tiesiogiai prisidėdamas prie klubo pajamų didinimo, pagerindamas lankomumo valdymą.


Išplėtus projekto taikymo sritį, įtraukiant tokias funkcijas kaip darbuotojų valdymas, analizė ir vidinė pranešimų siuntimo sistema, išryškėjo Django apribojimai valdyti sudėtingus, tuo pačiu metu vykstančius procesus. Šis supratimas paskatino mane integruoti Go, panaudojant jos gorutinas ir Fasthttp mūsų vidinio pasiuntinio kūrimui. „Go“ našumas tvarkant lygiagrečias užduotis padėjo mums išplėsti CRM funkcionalumą, leidžiantį išlaikyti aukštą našumą su minimaliomis papildomomis išlaidomis.


Sprendimas naudoti hibridinės technologijos metodą, naudojant Django pagrindinėms funkcijoms, o Go – didelio našumo komponentams, pasirodė esąs labai svarbus. Ši strategija leido man subalansuoti greitą plėtrą ir mastelį, užtikrinant, kad CRM galėtų tobulėti, kad atitiktų augančius klubo poreikius.