Arhitectura software și proiectarea sistemelor: imaginea de ansamblu și ghidul de resurse

Salut colegi.

Astăzi vă oferim în considerație o traducere a unui articol de Tugberk Ugurlu, care s-a angajat să contureze într-un volum relativ mic principiile proiectării sistemelor software moderne. Iată ce spune autorul despre el însuși pe scurt:

Arhitectura software și proiectarea sistemelor: imaginea de ansamblu și ghidul de resurse
Întrucât este absolut imposibil să acoperiți într-un articol habro un subiect atât de colosal precum modele arhitecturale + modele de design începând din 2019, vă recomandăm nu doar textul domnului Uruglu în sine, ci și numeroasele link-uri pe care le-a inclus cu amabilitate în acesta. Dacă vă place, vom publica un text mai specializat despre proiectarea sistemelor distribuite.

Arhitectura software și proiectarea sistemelor: imaginea de ansamblu și ghidul de resurse

instantaneu Isaac Smith de la Unsplash

Dacă nu ați avut niciodată de înfruntat provocări precum proiectarea unui sistem software de la zero, atunci când începeți o astfel de muncă, uneori nu este clar nici măcar de unde să începeți. Cred că mai întâi trebuie să trasezi limite, astfel încât să ai o idee mai mult sau mai puțin sigură despre ce anume vei proiecta, apoi să-ți sufleci mânecile și să lucrezi în limitele respective. Ca punct de plecare, puteți lua un produs sau serviciu (în mod ideal unul care vă place foarte mult) și vă puteți da seama cum să îl implementați. S-ar putea să fii uimit de cât de simplu arată acest produs și cât de multă complexitate conține de fapt. Nu uita: simplu – de obicei complex, și asta e în regulă.

Cred că cel mai bun sfat pe care îl pot da oricui începe să proiecteze un sistem este acesta: nu faceți nicio presupunere! De la bun început, trebuie să specificați faptele cunoscute despre acest sistem și așteptările asociate cu acesta. Iată câteva întrebări bune de adresat pentru a vă ajuta să începeți cu designul dvs.:

  • Care este problema pe care încercăm să o rezolvăm?
  • Care este numărul maxim de utilizatori care vor interacționa cu sistemul nostru?
  • Ce tipare de scriere și citire a datelor vom folosi?
  • Care sunt cazurile de eșec așteptate, cum le vom gestiona?
  • Care sunt așteptările pentru consistența și disponibilitatea sistemului?
  • Trebuie să țineți cont de orice cerințe legate de verificarea și reglementarea externă atunci când lucrați?
  • Ce tipuri de date sensibile vom stoca?

Sunt doar câteva întrebări care mi-au fost utile atât mie, cât și echipelor la care am participat de-a lungul anilor de activitate profesională. Dacă cunoașteți răspunsurile la aceste întrebări (și orice altele care sunt relevante pentru contextul în care trebuie să lucrați), atunci puteți aprofunda treptat în detaliile tehnice ale problemei.

Setați nivelul inițial

Ce vreau să spun aici prin „linie de bază”? De fapt, în vremurile noastre, majoritatea problemelor din industria software „pot” fi rezolvate folosind metodele și tehnologiile existente. Prin urmare, navigând în acest peisaj, obțineți un anumit avans atunci când vă confruntați cu probleme pe care altcineva a trebuit să le rezolve înaintea dvs. Nu uitați că programele sunt scrise pentru a rezolva problemele de afaceri și ale utilizatorilor, așa că ne străduim să rezolvăm problema în cel mai simplu și simplu (din punctul de vedere al utilizatorului). De ce este important de reținut acest lucru? Poate că în sistemul tău de coordonate îți place să cauți soluții unice pentru toate problemele, pentru că te gândești „ce fel de programator sunt dacă urmez tipare peste tot”? De fapt, arta de aici este luarea deciziilor despre unde și ce să faci. Desigur, fiecare dintre noi trebuie să se confrunte din când în când cu probleme unice, fiecare dintre acestea fiind o adevărată provocare. Cu toate acestea, dacă nivelul nostru inițial este clar definit, atunci știm pe ce să ne cheltuim energia: să căutăm opțiuni gata făcute pentru a rezolva problema pusă în fața noastră sau să o studiem în continuare și să obținem o înțelegere mai profundă.

