ProHoster > Blogs > Administrācija > Programmatūras arhitektūra un sistēmu dizains: lielais attēls un resursu ceļvedis

Programmatūras arhitektūra un sistēmu dizains: lielais attēls un resursu ceļvedis

Sveiki kolēģi.

Å odien piedāvājam jÅ«su apskatei Tugberka Ugurlu raksta tulkojumu, kurÅ” apņēmās salÄ«dzinoÅ”i nelielā apjomā ieskicēt mÅ«sdienu programmatÅ«ras sistēmu projektÄ“Å”anas principus. LÅ«k, ko autors kopsavilkumā saka par sevi:

Programmatūras arhitektūra un sistēmu dizains: lielais attēls un resursu ceļvedis
Tā kā no 2019. gada habro rakstā ir absolÅ«ti neiespējami aptvert tik kolosālu tēmu kā arhitektÅ«ras raksti + dizaina raksti, mēs iesakām ne tikai paÅ”u Uruglu kunga tekstu, bet arÄ« daudzās saites, kuras viņŔ laipni iekļāvis tajā. Ja jums patiks, mēs publicēsim specializētāku tekstu par izplatÄ«to sistēmu dizainu.

Programmatūras arhitektūra un sistēmu dizains: lielais attēls un resursu ceļvedis

Foto ÄŖzaks Smits no Unsplash

Ja jums nekad nav nācies saskarties ar tādiem izaicinājumiem kā programmatÅ«ras sistēmas projektÄ“Å”ana no nulles, tad, uzsākot Ŕādu darbu, dažreiz pat nav skaidrs, ar ko sākt. Es uzskatu, ka vispirms ir jānozÄ«mē robežas, lai jums bÅ«tu vairāk vai mazāk pārliecināts priekÅ”stats par to, ko tieÅ”i jÅ«s plānojat izstrādāt, un pēc tam atrotiet piedurknes un strādājiet Å”ajās robežās. Kā sākuma punktu varat ņemt produktu vai pakalpojumu (ideālā gadÄ«jumā tādu, kas jums patieŔām patÄ«k) un izdomāt, kā to ieviest. JÅ«s varētu bÅ«t pārsteigts, cik vienkārÅ”s Å”is produkts izskatās un cik sarežģīts tas patiesÄ«bā ir. Neaizmirsti: vienkārÅ”s - parasti sarežģīts, un tas ir labi.

Es domāju, ka labākais padoms, ko varu sniegt ikvienam, kurÅ” sāk izstrādāt sistēmu, ir Ŕāds: neizdariet nekādus pieņēmumus! No paÅ”a sākuma jums ir jāprecizē fakti, kas ir zināmi par Å”o sistēmu un ar to saistÄ«tās cerÄ«bas. Å eit ir daži labi jautājumi, ko uzdot, lai palÄ«dzētu jums sākt darbu ar dizainu.

  • Kāda ir problēma, kuru mēs cenÅ”amies atrisināt?
  • Kāds ir maksimālais lietotāju skaits, kas mijiedarbosies ar mÅ«su sistēmu?
  • Kādus datu rakstÄ«Å”anas un lasÄ«Å”anas modeļus izmantosim?
  • Kādi ir sagaidāmie neveiksmju gadÄ«jumi, kā mēs tos risināsim?
  • Kādas ir cerÄ«bas attiecÄ«bā uz sistēmas konsekvenci un pieejamÄ«bu?
  • Vai strādājot ir jāņem vērā kādas prasÄ«bas saistÄ«bā ar ārējo pārbaudi un regulÄ“Å”anu?
  • Kāda veida sensitÄ«vus datus mēs glabāsim?

Å ie ir tikai daži jautājumi, kas noderējuÅ”i gan man, gan kolektÄ«viem, kuros esmu piedalÄ«jies profesionālās darbÄ«bas gados. Ja jÅ«s zināt atbildes uz Å”iem jautājumiem (un uz visiem citiem, kas attiecas uz kontekstu, kurā jums jāstrādā), varat pakāpeniski iedziļināties problēmas tehniskajās detaļās.

Iestatiet sākotnējo līmeni

