Hello mga kasamahan.
Ngayon, nag-aalok kami para sa iyong pagsasaalang-alang ng pagsasalin ng isang artikulo ni Tugberk Ugurlu, na nagsagawa ng pagbabalangkas sa medyo maliit na volume ng mga prinsipyo ng pagdidisenyo ng mga modernong software system. Narito ang sinabi ng may-akda tungkol sa kanyang sarili bilang buod:
Dahil talagang imposibleng mag-cover sa isang artikulo ng habro ng napakalaking paksa tulad ng mga pattern ng arkitektura + mga pattern ng disenyo noong 2019, inirerekomenda namin hindi lamang ang teksto ni Mr. Uruglu mismo, kundi pati na rin ang maraming link na mabait niyang isinama dito. Kung gusto mo, maglalathala kami ng mas mataas na espesyalisadong teksto tungkol sa disenyo ng mga distributed system.
Snapshot mula sa Unsplash
Kung hindi mo pa kailangang harapin ang mga hamon tulad ng pagdidisenyo ng isang software system mula sa simula, kung gayon kapag sinimulan ang ganoong gawain, kung minsan ay hindi rin malinaw kung saan magsisimula. Naniniwala ako na kailangan mo munang gumuhit ng mga hangganan upang magkaroon ka ng higit o hindi gaanong kumpiyansa na ideya kung ano ang eksaktong ididisenyo mo, at pagkatapos ay i-roll up ang iyong mga manggas at magtrabaho sa loob ng mga hangganang iyon. Bilang panimulang punto, maaari kang kumuha ng isang produkto o serbisyo (sa perpektong isa na talagang gusto mo) at alamin kung paano ito ipatupad. Maaari kang mamangha sa kung gaano kasimple ang hitsura ng produktong ito, at kung gaano kahirap ang nilalaman nito. Huwag kalimutan: , at ayos lang.
Sa tingin ko ang pinakamahusay na payo na maibibigay ko sa sinumang nagsisimulang magdisenyo ng isang sistema ay ito: huwag gumawa ng anumang mga pagpapalagay! Sa simula pa lang, kailangan mong tukuyin ang mga katotohanang nalalaman tungkol sa sistemang ito at ang mga inaasahan na nauugnay dito. Narito ang ilang magagandang tanong na itatanong upang matulungan kang magsimula sa iyong disenyo:
- Ano ang problemang sinusubukan nating lutasin?
- Ano ang pinakamataas na bilang ng mga user na makikipag-ugnayan sa aming system?
- Anong mga pattern ng pagsulat at pagbasa ng data ang gagamitin natin?
- Ano ang mga inaasahang kaso ng kabiguan, paano natin ito haharapin?
- Ano ang mga inaasahan para sa pagkakapare-pareho at pagkakaroon ng system?
- Kailangan mo bang isaalang-alang ang anumang mga kinakailangan na nauugnay sa panlabas na pag-verify at regulasyon kapag nagtatrabaho?
- Anong mga uri ng sensitibong data ang iimbak namin?
Ito ay ilan lamang sa mga tanong na naging kapaki-pakinabang sa akin at sa mga koponan kung saan ako lumahok sa mga taon ng propesyonal na aktibidad. Kung alam mo ang mga sagot sa mga tanong na ito (at anumang iba pa na may kaugnayan sa konteksto kung saan kailangan mong magtrabaho), maaari mong unti-unting suriin ang mga teknikal na detalye ng problema.
Itakda ang paunang antas
Ano ang ibig kong sabihin sa "baseline" dito? Sa totoo lang, sa ating panahon, karamihan sa mga problema sa industriya ng software ay "maaaring" malutas gamit ang mga umiiral na pamamaraan at teknolohiya. Alinsunod dito, sa pamamagitan ng pag-navigate sa landscape na ito, makakakuha ka ng isang tiyak na simula kapag nahaharap sa mga problema na kailangang lutasin ng ibang tao bago ka. Huwag kalimutan na ang mga programa ay isinulat upang malutas ang mga problema sa negosyo at user, kaya't nagsusumikap kaming lutasin ang problema sa pinakasimple at pinakasimpleng paraan (mula sa pananaw ng user). Bakit ito mahalagang tandaan? Marahil sa iyong sistema ng coordinate gusto mong maghanap ng mga natatanging solusyon para sa lahat ng mga problema, dahil iniisip mo, "anong uri ng programmer ako kung susundin ko ang mga pattern sa lahat ng dako"? Sa katunayan, ang sining dito ay ang paggawa ng mga desisyon tungkol sa kung saan at kung ano ang gagawin. Mangyari pa, bawat isa sa atin ay kailangang harapin ang mga natatanging problema sa pana-panahon, na ang bawat isa ay isang tunay na hamon. Gayunpaman, kung malinaw na tinukoy ang ating paunang antas, alam natin kung ano ang gugugol ng ating lakas: paghahanap ng mga handa na opsyon para sa paglutas ng problemang itinakda sa atin, o higit pang pag-aaral nito at pagkakaroon ng mas malalim na pag-unawa.
Sa palagay ko ay nakumbinsi kita na kung ang isang espesyalista ay may kumpiyansa na nauunawaan kung ano ang bahagi ng arkitektura ng ilang kahanga-hangang mga sistema ng software, kung gayon ang kaalamang ito ay kailangang-kailangan para sa pag-master ng sining ng isang arkitekto at pagbuo ng matatag na batayan sa larangang ito.
Okay, so saan magsisimula? U Mayroong isang repositoryo sa GitHub na tinatawag , kung saan matututunan mo kung paano magdisenyo ng mga malalaking sistema, gayundin ang paghahanda para sa mga panayam sa paksang ito. Ang imbakan ay may isang seksyon na may mga halimbawa , kung saan, sa partikular, isinasaalang-alang kung paano nila nilapitan ang disenyo ng kanilang mga system hal. Twitter, Uber, atbp.
Gayunpaman, bago lumipat sa materyal na ito, tingnan natin ang pinakamahahalagang hamon sa arkitektura na kinakaharap natin sa pagsasanay. Mahalaga ito dahil kailangan mong tukuyin ang MARAMING aspeto ng isang matigas ang ulo at multi-faceted na problema, at pagkatapos ay lutasin ito sa loob ng balangkas ng mga regulasyong ipinapatupad sa isang partikular na sistema. , isang dating empleyado sa Facebook, ang sumulat , kung saan ibinahagi niya ang kanyang sariling karanasan sa pag-screen ng daan-daang mga aplikante. Bagama't nakatutok nang husto ang video sa malaking disenyo ng system at sa pamantayan ng tagumpay na mahalaga kapag naghahanap ng kandidato para sa ganoong posisyon, magsisilbi pa rin itong komprehensibong mapagkukunan sa kung anong mga bagay ang pinakamahalaga kapag nagdidisenyo ng mga system. I suggest din ang video na ito.
Bumuo ng kaalaman tungkol sa pag-iimbak at pagkuha ng data
Karaniwan, ang iyong desisyon tungkol sa kung paano mo iimbak at kukunin ang iyong data sa mahabang panahon ay may kritikal na epekto sa pagganap ng system. Samakatuwid, kailangan mo munang maunawaan ang inaasahang pagsusulat at pagbabasa ng mga katangian ng iyong system. Pagkatapos ay kailangan mong masuri ang mga tagapagpahiwatig na ito at gumawa ng mga pagpipilian batay sa mga pagtatasa na ginawa. Gayunpaman, maaari mong epektibong makayanan ang gawaing ito kung naiintindihan mo ang mga umiiral na pattern ng pag-iimbak ng data. Sa prinsipyo, ito ay nagpapahiwatig ng matatag na kaalaman na may kaugnayan sa .
Ang mga database ay maaaring isipin bilang mga istruktura ng data na lubhang nasusukat at matibay. Samakatuwid, ang kaalaman sa mga istruktura ng data ay dapat maging lubhang kapaki-pakinabang sa iyo kapag pumipili ng isang partikular na database. Halimbawa, ay isang server ng istruktura ng data na sumusuporta sa iba't ibang uri ng mga halaga. Pinapayagan ka nitong magtrabaho kasama ang mga istruktura ng data tulad ng mga listahan at set, at magbasa ng data gamit ang mga kilalang algorithm, halimbawa, , pag-aayos ng naturang gawain sa isang matibay at lubos na naa-access na istilo.
Snapshot mula sa Unsplash
Sa sandaling mayroon ka nang sapat na pag-unawa sa iba't ibang mga pattern ng pag-iimbak ng data, magpatuloy sa pag-aaral ng pagkakapare-pareho at kakayahang magamit ng data. Una sa lahat, kailangan mong maunawaan kahit man lang sa mga pangkalahatang termino, at pagkatapos ay pakinisin ang kaalamang ito sa pamamagitan ng mas malapitang pagtingin sa mga naitatag na pattern ΠΈ . Sa ganitong paraan, magkakaroon ka ng pag-unawa sa larangan at mauunawaan mo na ang pagbabasa at pagsusulat ng data ay talagang dalawang magkaibang problema, bawat isa ay may sariling natatanging hamon. Gamit ang ilang pare-pareho at availability pattern, maaari mong makabuluhang taasan ang pagganap ng system habang tinitiyak ang maayos na daloy ng data sa iyong mga application.
Sa wakas, sa pagtatapos ng pag-uusap tungkol sa mga isyu sa pag-iimbak ng data, dapat din nating banggitin ang pag-cache. Dapat ba itong tumakbo nang sabay sa client at server? Anong data ang magiging sa iyong cache? At bakit? Paano mo inaayos ang cache invalidation? Gagawin ba ito nang regular, sa ilang mga agwat? Kung oo, gaano kadalas? Inirerekomenda ko ang simulang pag-aralan ang mga paksang ito ang nabanggit na system design primer.
Mga Pattern ng Komunikasyon
Ang mga sistema ay binubuo ng iba't ibang bahagi; ang mga ito ay maaaring iba't ibang proseso na tumatakbo sa loob ng parehong pisikal na node, o iba't ibang machine na tumatakbo sa iba't ibang bahagi ng iyong network. Ang ilan sa mga mapagkukunang ito sa loob ng iyong network ay maaaring pribado, ngunit ang iba ay dapat na pampubliko at bukas sa mga consumer na nag-a-access sa kanila mula sa labas.
Kinakailangan upang matiyak ang komunikasyon ng mga mapagkukunang ito sa bawat isa, pati na rin ang pagpapalitan ng impormasyon sa pagitan ng buong sistema at sa labas ng mundo. Sa konteksto ng disenyo ng mga system, narito muli tayong nahaharap sa isang hanay ng mga bago at natatanging hamon. Tingnan natin kung paano sila magiging kapaki-pakinabang , at anong p.
Snapshot mula sa Unsplash
Kapag nag-oorganisa ng komunikasyon sa labas ng mundo, ito ay palaging napakahalaga , ang probisyon na kailangan ding seryosohin at aktibong ituloy.
Pamamahagi ng koneksyon
Hindi ako sigurado na ang paglalagay ng paksang ito sa isang hiwalay na seksyon ay mukhang makatwiran sa lahat. Gayunpaman, ipapakita ko ang konseptong ito nang detalyado dito, at naniniwala ako na ang materyal sa seksyong ito ay pinakatumpak na inilarawan ng terminong "pamamahagi ng koneksyon".
Ang mga sistema ay nabuo sa pamamagitan ng maayos na pagkonekta sa maraming mga bahagi, at ang kanilang komunikasyon sa isa't isa ay madalas na nakaayos batay sa itinatag na mga protocol, halimbawa, TCP at UDP. Gayunpaman, ang mga protocol na ito ay kadalasang hindi sapat upang matugunan ang lahat ng mga pangangailangan ng mga modernong sistema, na kadalasang pinapatakbo sa ilalim ng mataas na pagkarga at lubos ding umaasa sa mga pangangailangan ng user. Kadalasan ay kinakailangan upang makahanap ng mga paraan upang maipamahagi ang mga koneksyon upang makayanan ang gayong mataas na pagkarga sa system.
Ang pamamahagi na ito ay batay sa kilalang (DNS). Ang ganitong sistema ay nagbibigay-daan sa mga pagbabago sa pangalan ng domain gaya ng weighted round robin at latency-based na mga pamamaraan upang makatulong na ipamahagi ang load.
sa panimula ay mahalaga, at halos lahat ng malaking sistema ng Internet na kinakaharap natin ngayon ay nasa likod ng isa o higit pang mga load balancer. Tumutulong ang mga load balancer na ipamahagi ang mga kahilingan ng kliyente sa maraming available na pagkakataon. Ang mga load balancer ay may parehong hardware at software, gayunpaman, sa pagsasanay, mas madalas na kailangan mong harapin ang mga software, halimbawa ΠΈ . sa konsepto ay halos kapareho din ng mga load balancer, bagama't mayroong hanay sa pagitan ng una at pangalawa . Ang mga pagkakaibang ito ay dapat isaalang-alang kapag nagdidisenyo ng isang sistema batay sa iyong mga pangangailangan.
Dapat mo ring malaman ang tungkol sa (CDN). Ang CDN ay isang pandaigdigang ipinamamahaging network ng mga proxy server na naghahatid ng impormasyon mula sa mga node na heograpikal na matatagpuan mas malapit sa isang partikular na user. Mas mainam na gamitin ang mga CDN kung nagtatrabaho ka sa mga static na file na nakasulat sa JavaScript, CSS at HTML. Bilang karagdagan, ang mga serbisyo sa cloud na nagbibigay ng mga tagapamahala ng trapiko ay karaniwan ngayon, halimbawa, , na nagbibigay sa iyo ng pandaigdigang pamamahagi at pinababang latency kapag nagtatrabaho sa dynamic na nilalaman. Gayunpaman, ang mga naturang serbisyo ay karaniwang kapaki-pakinabang sa mga kaso kung saan kailangan mong magtrabaho kasama ang mga stateless na serbisyo sa web.
Pag-usapan natin ang lohika ng negosyo. Pag-istruktura ng lohika ng negosyo, mga daloy ng gawain at mga bahagi
Kaya, nagawa naming talakayin ang iba't ibang aspeto ng imprastraktura ng sistema. Malamang, hindi man lang iniisip ng user ang lahat ng elementong ito ng iyong system at, sa totoo lang, wala siyang pakialam sa kanila. Interesado ang user sa kung ano ang pakiramdam ng pakikipag-ugnayan sa iyong system, kung ano ang maaaring makamit sa pamamagitan ng paggawa nito, at gayundin kung paano isinasagawa ng system ang mga utos ng user, kung ano at paano ito ginagawa sa data ng user.
Tulad ng iminumungkahi ng pamagat ng artikulong ito, magsasalita ako tungkol sa arkitektura ng software at disenyo ng system. Alinsunod dito, hindi ko binalak na saklawin ang mga pattern ng disenyo ng software na naglalarawan kung paano nilikha ang mga bahagi ng software. Gayunpaman, kung mas iniisip ko ito, mas tila sa akin na ang linya sa pagitan ng mga pattern ng disenyo ng software at mga pattern ng arkitektura ay napakalabo, at ang dalawang konsepto ay malapit na nauugnay. Kunin natin halimbawa (pagkuha ng kaganapan). Kapag pinagtibay mo ang pattern na ito ng arkitektura, maaapektuhan nito ang halos lahat ng aspeto ng iyong system: pangmatagalang imbakan ng data, ang antas ng pagkakapare-pareho na pinagtibay sa iyong system, ang hugis ng mga bahagi nito, atbp., atbp. Samakatuwid, nagpasya akong banggitin ang ilang mga pattern ng arkitektura na direktang nauugnay sa lohika ng negosyo. Kahit na ang artikulong ito ay kailangang limitahan ang sarili nito sa isang simpleng listahan, hinihikayat ko kayong kilalanin ito at isipin ang mga ideyang nauugnay sa mga pattern na ito. Narito ka:
- Mga konsepto , lalo na, ,
Mga collaborative approach
Malamang na hindi mo makikita ang iyong sarili sa isang proyekto bilang kalahok na tanging responsable para sa proseso ng disenyo ng system. Sa kabaligtaran, malamang na kailangan mong makipag-ugnayan sa mga kasamahan na nagtatrabaho sa loob at labas ng iyong gawain. Sa kasong ito, maaaring kailanganin mong suriin ang mga napiling solusyon sa teknolohiya kasama ang mga kasamahan, tukuyin ang mga pangangailangan ng negosyo at maunawaan kung paano pinakamahusay na iparallelize ang mga gawain.
Snapshot mula sa Unsplash
Ang unang hakbang ay upang bumuo ng isang tumpak at nakabahaging pag-unawa sa kung ano ang layunin ng negosyo na sinusubukan mong makamit at kung anong mga gumagalaw na bahagi ang kailangan mong harapin. Mga diskarte sa pagmomodelo ng grupo, sa partikular (event storming) ay nakakatulong upang makabuluhang mapabilis ang prosesong ito at mapataas ang iyong mga pagkakataong magtagumpay. Maaaring gawin ang gawaing ito bago o pagkatapos mong magbalangkas , at pagkatapos ay palalimin ito habang tumatanda ang produkto. Batay sa antas ng pagkakapare-pareho na makakamit dito, maaari ka ring magbalangkas para sa limitadong konteksto kung saan ka nagtatrabaho. Kapag kailangan mong pag-usapan ang tungkol sa arkitektura ng iyong system, maaari mong makitang kapaki-pakinabang ito , iminungkahi , lalo na kapag kailangan mong maunawaan kung gaano karaming kailangan mong talakayin ang mga detalye ng problema, na nakikita ang mga bagay na gusto mong ipaalam.
Marahil ay may isa pang mature na teknolohiya sa paksang ito na hindi gaanong kapaki-pakinabang kaysa sa Domain Driven Design. Gayunpaman, kahit papaano ay bumalik tayo sa pag-unawa sa lugar ng paksa, kaya ang kaalaman at karanasan sa larangan dapat maging kapaki-pakinabang sa iyo.
Pinagmulan: www.habr.com