Cred că am putut să vă conving că, dacă un specialist înțelege cu încredere care este componenta arhitecturală a unor sisteme software minunate, atunci aceste cunoștințe vor fi indispensabile pentru stăpânirea artei unui arhitect și dezvoltarea unei baze solide în acest domeniu.

Bine, de unde să încep? U Donna Martina Există un depozit pe GitHub numit sistem-design-amorsare, din care puteți învăța cum să proiectați sisteme la scară largă, precum și să vă pregătiți pentru interviuri pe această temă. Depozitul are o secțiune cu exemple arhitecturi reale, unde, în special, se ia în considerare modul în care aceștia abordează proiectarea sistemelor lor unele firme cunoscutede exemplu, Twitter, Uber etc.

Cu toate acestea, înainte de a trece la acest material, să aruncăm o privire mai atentă la cele mai importante provocări arhitecturale cu care ne confruntăm în practică. Acest lucru este important pentru că trebuie să specificați MULTE aspecte ale unei probleme încăpățânate și cu mai multe fațete și apoi să o rezolvați în cadrul reglementărilor în vigoare într-un sistem dat. Jackson Gabbard, un fost angajat al Facebook, a scris Videoclip de 50 de minute despre interviurile de proiectare a sistemelor, unde și-a împărtășit propria experiență de a examina sute de solicitanți. În timp ce videoclipul se concentrează foarte mult pe proiectarea unui sistem mare și pe criteriile de succes care sunt importante atunci când se caută un candidat pentru o astfel de poziție, va servi totuși ca o resursă cuprinzătoare asupra lucrurilor care sunt cele mai importante atunci când se proiectează sisteme. sugerez si eu rezumat acest video.

Dezvoltați cunoștințe despre stocarea și preluarea datelor

De obicei, decizia dumneavoastră cu privire la modul în care stocați și recuperați datele pe termen lung are un impact critic asupra performanței sistemului. Prin urmare, trebuie să înțelegeți mai întâi caracteristicile de scriere și citire așteptate ale sistemului dvs. Apoi trebuie să fiți capabil să evaluați acești indicatori și să faceți alegeri pe baza evaluărilor făcute. Cu toate acestea, puteți face față eficient acestei lucrări numai dacă înțelegeți modelele existente de stocare a datelor. În principiu, aceasta presupune cunoștințe solide legate de selectarea bazei de date.

Bazele de date pot fi gândite ca structuri de date extrem de scalabile și durabile. Prin urmare, cunoștințele structurilor de date ar trebui să vă fie foarte utile atunci când alegeți o anumită bază de date. De exemplu, Redis este un server de structură de date care acceptă diferite tipuri de valori. Vă permite să lucrați cu structuri de date, cum ar fi liste și seturi și să citiți date folosind algoritmi cunoscuți, de exemplu, LRU, organizând astfel de lucrări într-un stil durabil și extrem de accesibil.

Arhitectura software și proiectarea sistemelor: imaginea de ansamblu și ghidul de resurse

instantaneu Samuel Zeller de la Unsplash

Odată ce aveți o înțelegere suficientă a diferitelor modele de stocare a datelor, treceți la studiul consistenței și disponibilității datelor. În primul rând, trebuie să înțelegi teorema CAP cel puțin în termeni generali, și apoi lustruiți aceste cunoștințe, luând o privire mai atentă asupra tiparelor stabilite consistenta и accesibilitate. În acest fel, veți dezvolta o înțelegere a domeniului și veți înțelege că citirea și scrierea datelor sunt de fapt două probleme foarte diferite, fiecare cu propriile provocări unice. Înarmat cu câteva modele de consistență și disponibilitate, puteți crește semnificativ performanța sistemului, asigurând în același timp un flux fluid de date către aplicațiile dvs.

