Cum să faceți față complexității atunci când proiectați sisteme software

Despre ce este vorba? În fiecare zi, în fiecare moment de-a lungul carierei noastre de inginer, întâlnim multe probleme diferite de complexitate variată și situații în care trebuie să luăm o decizie sau să o amânăm din cauza lipsei de date. Ori de câte ori construim noi servicii, construim infrastructură sau chiar formăm procese de dezvoltare, atingem o lume imensă cu diverse provocări. Este o provocare, și poate chiar imposibil, să enumerați toate problemele. Veți întâlni unele dintre aceste probleme doar dacă lucrați într-o anumită nișă. Pe de altă parte, există multe pe care trebuie să le înțelegem cu toții cum să le rezolvăm, deoarece sunt cruciale pentru construirea sistemelor IT. Cu o mare probabilitate, le vei întâlni în toate proiectele. În acest articol, voi împărtăși experiențele mele cu unele dintre problemele pe care le-am întâlnit în timpul creării de programe software. Ce este preocuparea transversală? Dacă ne uităm la Wikipedia, vom găsi următoarea definiție În dezvoltarea de software orientată pe aspecte, preocupările transversale sunt aspecte ale unui program care afectează mai multe module, fără posibilitatea de a fi încapsulate în niciunul dintre ele. Aceste preocupări adesea nu pot fi descompuse în mod curat de restul sistemului atât în proiectare, cât și în implementare și pot duce fie la împrăștiere (duplicarea codului), fie la încurcare (dependențe semnificative între sisteme) sau ambele. Descrie foarte mult ce este, dar vreau să o extind și să o simplific puțin: O este un concept sau o componentă a sistemului/organizației care afectează (sau „transmite”) multe alte părți. preocupare transversală Cele mai bune exemple de astfel de preocupări sunt arhitectura sistemului, înregistrarea în jurnal, securitatea, gestionarea tranzacțiilor, telemetria, proiectarea bazelor de date și există multe altele. Vom detalia multe dintre ele mai târziu în acest articol. La nivel de cod, preocupările transversale sunt adesea implementate folosind tehnici precum , unde aceste preocupări sunt modularizate în componente separate care pot fi aplicate în întreaga aplicație. Acest lucru păstrează logica de afaceri izolată de aceste preocupări, făcând codul mai lizibil și mai ușor de întreținut. programarea orientată pe aspecte (AOP) Clasificarea aspectelor Există multe modalități posibile de clasificare a aspectelor prin segmentarea acestora cu diferite proprietăți, cum ar fi domeniul de aplicare, dimensiunea, funcționalitatea, importanța, ținta și altele, dar în acest articol, voi folosi o clasificare simplă a domeniului de aplicare. Prin aceasta, vreau să spun unde este direcționat acest aspect specific, fie că este vorba despre întreaga organizație, un anumit sistem sau un element specific al acelui sistem. Deci, voi împărți aspectele în și . Macro Micro Prin aspect mă refer în principal la considerente pe care le urmărim pentru întregul sistem, cum ar fi arhitectura sistemului aleasă și designul acestuia (monolitic, microservicii, arhitectură orientată spre servicii), stiva de tehnologie, structura organizațională etc. Aspectele sunt legate în principal de aspectele strategice și de nivel înalt. deciziilor. macro macro Între timp, aspectul este mult mai aproape de nivelul de cod și dezvoltare. De exemplu, ce cadru este folosit pentru interacțiunea cu baza de date, structura proiectului de foldere și clase sau chiar modele specifice de proiectare a obiectelor. Micro Deși această clasificare nu este ideală, ajută la structurarea unei înțelegeri a posibilelor probleme și a importanței și impactului soluțiilor pe care le aplicăm acestora. În acest articol, accentul meu principal va fi pe aspectele macro. Aspecte macro Structura organizatorică Când tocmai am început să învăț despre arhitectura software, am citit multe articole interesante despre legea lui Conway și impactul acesteia asupra structurii organizaționale. Mai ales . Deci, această lege prevede că acesta Orice organizație care proiectează un sistem (definit în linii mari) va produce un design a cărui structură este o copie a structurii de comunicare a organizației. Întotdeauna am crezut că acest concept este într-adevăr foarte universal și reprezintă Regula de Aur. Apoi am început să învăț abordarea lui Eric Evans Domain-Driven Design (DDD) pentru modelarea sistemelor. Eric Evans subliniază importanța identificării contextului delimitat. Acest concept implică împărțirea unui model de domeniu complex în secțiuni mai mici, mai ușor de gestionat, fiecare cu propriul set limitat de cunoștințe. Această abordare ajută la comunicarea eficientă în echipă, deoarece reduce nevoia de cunoaștere extinsă a întregului domeniu și minimizează schimbarea contextului, făcând astfel conversațiile mai eficiente. Schimbarea contextului este cel mai rău și mai consumator de resurse. Chiar și computerele se luptă cu asta. Deși este puțin probabil să obținem o absență completă a comutării contextului, consider că pentru asta ar trebui să ne străduim. Revenind la Legea lui Conway, am găsit mai multe probleme cu ea. care am întâlnit-o cu legea lui Conway, care sugerează că proiectarea sistemului oglindește structura organizațională, este potențialul de a forma Contexte delimitate complexe și cuprinzătoare. Această complexitate apare atunci când structura organizațională nu este aliniată cu granițele de domeniu, ceea ce duce la Contexte delimitate care sunt puternic interdependente și încărcate cu informații. Aceasta duce la schimbarea frecventă a contextului pentru echipa de dezvoltare. Prima problemă pe este că terminologia organizațională se scurge la nivelul codului. Atunci când structurile organizaționale se schimbă, necesită modificări ale bazei de cod, consumând resurse valoroase. O altă problemă Astfel, urmărirea ajută la construirea sistemului și a organizației care încurajează arhitectura software dorită. Cu toate acestea, este de remarcat să spunem că această abordare nu va funcționa foarte bine în arhitectura și structurile deja formate, deoarece modificările în această etapă sunt prelungite, dar are performanțe excepționale în startup-uri, deoarece acestea introduc rapid orice modificări. Inverse Conway Maneuver Minge mare de noroi Acest model sau „anti-model” conduce la construirea unui sistem fără nicio arhitectură. Nu există reguli, limite și nicio strategie cu privire la modul de a controla inevitabila complexitate tot mai mare. Complexitatea este cel mai formidabil inamic în călătoria construirii sistemelor software. Pentru a evita construirea unui astfel de sistem, trebuie să respectăm reguli și constrângeri specifice. Arhitectura sistemului Există nenumărate definiții pentru arhitectura software. Îmi plac multe dintre ele, deoarece acoperă diferite aspecte ale acesteia. Cu toate acestea, pentru a putea raționa despre arhitectură, trebuie în mod natural să ne formăm unele dintre ele în mintea noastră. Și este de remarcat să spunem că această definiție poate evolua. Deci, cel puțin deocamdată, am următoarea descriere pentru mine. se referă la deciziile și alegerile pe care le faceți în fiecare zi care au impact asupra sistemului construit. Arhitectura software Pentru a lua decizii pe care trebuie să le ai în „pungă” principii și tipare pentru rezolvarea problemelor apărute, este, de asemenea, esențial să afirmi că înțelegerea cerințelor este esențială pentru a construi ceea ce are nevoie o afacere. Cu toate acestea, uneori cerințele nu sunt transparente sau chiar nu sunt definite, în acest caz, este mai bine să așteptați să obțineți mai multe clarificări sau să vă bazați pe experiența dvs. și să aveți încredere în intuiția dvs. Dar oricum, nu poți lua decizii corect dacă nu ai principii și modele pe care să te bazezi. Aici ajung la definiția stilului de arhitectură software. este un set de principii și modele care desemnează modul de construire a software-ului. Stilul de arhitectură software Există o mulțime de stiluri arhitecturale diferite axate pe diferite laturi ale arhitecturii planificate, iar aplicarea mai multor dintre ele simultan este o situație normală. De exemplu, cum ar fi: Arhitectură monolitică Design bazat pe domeniu Bazat pe componente Microservicii Conductă și filtre Condus de evenimente Microkernel Orientat spre servicii și așa mai departe… Desigur, au avantajele și dezavantajele lor, dar cel mai important lucru pe care l-am învățat este că arhitectura evoluează treptat, în funcție de problemele reale. Începând cu arhitectura monolitică este o alegere excelentă pentru reducerea complexităților operaționale, foarte probabil că această arhitectură se va potrivi nevoilor dvs. chiar și după ce ajungeți la etapa Product-market Fit (PMI) de construire a produsului. La scară, puteți lua în considerare trecerea către o abordare bazată pe evenimente și către microservicii pentru a obține o implementare independentă, un mediu tehnologic eterogen și o arhitectură mai puțin cuplată (și mai puțin transparentă între timp datorită naturii abordărilor bazate pe evenimente și pub-sub dacă acestea sunt adoptate). Simplitatea și eficiența sunt apropiate și au un mare impact una asupra celeilalte. De obicei, arhitecturile complicate influențează viteza de dezvoltare a noilor caracteristici, susținând și menținând pe cele existente și provocând evoluția naturală a sistemului. Cu toate acestea, sistemele complexe necesită adesea o arhitectură complexă și cuprinzătoare, ceea ce este inevitabil. În mod corect, acesta este un subiect foarte larg și există multe idei grozave despre cum să structurați și să construiți sisteme pentru evoluția naturală. Pe baza experienței mele, am elaborat următoarea abordare: Aproape întotdeauna începe cu stilul arhitecturii monolitice, deoarece elimină majoritatea problemelor care apar din cauza naturii sistemelor distribuite. De asemenea, este logic să urmați monolitul modular pentru a vă concentra pe componente de construcție cu limite clare. Aplicarea unei abordări bazate pe componente i-ar putea ajuta să comunice între ei prin utilizarea evenimentelor, dar apelurile directe (aka RPC) simplifică lucrurile la început. Cu toate acestea, este important să urmăriți dependențele dintre componente, deoarece dacă componenta A știe multe despre componenta B, poate că are sens să le îmbinați într-una singură. Când vă apropiați de situația în care trebuie să vă scalați dezvoltarea și sistemul, ați putea lua în considerare să urmați modelul pentru a extrage treptat componentele care trebuie implementate independent sau chiar scalate cu cerințe specifice. Stangler Acum, dacă ai o viziune clară asupra viitorului, ceea ce este un pic de noroc incredibil, te-ai putea decide asupra arhitecturii dorite. În acest moment, puteți decide să treceți către arhitectura de microservicii aplicând și abordări de orchestrare și coregrafie, încorporând modelul CQRS pentru operațiuni de scriere și citire la scară independentă sau chiar decizi să rămâneți cu arhitectura monolitică dacă se potrivește nevoilor dvs. De asemenea, este vital să înțelegeți cifrele și valorile precum (Utilizatori activi zilnici), (Utilizatori activi lunari), (Solicitare pe secundă) și (Tranzacție pe secundă), deoarece vă poate ajuta să faceți alegeri, deoarece arhitectura pentru 100 de utilizatori activi și 100 de milioane de utilizatori activi sunt diferiți. DAU MAU RPC TPC Ca o notă finală, aș spune că arhitectura are un impact semnificativ asupra succesului produsului. La scalare este necesară o arhitectură prost proiectată pentru produse, ceea ce duce foarte probabil la eșec, deoarece clienții nu vor aștepta în timp ce scalați sistemul, ei vor alege un concurent, așa că trebuie să fim în fața potențialului scalare. Pe de altă parte, a avea un sistem foarte complicat și deja scalat, fără clienți sau planuri de a obține mulți dintre ei, vă va costa bani pentru afacerea dvs. degeaba. Deși recunosc că uneori nu ar putea fi o abordare lean, ideea este să avem un sistem scalabil, dar nu deja scalat. Selectarea stivei de tehnologie Selectarea unei stive de tehnologie este, de asemenea, o decizie la nivel macro, deoarece influențează angajarea, perspectivele de evoluție naturală a sistemului, scalabilitatea și performanța sistemului. Aceasta este lista de considerente de bază pentru alegerea unei stive de tehnologie: De exemplu, o aplicație web simplă poate fi construită cu cadrul Blazor dacă dezvoltatorii dvs. au experiență cu acesta, dar din cauza lipsei de maturitate a WebAssembly, alegerea React și Typescript pentru succes pe termen lung ar putea fi o decizie mai bună. Cerințe și complexitate ale proiectului. Dacă anticipați că veți primi o cantitate mare de trafic, optarea pentru ASP.NET Core peste Django ar putea fi o alegere înțeleaptă datorită performanței sale superioare în gestionarea cererilor concurente. Cu toate acestea, această decizie depinde de amploarea traficului la care vă așteptați. Dacă trebuie să gestionați potențial miliarde de solicitări cu o latență scăzută, prezența Garbage Collection ar putea fi o provocare. Nevoi de scalabilitate și performanță. În cele mai multe cazuri, aceștia sunt factorii de care trebuie să ne pasă. Time to Market, costurile de întreținere și stabilitatea angajării vă conduc nevoile afacerii fără obstacole. Angajare, timp de dezvoltare și cost. Setul de aptitudini ale echipei de dezvoltare este un factor critic. În general, este mai eficient să folosești tehnologii cu care echipa ta este deja familiarizată, cu excepția cazului în care există un motiv serios pentru a investi în învățarea unei noi stive. Experiența și resursele echipei. O comunitate puternică și un ecosistem bogat de biblioteci și instrumente pot ușura foarte mult procesul de dezvoltare. Tehnologiile populare au adesea un sprijin mai bun al comunității, care poate fi de neprețuit pentru rezolvarea problemelor și găsirea de resurse. Astfel, puteți economisi resurse și vă puteți concentra în principal pe produs. Maturitate. Luați în considerare viabilitatea pe termen lung a tehnologiei. Tehnologiile care sunt adoptate și acceptate pe scară largă sunt mai puțin probabil să devină învechite și, în general, primesc actualizări și îmbunătățiri regulate. Întreținere și asistență pe termen lung. Cum ar putea avea mai multe stive de tehnologie să afecteze creșterea afacerii? Dintr-o perspectivă, introducerea încă o stivă vă poate mări angajarea, dar, pe de altă parte, aduce costuri suplimentare de întreținere, deoarece trebuie să susțineți ambele stive. Deci, așa cum am spus anterior, din punctul meu de vedere, doar o nevoie suplimentară ar trebui să fie un argument pentru încorporarea mai multor stive de tehnologie. Dar care este principiul selectării celui mai bun instrument pentru o problemă specifică? Uneori nu ai altă opțiune decât să aduci noi instrumente pentru a rezolva o problemă specifică pe baza acelorași considerente menționate mai sus, în astfel de cazuri, are sens să selectezi cea mai bună soluție. Crearea de sisteme fără cuplare ridicată la o tehnologie specifică ar putea fi o provocare. Cu toate acestea, este util să lupți pentru o condiție în care sistemul nu este strâns cuplat cu tehnologia și nu va muri dacă mâine, un anumit cadru sau un instrument devine vulnerabil sau chiar depreciat. Un alt aspect important este legat de dependențele software-ului open-source și proprietar. Software-ul proprietar vă oferă mai puțină flexibilitate și posibilitatea de a fi personalizat. Totuși, cel mai periculos factor este blocarea furnizorului, în care devii dependent de produsele, prețurile, termenii și foaia de parcurs ale unui furnizor. Acest lucru poate fi riscant dacă vânzătorul își schimbă direcția, crește prețurile sau întrerupe produsul. Eliminarea unui singur punct de eșec la toate nivelurile este cheia pentru construirea de sisteme fiabile pentru creștere. Software-ul open-source reduce acest risc, deoarece o singură entitate nu îl controlează. Punct unic de eșec (SPOF) Un singur punct de defecțiune (SPOF) se referă la orice parte a unui sistem care, dacă eșuează, va face ca întregul sistem să nu mai funcționeze. Eliminarea SPOF la toate nivelurile este crucială pentru orice sistem care necesită disponibilitate ridicată. Totul, inclusiv cunoștințele, personalul, componentele sistemului, furnizorii de cloud și cablurile de internet, pot eșua. Există mai multe tehnici de bază pe care le-am putea aplica pentru a elimina punctele singulare de defecțiune: Implementați redundanța pentru componentele critice. Aceasta înseamnă că aveți componente de rezervă care pot prelua în cazul în care componenta principală eșuează. Redundanța poate fi aplicată pe diferite straturi ale sistemului, inclusiv hardware (servere, discuri), rețele (linkuri, comutatoare) și software (baze de date, servere de aplicații). Dacă găzduiți totul într-un furnizor de cloud și chiar aveți copii de rezervă acolo, luați în considerare construirea unui backup suplimentar regulat într-un altul pentru a reduce costul pierdut în caz de dezastru. Redundanţă. Distribuiți-vă sistemul în mai multe locații fizice, cum ar fi centre de date sau regiuni cloud. Această abordare vă protejează sistemul împotriva defecțiunilor specifice locației, cum ar fi întreruperile de curent sau dezastrele naturale. Centre de date. Aplicați o abordare de failover pentru toate componentele dvs. (DNS, CDN, balansoare de încărcare, Kubernetes, gateway-uri API și baze de date). Deoarece problemele pot apărea pe neașteptate, este esențial să aveți un plan de rezervă pentru a înlocui rapid orice componentă cu clona sa, după cum este necesar. Failover. Asigurați-vă că serviciile dvs. sunt construite pentru a fi scalabile orizontal și foarte disponibile încă de la început, respectând următoarele principii: Servicii de mare disponibilitate. Practicați apatridia serviciului și evitați stocarea sesiunilor utilizatorilor în cache-urile din memorie. În schimb, utilizați un sistem cache distribuit, cum ar fi Redis. Evitați să vă bazați pe ordinea cronologică a consumului de mesaje atunci când dezvoltați logica. Minimizați modificările nerespective pentru a preveni perturbarea consumatorilor API. Acolo unde este posibil, optați pentru modificări compatibile cu versiunea inversă. De asemenea, luați în considerare costul, deoarece uneori, implementarea unei schimbări de ruptură poate fi mai rentabilă. Încorporați execuția migrației în conducta de implementare. Stabiliți o strategie pentru gestionarea cererilor concurente. Implementați descoperirea, monitorizarea și înregistrarea serviciilor pentru a îmbunătăți fiabilitatea și observabilitatea. Dezvoltați logica de afaceri pentru a fi idempotent, recunoscând că eșecurile rețelei sunt inevitabile. Examinați și minimizați în mod regulat dependențele externe. Fiecare dependență externă poate introduce potențiale SPOF, așa că este esențial să înțelegem și să atenuăm aceste riscuri. Revizuirea dependenței. Nu uitați niciodată importanța răspândirii cunoștințelor în cadrul organizației dvs. Oamenii pot fi imprevizibili, iar a te baza pe un singur individ este riscant. Încurajați membrii echipei să-și digitalizeze cunoștințele prin documentare. Cu toate acestea, aveți grijă de supradocumentare. Utilizați diverse instrumente AI pentru a simplifica acest proces. Partajarea regulată a cunoștințelor. Concluzie În acest articol, am acoperit mai multe aspecte cheie și cum putem face față complexității acestora. ale macro-urilor Vă mulțumim pentru citit! Ne vedem data viitoare!