Ko es Å”eit domāju ar ā€œbāzes lÄ«meniā€? PatiesÄ«bā mÅ«sdienās lielāko daļu problēmu programmatÅ«ras nozarē ā€œvarā€ atrisināt, izmantojot esoŔās metodes un tehnoloÄ£ijas. AttiecÄ«gi, pārvietojoties pa Å”o ainavu, jÅ«s iegÅ«stat zināmu priekÅ”rocÄ«bu, saskaroties ar problēmām, kuras kādam citam bija jāatrisina pirms jums. Neaizmirstiet, ka programmas ir rakstÄ«tas, lai atrisinātu biznesa un lietotāju problēmas, tāpēc mēs cenÅ”amies atrisināt problēmu pēc iespējas vienkārŔākajā un vienkārŔākajā (no lietotāja viedokļa). Kāpēc tas ir svarÄ«gi atcerēties? VarbÅ«t jÅ«su koordinātu sistēmā jums patÄ«k meklēt unikālus risinājumus visām problēmām, jo ā€‹ā€‹jÅ«s domājat, "kas gan es par programmētāju, ja es visur sekoju modeļiem"? PatiesÄ«bā, māksla Å”eit pieņem lēmumus par to, kur un ko darÄ«t. Protams, katram no mums ik pa laikam nākas saskarties ar unikālām problēmām, no kurām katra ir Ä«sts izaicinājums. Taču, ja mÅ«su sākotnējais lÄ«menis ir skaidri definēts, tad zinām, kam tērēt savu enerÄ£iju: gatavu variantu meklÄ“Å”anai izvirzÄ«tās problēmas risināŔanai vai tās tālākai izpētei un dziļākai izpratnei.

Domāju, ka varēju jÅ«s pārliecināt, ka, ja speciālists pārliecinoÅ”i saprot, kas ir dažu brÄ«niŔķīgu programmatÅ«ras sistēmu arhitektoniskā sastāvdaļa, tad Ŕīs zināŔanas bÅ«s neaizstājamas, lai apgÅ«tu arhitekta mākslu un veidotu stabilu pamatu Å”ajā jomā.

Labi, kur sākt? U Donna Martina Vietnē GitHub ir repozitorijs, ko sauc sistēma-projektÄ“Å”ana-grunts, no kuras var mācÄ«ties veidot liela mēroga sistēmas, kā arÄ« sagatavoties intervijām par Å”o tēmu. Repozitorijā ir sadaļa ar piemēriem Ä«stas arhitektÅ«ras, kur jo Ä«paÅ”i tiek apsvērts, kā viņi tuvojas savu sistēmu projektÄ“Å”anai daži labi zināmi uzņēmumipiemēram, Twitter, Uber utt.

Tomēr, pirms pāriet pie Ŕī materiāla, sÄ«kāk aplÅ«kosim svarÄ«gākos arhitektÅ«ras izaicinājumus, ar kuriem saskaramies praksē. Tas ir svarÄ«gi, jo jums ir jāprecizē DAUDZI spÄ«tÄ«gas un daudzŔķautņainas problēmas aspekti un pēc tam jārisina noteiktā sistēmā spēkā esoÅ”o noteikumu ietvaros. Džeksons Gabards, bijuÅ”ais Facebook darbinieks, rakstÄ«ja 50 minÅ«Å”u video par sistēmu dizaina intervijām, kur viņŔ dalÄ«jās savā pieredzē, pārbaudot simtiem pretendentu. Lai gan videoklipā liela uzmanÄ«ba tiek pievērsta lielu sistēmu dizainam un veiksmes kritērijiem, kas ir svarÄ«gi, meklējot kandidātu Ŕādam amatam, tas joprojām kalpos kā visaptveroÅ”s resurss par to, kuras lietas ir vissvarÄ«gākās, veidojot sistēmas. Es arÄ« iesaku kopsavilkums Å”is video.

Veidojiet zināŔanas par datu uzglabāŔanu un izgūŔanu