În sfârșit, încheind conversația despre problemele de stocare a datelor, ar trebui să menționăm și stocarea în cache. Ar trebui să ruleze simultan pe client și server? Ce date vor fi în memoria cache? Și de ce? Cum organizezi invalidarea memoriei cache? Se va face regulat, la anumite intervale? Dacă da, cât de des? Recomand să începeți să studiați aceste subiecte cu secțiunea următoare amorsa de proiectare a sistemului menționată mai sus.

Modele de comunicare

Sistemele constau din diverse componente; acestea pot fi procese diferite care rulează în același nod fizic sau mașini diferite care rulează în părți diferite ale rețelei dvs. Unele dintre aceste resurse din rețeaua dvs. pot fi private, dar altele ar trebui să fie publice și deschise consumatorilor care le accesează din exterior.

Este necesar să se asigure comunicarea acestor resurse între ele, precum și schimbul de informații între întregul sistem și lumea exterioară. În contextul proiectării sistemelor, aici din nou ne confruntăm cu un set de provocări noi și unice. Să vedem cum pot fi utile fluxuri de sarcini asincrone, și ce pSunt disponibile o varietate de modele de comunicare.

Arhitectura software și proiectarea sistemelor: imaginea de ansamblu și ghidul de resurse

instantaneu Tony Stoddard de la Unsplash

Atunci când organizați comunicarea cu lumea exterioară, este întotdeauna foarte importantă siguranță, a cărui prevedere trebuie, de asemenea, luată în serios și urmărită activ.

Distribuția conexiunii

Nu sunt sigur că plasarea acestui subiect într-o secțiune separată va părea justificată tuturor. Cu toate acestea, voi prezenta acest concept în detaliu aici și cred că materialul din această secțiune este cel mai precis descris prin termenul „distribuție a conexiunii”.

Sistemele sunt formate prin conectarea corectă a multor componente, iar comunicarea lor între ele este adesea organizată pe baza protocoalelor stabilite, de exemplu, TCP și UDP. Cu toate acestea, aceste protocoale ca atare sunt adesea insuficiente pentru a satisface toate nevoile sistemelor moderne, care sunt adesea operate la sarcini mari și sunt, de asemenea, foarte dependente de nevoile utilizatorilor. Este adesea necesar să se găsească modalități de distribuire a conexiunilor pentru a face față sarcinilor atât de mari ale sistemului.

Această distribuție se bazează pe binecunoscutul numele domeniului (DNS). Un astfel de sistem permite transformări de nume de domeniu, cum ar fi round robin ponderat și metode bazate pe latență pentru a ajuta la distribuirea încărcăturii.

Echilibrarea sarcinii este esențial important și, practic, fiecare sistem mare de internet cu care ne confruntăm astăzi se află în spatele unuia sau mai multor echilibratori de încărcare. Echilibratoarele de încărcare ajută la distribuirea cererilor clienților în mai multe instanțe disponibile. Echilibratoarele de sarcină vin atât în ​​hardware, cât și în software, cu toate acestea, în practică, mai des trebuie să aveți de-a face cu cele software, de exemplu HAProxy и ELB. Proxy invers conceptual, de asemenea, foarte asemănător cu echilibratoarele de încărcare, deși există o gamă între primul și al doilea diferențe distincte. Aceste diferențe trebuie luate în considerare atunci când proiectați un sistem pe baza nevoilor dumneavoastră.

Ar trebui să știți și despre rețele de livrare de conținut (CDN). Un CDN este o rețea globală distribuită de servere proxy care furnizează informații de la noduri care sunt localizate geografic mai aproape de un anumit utilizator. Este de preferat să utilizați CDN-urile dacă lucrați cu fișiere statice scrise în JavaScript, CSS și HTML. În plus, serviciile cloud care oferă manageri de trafic sunt comune astăzi, de exemplu, Manager de trafic Azure, oferindu-vă distribuție globală și o latență redusă atunci când lucrați cu conținut dinamic. Cu toate acestea, astfel de servicii sunt de obicei utile în cazurile în care trebuie să lucrați cu servicii web fără stat.

