Sveiki kolegos.
Šiandien siūlome jūsų svarstymui Tugberko Ugurlu straipsnio vertimą, kuris ėmėsi palyginti nedideliu mastu apibūdinti šiuolaikinių programinės įrangos sistemų kūrimo principus. Štai ką autorius apibendrina apie save:
Kadangi habro straipsnyje visiškai neįmanoma aprėpti tokios kolosalios temos kaip architektūros raštai + dizaino raštai nuo 2019 m., rekomenduojame ne tik paties P. Uruglu tekstą, bet ir daugybę nuorodų, kurias jis maloniai įdėjo. Jei patiks, paskelbsime labiau specializuotą tekstą apie paskirstytų sistemų dizainą.
Momentinė nuotrauka iš Unsplash
Jeigu niekada neteko susidurti su tokiais iššūkiais kaip programinės sistemos projektavimas nuo nulio, tai pradedant tokius darbus kartais net neaišku nuo ko pradėti. Manau, kad pirmiausia reikia nubrėžti ribas, kad daugiau ar mažiau įsitikintumėte, ką tiksliai ketinate kurti, o tada pasiraitoti rankoves ir dirbti tose ribose. Kaip išeities tašką galite paimti produktą ar paslaugą (idealiu atveju tokią, kuri jums tikrai patinka) ir išsiaiškinti, kaip ją įgyvendinti. Galbūt nustebsite, kaip paprastas šis produktas atrodo ir koks sudėtingas jis iš tikrųjų yra. Nepamiršk: , ir viskas gerai.
Manau, kad geriausias patarimas, kurį galiu duoti kiekvienam, pradedančiam kurti sistemą, yra toks: nedarykite jokių prielaidų! Nuo pat pradžių turite nurodyti žinomus faktus apie šią sistemą ir su ja susijusius lūkesčius. Štai keletas gerų klausimų, kurie padės jums pradėti kurti dizainą:
- Kokią problemą bandome išspręsti?
- Koks didžiausias vartotojų, kurie sąveikaus su mūsų sistema, skaičius?
- Kokius duomenų rašymo ir skaitymo modelius naudosime?
- Kokie tikėtini nesėkmių atvejai, kaip juos tvarkysime?
- Kokie lūkesčiai dėl sistemos nuoseklumo ir prieinamumo?
- Ar dirbant reikia atsižvelgti į kokius nors reikalavimus, susijusius su išorine patikra ir reguliavimu?
- Kokio tipo neskelbtinus duomenis saugosime?
Tai tik keli klausimai, kurie buvo naudingi tiek man, tiek kolektyvams, kuriuose dalyvavau per ilgus profesinės veiklos metus. Jei žinote atsakymus į šiuos klausimus (ir visus kitus, susijusius su kontekstu, kuriame turite dirbti), galite palaipsniui įsigilinti į technines problemos detales.
Nustatykite pradinį lygį
Ką aš turiu omenyje sakydamas „bazinis lygis“? Tiesą sakant, mūsų laikais daugumą programinės įrangos pramonės problemų „galima“ išspręsti naudojant esamus metodus ir technologijas. Atitinkamai, naršydami šiame kraštovaizdyje jūs gaunate tam tikrą pranašumą, kai susiduriate su problemomis, kurias kažkas turėjo išspręsti prieš jus. Nepamirškite, kad programos yra sukurtos spręsti verslo ir vartotojų problemas, todėl mes stengiamės problemą išspręsti paprasčiausiu ir paprasčiausiu (vartotojo požiūriu) būdu. Kodėl tai svarbu atsiminti? Galbūt savo koordinačių sistemoje mėgstate ieškoti unikalių sprendimų visoms problemoms, nes galvojate „koks aš programuotojas, jei visur vadovaujuosi šablonais“? Faktiškai, menas čia priima sprendimus, kur ir ką daryti. Žinoma, kiekvienam iš mūsų karts nuo karto tenka susidurti su unikaliomis problemomis, kurių kiekviena yra tikras iššūkis. Tačiau jei mūsų pradinis lygis yra aiškiai apibrėžtas, tada žinome, kam išleisti savo energiją: ieškoti paruoštų variantų, kaip išspręsti iškilusią problemą, ar toliau ją tirti ir įgyti gilesnį supratimą.
Manau, man pavyko jus įtikinti, kad jei specialistas užtikrintai supranta, kas yra kai kurių nuostabių programinės įrangos sistemų architektūrinis komponentas, tai šios žinios bus nepakeičiamos norint įsisavinti architekto meną ir sukurti tvirtą pagrindą šioje srityje.
Gerai, taigi nuo ko pradėti? U „GitHub“ yra saugykla, vadinama , iš kurio galite išmokti kurti didelės apimties sistemas, taip pat pasiruošti interviu šia tema. Saugykloje yra skyrius su pavyzdžiais , kur visų pirma svarstoma, kaip jie žiūri į savo sistemų dizainą pvz., Twitter, Uber ir kt.
Tačiau prieš pereidami prie šios medžiagos, atidžiau pažvelkime į svarbiausius architektūrinius iššūkius, su kuriais susiduriame praktiškai. Tai svarbu, nes turite nurodyti DAUG užsispyrusios ir daugialypės problemos aspektų, o paskui ją išspręsti pagal tam tikroje sistemoje galiojančius reglamentus. rašė buvęs „Facebook“ darbuotojas , kur jis pasidalijo savo patirtimi tikrinant šimtus pretendentų. Nors vaizdo įraše daug dėmesio skiriama didelių sistemų projektavimui ir sėkmės kriterijams, kurie yra svarbūs ieškant kandidato į tokias pareigas, jis vis tiek pasitarnaus kaip išsamus šaltinis apie tai, kokie dalykai yra svarbiausi kuriant sistemas. Taip pat siūlau šį vaizdo įrašą.
Įgykite žinių apie duomenų saugojimą ir gavimą
Paprastai jūsų sprendimas dėl ilgalaikio duomenų saugojimo ir gavimo turi esminės įtakos sistemos veikimui. Todėl pirmiausia turite suprasti numatomas jūsų sistemos rašymo ir skaitymo charakteristikas. Tuomet reikia mokėti įvertinti šiuos rodiklius ir pagal atliktus vertinimus pasirinkti. Tačiau jūs galite efektyviai susidoroti su šiuo darbu tik tada, kai suprantate esamus duomenų saugojimo modelius. Iš esmės tai reiškia tvirtas žinias, susijusias su .
Duomenų bazės gali būti laikomos duomenų struktūromis, kurios yra labai keičiamos ir patvarios. Todėl duomenų struktūrų žinios jums turėtų būti labai naudingos renkantis konkrečią duomenų bazę. Pavyzdžiui, yra duomenų struktūros serveris, palaikantis įvairių tipų reikšmes. Tai leidžia dirbti su duomenų struktūromis, tokiomis kaip sąrašai ir rinkiniai, ir skaityti duomenis naudojant gerai žinomus algoritmus, pavyzdžiui, , organizuojant tokį darbą patvariu ir labai prieinamu stiliumi.
Momentinė nuotrauka iš Unsplash
Kai pakankamai suprasite įvairius duomenų saugojimo modelius, pereikite prie duomenų nuoseklumo ir prieinamumo tyrimo. Visų pirma, jūs turite suprasti bent jau bendrais bruožais, o vėliau šias žinias nušlifuokite atidžiau pažvelgdami į nusistovėjusius modelius и . Taip suprasite šią sritį ir suprasite, kad duomenų skaitymas ir rašymas iš tikrųjų yra dvi labai skirtingos problemos, kurių kiekviena turi savo unikalių iššūkių. Turėdami keletą nuoseklumo ir pasiekiamumo modelių, galite žymiai padidinti sistemos našumą ir užtikrinti sklandų duomenų srautą į programas.
Baigdami pokalbį apie duomenų saugojimo problemas, turėtume paminėti ir talpyklą. Ar jis turėtų veikti vienu metu kliente ir serveryje? Kokie duomenys bus jūsų talpykloje? Ir kodėl? Kaip organizuojate talpyklos negaliojimą? Ar tai bus daroma reguliariai, tam tikrais intervalais? Jei taip, kaip dažnai? Rekomenduoju pradėti studijuoti šias temas jau minėtas sistemos dizaino gruntas.
Bendravimo modeliai
Sistemos susideda iš įvairių komponentų; tai gali būti skirtingi procesai, veikiantys tame pačiame fiziniame mazge, arba skirtingi įrenginiai, veikiantys skirtingose tinklo dalyse. Kai kurie iš šių išteklių jūsų tinkle gali būti privatūs, tačiau kiti turėtų būti vieši ir atviri vartotojams, galintiems juos pasiekti iš išorės.
Būtina užtikrinti šių išteklių ryšį tarpusavyje, taip pat informacijos mainus tarp visos sistemos ir išorinio pasaulio. Sistemų projektavimo kontekste vėl susiduriame su daugybe naujų ir unikalių iššūkių. Pažiūrėkime, kuo jie gali būti naudingi , o ką p.
Momentinė nuotrauka iš Unsplash
Organizuojant bendravimą su išoriniu pasauliu tai visada labai svarbu , į kurio teikimą taip pat reikia žiūrėti rimtai ir aktyviai jo siekti.
Ryšio paskirstymas
Nesu tikras, kad šios temos skyrimas į atskirą skyrių visiems atrodys pagrįstas. Nepaisant to, šią sąvoką čia pateiksiu išsamiai ir manau, kad šios dalies medžiagą tiksliausiai apibūdina terminas „ryšio paskirstymas“.
Sistemos formuojamos tinkamai sujungiant daugelį komponentų, o jų tarpusavio ryšys dažnai organizuojamas pagal nustatytus protokolus, pavyzdžiui, TCP ir UDP. Tačiau šių protokolų kaip tokių dažnai nepakanka, kad patenkintų visus šiuolaikinių sistemų poreikius, kurios dažnai veikia esant didelei apkrovai ir taip pat labai priklauso nuo vartotojų poreikių. Dažnai reikia ieškoti būdų, kaip paskirstyti ryšius, kad būtų galima susidoroti su tokiomis didelėmis sistemos apkrovomis.
Šis paskirstymas pagrįstas gerai žinomais (DNS). Tokia sistema leidžia keisti domeno vardo transformacijas, pvz., svertinį ratą ir delsos metodus, padedančius paskirstyti apkrovą.
yra labai svarbus, ir beveik kiekviena didelė interneto sistema, su kuria šiandien susiduriame, yra už vieno ar kelių apkrovos balansavimo įrenginių. Apkrovos balansavimo priemonės padeda paskirstyti klientų užklausas keliems galimiems egzemplioriams. Apkrovos balansuotojai yra tiek aparatinės, tiek programinės įrangos, tačiau praktikoje dažniau tenka susidurti su programiniais, pvz. и . konceptualiai taip pat labai panašus į apkrovos balansavimo priemones, nors yra intervalas tarp pirmojo ir antrojo . Į šiuos skirtumus reikia atsižvelgti kuriant sistemą pagal savo poreikius.
Taip pat turėtumėte žinoti apie (CDN). CDN yra pasaulinis paskirstytas tarpinių serverių tinklas, teikiantis informaciją iš mazgų, kurie geografiškai yra arčiau konkretaus vartotojo. CDN pageidautina naudoti, jei dirbate su statiniais failais, parašytais JavaScript, CSS ir HTML. Be to, debesų paslaugos, teikiančios srauto tvarkykles, šiandien yra paplitusios, pavyzdžiui, , suteikiantis pasaulinį platinimą ir sumažintą delsą dirbant su dinamišku turiniu. Tačiau tokios paslaugos dažniausiai praverčia tais atvejais, kai tenka dirbti su interneto paslaugomis be pilietybės.
Pakalbėkime apie verslo logiką. Verslo logikos, užduočių srautų ir komponentų struktūrizavimas
Taigi, mums pavyko aptarti įvairius infrastruktūrinius sistemos aspektus. Greičiausiai vartotojas net negalvoja apie visus šiuos jūsų sistemos elementus ir, tiesą sakant, jiems visiškai nerūpi. Vartotojas domisi, kaip yra sąveikauti su jūsų sistema, ką galima pasiekti tai darant, taip pat kaip sistema vykdo vartotojo komandas, ką ir kaip daro su vartotojo duomenimis.
Kaip rodo šio straipsnio pavadinimas, aš ketinau kalbėti apie programinės įrangos architektūrą ir sistemos dizainą. Atitinkamai, aš neplanavau aprėpti programinės įrangos projektavimo modelių, apibūdinančių, kaip kuriami programinės įrangos komponentai. Tačiau kuo daugiau apie tai galvoju, tuo labiau man atrodo, kad riba tarp programinės įrangos projektavimo modelių ir architektūrinių modelių yra labai neryški, o šios dvi sąvokos yra glaudžiai susijusios. Paimkime pavyzdį (renginio šaltinių paieška). Pritaikius šį architektūrinį modelį, jis turės įtakos beveik visiems sistemos aspektams: ilgalaikiam duomenų saugojimui, jūsų sistemoje priimtam nuoseklumo lygiui, joje esančių komponentų formai ir t. t. Todėl nusprendžiau paminėti kai kuriuos architektūrinius modelius, kurie tiesiogiai susiję su verslo logika. Nors šiame straipsnyje teks apsiriboti paprastu sąrašu, raginu su juo susipažinti ir pagalvoti apie idėjas, susijusias su šiais modeliais. Prašom:
- Iš koncepcijos , ypač ,
Bendradarbiavimo metodai
Labai mažai tikėtina, kad atsidursite projekte kaip dalyvis, kuris yra vienintelis atsakingas už sistemos projektavimo procesą. Priešingai, greičiausiai turėsite bendrauti su kolegomis, dirbančiais tiek jūsų užduotyje, tiek už jos ribų. Tokiu atveju gali tekti kartu su kolegomis įvertinti pasirinktus technologinius sprendimus, nustatyti verslo poreikius ir suprasti, kaip geriausiai sulyginti užduotis.
Momentinė nuotrauka iš Unsplash
Pirmas žingsnis yra sukurti tikslų ir bendrą supratimą apie tai, kokį verslo tikslą bandote pasiekti ir su kokiomis judančiomis dalimis turėsite susidurti. Visų pirma grupės modeliavimo metodai (įvykių šturmas) padeda žymiai pagreitinti šį procesą ir padidinti sėkmės tikimybę. Šį darbą galima atlikti prieš nubrėžiant arba po jo , o tada pagilinkite, kai produktas bręsta. Remdamiesi nuoseklumo lygiu, kuris bus pasiektas čia, taip pat galite suformuluoti ribotam kontekstui, kuriame dirbate. Kai jums reikia pakalbėti apie savo sistemos architektūrą, tai gali būti naudinga , pasiūlė , ypač kai reikia suprasti, kiek teks gilintis į problemos detales, vizualizuojant dalykus, su kuriais norisi bendrauti.
Tikriausiai yra dar viena brandi technologija šia tema, kuri yra ne mažiau naudinga nei Domain Driven Design. Tačiau kažkaip grįžtame prie dalykinės srities supratimo, taigi žinių ir patirties šioje srityje turėtų būti jums naudinga.
Šaltinis: www.habr.com