Parasti jÅ«su lēmumam par to, kā uzglabāt un izgÅ«t datus ilgtermiņā, ir bÅ«tiska ietekme uz sistēmas veiktspēju. Tāpēc vispirms ir jāsaprot paredzamās sistēmas rakstÄ«Å”anas un lasÄ«Å”anas Ä«paŔības. Tad jums ir jāspēj novērtēt Å”os rādÄ«tājus un izdarÄ«t izvēli, pamatojoties uz veiktajiem novērtējumiem. Tomēr jÅ«s varat efektÄ«vi tikt galā ar Å”o darbu tikai tad, ja saprotat esoÅ”os datu uzglabāŔanas modeļus. Principā tas nozÄ«mē stabilas zināŔanas, kas saistÄ«tas ar datu bāzes izvēle.

Datu bāzes var uzskatÄ«t par datu struktÅ«rām, kas ir ārkārtÄ«gi mērogojamas un izturÄ«gas. Tāpēc, izvēloties konkrētu datu bāzi, zināŔanām par datu struktÅ«rām vajadzētu bÅ«t ļoti noderÄ«gām. Piemēram, Redis ir datu struktÅ«ras serveris, kas atbalsta dažāda veida vērtÄ«bas. Tas ļauj strādāt ar datu struktÅ«rām, piemēram, sarakstiem un kopām, un lasÄ«t datus, izmantojot labi zināmus algoritmus, piemēram, LRU, organizējot Ŕādu darbu izturÄ«gā un ļoti pieejamā stilā.

Programmatūras arhitektūra un sistēmu dizains: lielais attēls un resursu ceļvedis

Foto Semjuels Zellers no Unsplash

Kad esat pietiekami izpratis dažādus datu uzglabāŔanas modeļus, pārejiet pie datu konsekvences un pieejamÄ«bas izpētes. Pirmkārt, jums ir jāsaprot CAP teorēma vismaz vispārÄ«gi, un pēc tam noslÄ«pēt Ŕīs zināŔanas, rÅ«pÄ«gāk aplÅ«kojot iedibinātos modeļus konsekvenci Šø pieejamÄ«ba. Tādā veidā jÅ«s attÄ«stÄ«sit izpratni par Å”o jomu un sapratÄ«sit, ka datu lasÄ«Å”ana un rakstÄ«Å”ana patiesÄ«bā ir divas ļoti atŔķirÄ«gas problēmas, un katrai no tām ir savi unikāli izaicinājumi. Izmantojot dažus konsekvences un pieejamÄ«bas modeļus, varat ievērojami palielināt sistēmas veiktspēju, vienlaikus nodroÅ”inot vienmērÄ«gu datu plÅ«smu uz jÅ«su lietojumprogrammām.

Visbeidzot, noslēdzot sarunu par datu uzglabāŔanas jautājumiem, jāpiemin arÄ« keÅ”atmiņa. Vai tam vajadzētu darboties vienlaicÄ«gi gan klientā, gan serverÄ«? Kādi dati bÅ«s jÅ«su keÅ”atmiņā? Un kāpēc? Kā jÅ«s organizējat keÅ”atmiņas anulÄ“Å”anu? Vai tas tiks darÄ«ts regulāri, ar noteiktiem intervāliem? Ja jā, cik bieži? Iesaku sākt pētÄ«t Ŕīs tēmas ar nākamā sadaļa iepriekÅ”minētais sistēmas dizaina gruntējums.

Komunikācijas modeļi

Sistēmas sastāv no dažādām sastāvdaļām; tie var bÅ«t dažādi procesi, kas darbojas vienā fiziskajā mezglā, vai dažādas maŔīnas, kas darbojas dažādās jÅ«su tÄ«kla daļās. Daži no Å”iem resursiem jÅ«su tÄ«klā var bÅ«t privāti, bet citiem ir jābÅ«t publiskiem un pieejamiem patērētājiem, kas tiem piekļūst no ārpuses.

NepiecieÅ”ams nodroÅ”ināt Å”o resursu savstarpēju saziņu, kā arÄ« informācijas apmaiņu starp visu sistēmu un ārpasauli. Sistēmu projektÄ“Å”anas kontekstā mēs atkal saskaramies ar virkni jaunu un unikālu izaicinājumu. ApskatÄ«sim, kā tie var bÅ«t noderÄ«gi asinhronās uzdevumu plÅ«smas, un ko pIr pieejami dažādi komunikācijas modeļi.

Programmatūras arhitektūra un sistēmu dizains: lielais attēls un resursu ceļvedis

Foto Tonijs Stoddards no Unsplash