Să vorbim despre logica afacerii. Structurarea logicii de afaceri, a fluxurilor de sarcini și a componentelor

Așadar, am reușit să discutăm despre diverse aspecte de infrastructură ale sistemului. Cel mai probabil, utilizatorul nici măcar nu se gândește la toate aceste elemente ale sistemului tău și, sincer, nu-i pasă deloc de ele. Utilizatorul este interesat de cum este să interacționeze cu sistemul dvs., ce se poate obține făcând acest lucru și, de asemenea, modul în care sistemul execută comenzile utilizatorului, ce și cum face cu datele utilizatorului.

După cum sugerează titlul acestui articol, aveam să vorbesc despre arhitectura software și designul sistemului. În consecință, nu am plănuit să acoper modelele de proiectare software care descriu modul în care sunt create componentele software. Cu toate acestea, cu cât mă gândesc mai mult la asta, cu atât mai mult mi se pare că linia dintre modelele de design software și modelele arhitecturale este foarte neclară, iar cele două concepte sunt strâns legate. Să luăm de exemplu înregistrare la eveniment (aprovizionare cu evenimente). Odată ce adoptați acest model arhitectural, acesta va afecta aproape fiecare aspect al sistemului dvs.: stocarea pe termen lung a datelor, nivelul de consistență adoptat în sistemul dvs., forma componentelor din acesta etc., etc. Prin urmare, am decis să menționez câteva modele arhitecturale care au legătură directă cu logica afacerii. Chiar dacă acest articol va trebui să se limiteze la o listă simplă, vă încurajez să vă familiarizați cu el și să vă gândiți la ideile asociate cu aceste tipare. Poftim:

Abordări colaborative

Este extrem de puțin probabil să vă găsiți într-un proiect ca participant care este singurul responsabil pentru procesul de proiectare a sistemului. Dimpotrivă, cel mai probabil va trebui să interacționați cu colegii care lucrează atât în ​​cadrul sarcinii dvs., cât și în afara acesteia. În acest caz, poate fi necesar să evaluați soluțiile tehnologice selectate împreună cu colegii, să identificați nevoile de afaceri și să înțelegeți cum să paralelizați cel mai bine sarcinile.

Arhitectura software și proiectarea sistemelor: imaginea de ansamblu și ghidul de resurse

instantaneu Kaleidico de la Unsplash

Primul pas este să dezvoltați o înțelegere precisă și comună a obiectivului de afaceri pe care încercați să-l atingeți și cu ce părți în mișcare va trebui să vă ocupați. Tehnici de modelare de grup, în special evenimente furtunoase (event storming) ajută la accelerarea semnificativă a acestui proces și la creșterea șanselor de succes. Această lucrare poate fi făcută înainte sau după ce schițați limitele serviciilor dvs, apoi aprofundați-l pe măsură ce produsul se maturizează. Pe baza nivelului de consistență care va fi atins aici, puteți și formula limba comuna pentru contextul limitat în care lucrați. Când trebuie să vorbiți despre arhitectura sistemului dvs., s-ar putea să o găsiți util modelul C4, propus Simon Brown, mai ales când trebuie să înțelegi cât de mult va trebui să intri în detaliile problemei, vizualizând lucrurile pe care vrei să le comunici.

Probabil că există o altă tehnologie matură pe această temă care nu este mai puțin utilă decât Domain Driven Design. Cu toate acestea, ne întoarcem cumva la înțelegerea domeniului subiectului, deci cunoștințe și experiență în domeniu Design bazat pe domeniu ar trebui să vă fie de folos.

Sursa: www.habr.com

Adauga un comentariu