Hallo kollega's.
Hjoed biede wy foar jo beskôging in oersetting fan in artikel fan Tugberk Ugurlu, dy't ûndernimme om yn in relatyf lyts folume de prinsipes fan it ûntwerpen fan moderne softwaresystemen te sketsen. Hjir is wat de skriuwer yn gearfetting oer himsels seit:
Om't it absolút ûnmooglik is om yn in habro-artikel sa'n kolossaal ûnderwerp te dekken as arsjitektoanyske patroanen + ûntwerppatroanen fanôf 2019, riede wy net allinich de tekst fan de hear Uruglu sels oan, mar ek de ferskate keppelings dy't hy der freonlik yn opnommen hat. As jo it leuk fine, sille wy in mear spesjalisearre tekst publisearje oer it ûntwerp fan ferspraat systemen.
Snapshot fan Unsplash
As jo noait sokke útdagings hawwe moatten as it ûntwerpen fan in softwaresysteem fanôf it begjin, dan is it by it begjinnen fan sa'n wurk soms net iens dúdlik wêr't jo moatte begjinne. Ik leau dat jo earst grinzen moatte tekenje sadat jo in min of mear selsbetrouwen idee hawwe fan wat jo krekt sille ûntwerpe, en dan de mouwen oprôlje en binnen dy grinzen wurkje. As útgongspunt kinne jo in produkt of tsjinst nimme (ideaal ien dy't jo echt leuk fine) en útfine hoe't jo it implementearje. Jo kinne fernuverje oer hoe ienfâldich dit produkt liket, en hoefolle kompleksiteit it eins befettet. Net ferjitte: , en dat is goed.
Ik tink dat it bêste advys dat ik kin jaan oan elkenien dy't begjint in systeem te ûntwerpen is dit: meitsje gjin oannames! Fan it begjin ôf moatte jo de feiten oantsjutte dy't bekend binne oer dit systeem en de ferwachtingen dy't dêrmei ferbûn binne. Hjir binne wat goede fragen om te stellen om jo te helpen mei jo ûntwerp te begjinnen:
- Wat is it probleem dat wy besykje op te lossen?
- Wat is it pykoantal brûkers dat sil ynteraksje mei ús systeem?
- Hokker patroanen fan skriuwen en lêzen fan gegevens sille wy brûke?
- Wat binne de ferwachte falliseminten, hoe sille wy se behannelje?
- Wat binne de ferwachtingen foar systeemkonsistinsje en beskikberens?
- Moatte jo by it wurkjen rekken hâlde mei alle easken relatearre oan eksterne ferifikaasje en regeljouwing?
- Hokker soarten gefoelige gegevens sille wy opslaan?
Dit binne mar in pear fragen dy't nuttich west hawwe foar sawol my as de teams dêr't ik yn 'e jierren fan profesjonele aktiviteit oan meidien haw. As jo de antwurden op dizze fragen kenne (en alle oaren dy't relevant binne foar de kontekst wêryn jo moatte wurkje), dan kinne jo stadichoan ferdjipje yn 'e technyske details fan it probleem.
Stel it earste nivo yn
Wat bedoel ik mei "baseline" hjir? Eins, yn ús tiid, de measte problemen yn 'e software yndustry "kinne" wurde oplost mei besteande metoaden en technologyen. Sadwaande, troch dit lânskip te navigearjen, krije jo in bepaalde foarsprong as jo konfrontearre wurde mei problemen dy't in oar foar jo oplosse moast. Ferjit net dat programma's skreaun binne om saaklike en brûkersproblemen op te lossen, dus wy stribje dernei om it probleem op 'e meast rjochtlinige en ienfâldige (út it eachpunt fan 'e brûker) manier op te lossen. Wêrom is dit wichtich om te ûnthâlden? Miskien wolle jo yn jo koördinatesysteem nei unike oplossingen sykje foar alle problemen, om't jo tinke, "wat foar programmeur bin ik as ik oeral patroanen folgje"? Yn feite, de keunst hjir is it meitsjen fan besluten oer wêr en wat te dwaan. Fansels, elk fan ús hat te krijen mei unike problemen fan tiid ta tiid, elk fan dat is in echte útdaging. As ús inisjele nivo lykwols dúdlik definiearre is, dan witte wy wêr't wy ús enerzjy oan besteegje moatte: sykje nei klearmakke opsjes foar it oplossen fan it foar ús foarstelde probleem, of fierder te studearjen en in djipper begryp te krijen.
Ik tink dat ik jo koe oertsjûgje dat as in spesjalist mei fertrouwen begrypt wat de arsjitektoanyske komponint fan guon prachtige softwaresystemen is, dan sil dizze kennis ûnmisber wêze foar it behearskjen fan 'e keunst fan in arsjitekt en it ûntwikkeljen fan in solide basis op dit mêd.
Okee, dus wêr te begjinnen? U D'r is in repository op GitHub neamd , wêrfan jo kinne leare hoe't jo grutskalige systemen ûntwerpe kinne, en ek tariede op ynterviews oer dit ûnderwerp. De repository hat in seksje mei foarbylden , wêrby't benammen besjoen wurdt hoe't se it ûntwerp fan har systemen oanpakke bygelyks Twitter, Uber, ensfh.
Foardat wy lykwols oergeane nei dit materiaal, litte wy de wichtichste arsjitektoanyske útdagings dy't wy yn 'e praktyk steane, tichterby besjen. Dit is wichtich om't jo in protte aspekten fan in koppige en mearsidige probleem moatte spesifisearje, en it dan oplosse binnen it ramt fan 'e regeljouwing dy't jildt yn in bepaald systeem. , in eardere Facebook-meiwurker, skreau , wêr't hy syn eigen ûnderfining dielde fan it screenen fan hûnderten oanfregers. Wylst de fideo in protte rjochtet op grut systeemûntwerp en de súkseskritearia dy't wichtich binne as jo sykje nei in kandidaat foar sa'n posysje, sil it noch altyd tsjinje as in wiidweidige boarne oer hokker dingen it wichtichste binne by it ûntwerpen fan systemen. Ik stel ek foar dizze fideo.
Bouwe kennis oer it opslaan en opheljen fan gegevens
Typysk hat jo beslút oer hoe't jo jo gegevens op 'e lange termyn opslaan en weromhelje in krityske ynfloed op systeemprestaasjes. Dêrom moatte jo earst de ferwachte skriuw- en lêskaaimerken fan jo systeem begripe. Dan moatte jo dizze yndikatoaren kinne evaluearje en karren meitsje op basis fan de makke beoardielingen. Jo kinne dit wurk lykwols allinich effektyf omgean as jo besteande patroanen foar gegevensopslach begripe. Yn prinsipe betsjut dit solide kennis yn ferbân mei .
Databanken kinne wurde tocht as gegevensstruktueren dy't ekstreem skalberber en duorsum binne. Dêrom soe kennis fan gegevensstruktueren tige nuttich wêze moatte foar jo by it kiezen fan in bepaalde databank. Bygelyks, is in gegevensstruktuertsjinner dy't ferskate soarten wearden stipet. It lit jo wurkje mei gegevensstruktueren lykas listen en sets, en gegevens lêze mei bekende algoritmen, bygelyks, , organisearjen fan sa'n wurk yn in duorsume en tige tagonklike styl.
Snapshot fan Unsplash
As jo ienris in foldwaande begryp hawwe fan 'e ferskate patroanen foar gegevensopslach, gean dan troch nei it studearjen fan gegevenskonsistinsje en beskikberens. Earst moatte jo begripe op syn minst yn algemiene termen, en dan poets dizze kennis troch in tichterby te sjen op fêststelde patroanen и . Op dizze manier sille jo in begryp fan it fjild ûntwikkelje en begripe dat it lêzen en skriuwen fan gegevens eins twa heul ferskillende problemen binne, elk mei har eigen unike útdagings. Bewapene mei in pear konsistinsje- en beskikbere patroanen, kinne jo systeemprestaasjes signifikant ferheegje, wylst jo soargje foar glêde gegevensstream nei jo applikaasjes.
As lêste, it konversaasje oer gegevens opslachproblemen ôfslute, moatte wy ek caching neame. Moat it tagelyk rinne op 'e client en server? Hokker gegevens sille yn jo cache wêze? En werom? Hoe organisearje jo cache-ûnjildigens? Sil it regelmjittich dien wurde, mei bepaalde yntervallen? As ja, hoe faak? Ik advisearje te begjinnen om dizze ûnderwerpen te studearjen mei de earder neamde systeem design primer.
Kommunikaasje patroanen
Systemen besteane út ferskate komponinten; dit kinne ferskate prosessen wêze dy't rinne binnen deselde fysike knooppunt, of ferskate masines dy't rinne op ferskate dielen fan jo netwurk. Guon fan dizze boarnen binnen jo netwurk kinne privee wêze, mar oaren moatte iepenbier wêze en iepen foar konsuminten dy't se fan bûten tagong krije.
It is needsaaklik om te soargjen foar kommunikaasje fan dizze middels mei elkoar, en ek de útwikseling fan ynformaasje tusken it hiele systeem en de bûtenwrâld. Yn 'e kontekst fan systeemûntwerp wurde wy hjir wer konfrontearre mei in set fan nije en unike útdagings. Litte wy sjen hoe't se nuttich kinne wêze en wat p.
Snapshot fan Unsplash
By it organisearjen fan kommunikaasje mei de bûtenwrâld is it altyd tige wichtich , wêrfan ek serieus en aktyf neistribbe wurde moat.
Ferbining distribúsje
Ik bin der net wis fan dat it pleatsen fan dit ûnderwerp yn in aparte seksje foar elkenien rjochtfeardich lykje sil. Dochs sil ik presintearje dit konsept yn detail hjir, en ik leau dat it materiaal yn dizze paragraaf wurdt meast sekuer beskreaun troch de term "ferbining distribúsje".
Systemen wurde foarme troch in protte komponinten goed te ferbinen, en har kommunikaasje mei elkoar wurdt faak organisearre op basis fan fêststelde protokollen, bygelyks TCP en UDP. Dizze protokollen as sadanich binne lykwols faaks net genôch om te foldwaan oan alle behoeften fan moderne systemen, dy't faaks ûnder hege lading wurde eksploitearre en ek tige ôfhinklik binne fan brûkersbehoeften. It is faak nedich om manieren te finen om ferbiningen te fersprieden om te gean mei sokke hege loads op it systeem.
Dizze ferdieling is basearre op de bekende (DNS). Sa'n systeem lit domeinnammetransformaasjes mooglik meitsje, lykas gewogen round robin en op latency-basearre metoaden om te helpen de lading te fersprieden.
is fûneminteel wichtich, en praktysk alle grutte ynternet systeem wy omgean hjoed, leit efter ien of mear load balancers. Loadbalancers helpe klantfersiken te fersprieden oer meardere beskikbere eksimplaren. Load balancers komme yn sawol hardware as software, mar yn 'e praktyk hawwe jo faker te krijen mei software, bygelyks и . konseptueel ek hiel gelyk oan load balancers, hoewol't der in berik tusken de earste en twadde . Dizze ferskillen moatte rekken holden wurde by it ûntwerpen fan in systeem basearre op jo behoeften.
Jo moatte ek witte oer (CDN). In CDN is in wrâldwide ferspraat netwurk fan proxy-tsjinners dy't ynformaasje leveret fan knooppunten dy't geografysk tichter by in spesifike brûker lizze. CDN's binne de foarkar te brûken as jo wurkje mei statyske bestannen skreaun yn JavaScript, CSS en HTML. Derneist binne wolktsjinsten dy't ferkearsbehearders leverje hjoed gewoan, bygelyks, , jouwe jo globale distribúsje en fermindere latency as jo wurkje mei dynamyske ynhâld. Sokke tsjinsten binne lykwols gewoanlik nuttich yn gefallen wêr't jo moatte wurkje mei steatleaze webtsjinsten.
Litte wy prate oer saaklike logika. Strukturearjen fan saaklike logika, taakstreamen en komponinten
Dat, it is ús slagge om ferskate ynfrastrukturele aspekten fan it systeem te besprekken. Meast wierskynlik tinkt de brûker net iens oer al dizze eleminten fan jo systeem en, earlik sein, makket har hielendal net oer. De brûker is ynteressearre yn hoe't it is om te ynteraksje mei jo systeem, wat kin wurde berikt troch dit te dwaan, en ek hoe't it systeem brûkerskommando's útfiert, wat en hoe't it docht mei brûkersgegevens.
Lykas de titel fan dit artikel suggerearret, soe ik prate oer software-arsjitektuer en systeemûntwerp. Dêrnjonken wie ik net fan plan om software-ûntwerppatroanen te dekken dy't beskriuwe hoe't softwarekomponinten wurde makke. Hoe mear ik der lykwols oer tink, hoe mear it my liket dat de line tusken software-ûntwerppatroanen en arsjitektoanyske patroanen heul wazig is, en de twa begripen binne nau besibbe. Litte wy bygelyks nimme (evenemint sourcing). Sadree't jo dit arsjitektoanyske patroan oannimme, sil it hast elk aspekt fan jo systeem beynfloedzje: lange termyn opslach fan gegevens, it nivo fan konsistinsje oannommen yn jo systeem, de foarm fan 'e komponinten dêryn, ensfh., ensfh. Dêrom besleat ik guon arsjitektoanyske patroanen te neamen dy't direkt relatearje oan bedriuwslogika. Ek al sil dit artikel himsels moatte beheine ta in ienfâldige list, ik moedigje jo oan om der yn 'e kunde te kommen en nei te tinken oer de ideeën dy't ferbûn binne mei dizze patroanen. Dêr bist:
- Fan it konsept , yn't bysonder, ,
Gearwurkjende oanpak
It is ekstreem ûnwierskynlik dat jo josels op in projekt sille fine as de dielnimmer dy't allinich ferantwurdlik is foar it systeemûntwerpproses. Krektoarsom, jo sille nei alle gedachten moatte ynteraksje mei kollega's wurkje sawol binnen as bûten jo taak. Yn dit gefal moatte jo miskien de selekteare technologyoplossingen mei kollega's evaluearje, saaklike behoeften identifisearje en begripe hoe't jo taken it bêste kinne parallelisearje.
Snapshot fan Unsplash
De earste stap is om in krekte en dielde begryp te ûntwikkeljen fan wat it bedriuwsdoel dat jo besykje te berikken is en mei hokker bewegende dielen jo moatte omgean. Groepsmodelleringstechniken, benammen (evenemint stoarmjen) helpe om dit proses signifikant te fersnellen en jo kânsen op sukses te fergrutsjen. Dit wurk kin dien wurde foar of nei jo skets , en ferdjipje it dan as it produkt ripet. Op grûn fan it nivo fan gearhing dat sil wurde berikt hjir, kinne jo ek formulearje foar de beheinde kontekst wêryn jo wurkje. As jo moatte prate oer de arsjitektuer fan jo systeem, kinne jo fine it nuttich , foarsteld , Benammen as jo moatte begripe hoefolle jo sille moatte gean yn 'e details fan it probleem, visualisearje de dingen dy't jo wolle kommunisearje.
D'r is wierskynlik in oare folwoeksen technology oer dit ûnderwerp dy't net minder nuttich is as Domain Driven Design. Wy komme lykwols op ien of oare manier werom nei it begripen fan it fakgebiet, dus kennis en ûnderfining op it fjild soe nuttich wêze moatte foar jo.
Boarne: www.habr.com