Organizējot saziņu ar ārpasauli, tas vienmēr ir ļoti svarÄ«gi droŔība, kuras nodroÅ”ināŔana arÄ« ir jāuztver nopietni un aktÄ«vi jātiecas uz to.

Savienojuma sadale

Es neesmu pārliecināts, ka Ŕīs tēmas ievietoÅ”ana atseviŔķā sadaļā ikvienam ŔķitÄ«s pamatota. Neskatoties uz to, es Å”eit detalizēti izklāstÄ«Å”u Å”o jēdzienu, un es uzskatu, ka Ŕīs sadaļas materiālu visprecÄ«zāk raksturo termins "pieslēguma sadale".

Sistēmas tiek veidotas, pareizi savienojot daudzas sastāvdaļas, un to savstarpējā saziņa bieži tiek organizēta, pamatojoties uz izveidotiem protokoliem, piemēram, TCP un UDP. Tomēr Å”ie protokoli kā tādi bieži vien ir nepietiekami, lai apmierinātu visas mÅ«sdienu sistēmu vajadzÄ«bas, kuras bieži tiek darbinātas ar lielu slodzi un arÄ« ir ļoti atkarÄ«gas no lietotāju vajadzÄ«bām. Bieži vien ir jāatrod veidi, kā izplatÄ«t savienojumus, lai tiktu galā ar tik lielu sistēmas slodzi.

Šis sadalījums ir balstīts uz labi zināmo domēna vārdu sistēma (DNS). Šāda sistēma ļauj veikt domēna nosaukumu transformācijas, piemēram, svērtās apaļās metodes un latentuma metodes, lai palīdzētu sadalīt slodzi.

Slodzes balansÄ“Å”ana ir ļoti svarÄ«ga, un praktiski katra lielā interneta sistēma, ar kuru mēs Å”odien nodarbojamies, atrodas aiz viena vai vairākiem slodzes lÄ«dzsvarotājiem. Slodzes balansētāji palÄ«dz izplatÄ«t klientu pieprasÄ«jumus vairākos pieejamos gadÄ«jumos. Slodzes balansētāji ir gan aparatÅ«rā, gan programmatÅ«rā, tomēr praksē biežāk nākas saskarties ar programmatÅ«ras, piem. HAProxy Šø ELB. Reversie starpniekserveri konceptuāli arÄ« ļoti lÄ«dzÄ«gi slodzes balansētājiem, lai gan ir diapazons starp pirmo un otro izteiktas atŔķirÄ«bas. Å Ä«s atŔķirÄ«bas ir jāņem vērā, izstrādājot sistēmu, pamatojoties uz jÅ«su vajadzÄ«bām.

Jums vajadzētu zināt arÄ« par satura piegādes tÄ«kli (CDN). CDN ir globāls izplatÄ«ts starpniekserveru tÄ«kls, kas piegādā informāciju no mezgliem, kas Ä£eogrāfiski atrodas tuvāk konkrētam lietotājam. CDN ieteicams izmantot, ja strādājat ar statiskiem failiem, kas rakstÄ«ti JavaScript, CSS un HTML. Turklāt mākoņpakalpojumi, kas nodroÅ”ina satiksmes pārvaldÄ«tājus, mÅ«sdienās ir izplatÄ«ti, piemēram, Azure Traffic Manager, nodroÅ”inot globālu izplatÄ«Å”anu un samazinātu latentumu, strādājot ar dinamisku saturu. Tomēr Ŕādi pakalpojumi parasti ir noderÄ«gi gadÄ«jumos, kad jums ir jāstrādā ar bezvalstnieku tÄ«mekļa pakalpojumiem.

Parunāsim par biznesa loÄ£iku. Biznesa loÄ£ikas, uzdevumu plÅ«smu un komponentu strukturÄ“Å”ana

Tātad mums izdevās apspriest dažādus sistēmas infrastruktÅ«ras aspektus. Visticamāk, lietotājs pat nedomā par visiem Å”iem jÅ«su sistēmas elementiem un, godÄ«gi sakot, par tiem nemaz nerÅ«p. Lietotāju interesē, kā ir mijiedarboties ar jÅ«su sistēmu, ko ar to var panākt, kā arÄ«, kā sistēma izpilda lietotāja komandas, ko un kā tā dara ar lietotāja datiem.

