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:
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.
Foto 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: , 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 Vietnē GitHub ir repozitorijs, ko sauc , 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 , kur jo īpaši tiek apsvērts, kā viņi tuvojas savu sistēmu projektēšanai piemē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. , bijušais Facebook darbinieks, rakstīja , 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 š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 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, 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, , organizējot šādu darbu izturīgā un ļoti pieejamā stilā.
Foto 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 vismaz vispārīgi, un pēc tam noslīpēt šīs zināšanas, rūpīgāk aplūkojot iedibinātos modeļus и . 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 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 , un ko p.
Foto no Unsplash
Organizējot saziņu ar ārpasauli, tas vienmēr ir ļoti svarīgi , 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 (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.
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. и . konceptuāli arī ļoti līdzīgi slodzes balansētājiem, lai gan ir diapazons starp pirmo un otro . Šī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 (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, , 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ā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:
- Koncepcijas , it īpaši, ,
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.
Foto 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 (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 , un pēc tam padziļiniet to produkta nogatavināšanas laikā. Pamatojoties uz konsekvences līmeni, kas šeit tiks sasniegts, varat arī formulēt ierobežotajam kontekstam, kurā strādājat. Ja jums ir jārunā par savas sistēmas arhitektūru, tā var būt noderīga , ierosināts , 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ā vajadzētu būt jums noderīgam.
Avots: www.habr.com