Kā liecina Ŕī raksta nosaukums, es grasÄ«jos runāt par programmatÅ«ras arhitektÅ«ru un sistēmas dizainu. AttiecÄ«gi es neplānoju aptvert programmatÅ«ras dizaina modeļus, kas apraksta, kā tiek veidoti programmatÅ«ras komponenti. Tomēr, jo vairāk es par to domāju, jo vairāk man Ŕķiet, ka robeža starp programmatÅ«ras dizaina modeļiem un arhitektÅ«ras modeļiem ir ļoti neskaidra, un abi jēdzieni ir cieÅ”i saistÄ«ti. Ņemsim, piemēram pasākuma reÄ£istrācija (pasākumu iegÅ«Å”ana). TiklÄ«dz jÅ«s pieņemsit Å”o arhitektÅ«ras modeli, tas ietekmēs gandrÄ«z visus jÅ«su sistēmas aspektus: datu ilgtermiņa uzglabāŔanu, jÅ«su sistēmā pieņemto konsekvences lÄ«meni, tajā esoÅ”o komponentu formu utt., utt. Tāpēc es nolēmu pieminēt dažus arhitektÅ«ras modeļus, kas ir tieÅ”i saistÄ«ti ar biznesa loÄ£iku. Lai gan Å”im rakstam bÅ«s jāaprobežojas ar vienkārÅ”u sarakstu, iesaku jÅ«s ar to iepazÄ«ties un padomāt par idejām, kas saistÄ«tas ar Å”iem modeļiem. Å eit jÅ«s esat:

Sadarbības pieejas

Ir ļoti maz ticams, ka jÅ«s nonāksit projektā kā dalÄ«bnieks, kurÅ” ir pilnÄ«bā atbildÄ«gs par sistēmas projektÄ“Å”anas procesu. Gluži pretēji, jums, visticamāk, bÅ«s jāsazinās ar kolēģiem, kas strādā gan jÅ«su uzdevumā, gan ārpus tā. Å ajā gadÄ«jumā jums var bÅ«t nepiecieÅ”ams kopā ar kolēģiem izvērtēt izvēlētos tehnoloÄ£iju risinājumus, noteikt biznesa vajadzÄ«bas un saprast, kā vislabāk paralēli veikt uzdevumus.

Programmatūras arhitektūra un sistēmu dizains: lielais attēls un resursu ceļvedis

Foto Kaleidiko no Unsplash

Pirmais solis ir izveidot precÄ«zu un kopÄ«gu izpratni par to, kāds ir uzņēmējdarbÄ«bas mērÄ·is, kuru mēģināt sasniegt, un ar kādām kustÄ«gajām daļām jums bÅ«s jātiek galā. Jo Ä«paÅ”i grupu modelÄ“Å”anas metodes vētrainiem notikumiem (notikumu vētra) palÄ«dz ievērojami paātrināt Å”o procesu un palielināt jÅ«su izredzes gÅ«t panākumus. Å o darbu var veikt pirms vai pēc izklāsta pakalpojumu robežas, un pēc tam padziļiniet to produkta nogatavināŔanas laikā. Pamatojoties uz konsekvences lÄ«meni, kas Å”eit tiks sasniegts, varat arÄ« formulēt kopÄ«gu valodu ierobežotajam kontekstam, kurā strādājat. Ja jums ir jārunā par savas sistēmas arhitektÅ«ru, tā var bÅ«t noderÄ«ga modelis C4, ierosināts Saimons Brauns, it Ä«paÅ”i, ja ir jāsaprot, cik daudz jums bÅ«s jāiedziļinās problēmas detaļās, vizualizējot lietas, ar kurām vēlaties sazināties.

Iespējams, par Å”o tēmu ir vēl viena nobriedusi tehnoloÄ£ija, kas ir ne mazāk noderÄ«ga kā domēna vadÄ«ts dizains. Tomēr mēs kaut kā atgriežamies pie priekÅ”meta jomas izpratnes, tātad zināŔanas un pieredze Å”ajā jomā Uz domēnu orientēts dizains vajadzētu bÅ«t jums noderÄ«gam.

Avots: www.habr.com

Pievieno komentāru