Sælir félagar.
Í dag bjóðum við þér til athugunar þýðingu á grein eftir Tugberk Ugurlu, sem tók að sér að útlista í tiltölulega litlu bindi meginreglur við hönnun nútíma hugbúnaðarkerfa. Hér er það sem höfundur segir um sjálfan sig í stuttu máli:
Þar sem það er algerlega ómögulegt að fjalla um í Habro grein svo stórkostlegt efni eins og byggingarmynstur + hönnunarmynstur frá og með 2019, mælum við ekki aðeins með texta Herra Uruglu sjálfs, heldur einnig fjölmörgum hlekkjum sem hann vinsamlega setti inn í hann. Ef þér líkar það munum við gefa út sérhæfðari texta um hönnun dreifðra kerfa.
Skyndimynd frá Unsplash
Ef þú hefur aldrei þurft að takast á við slíkar áskoranir eins og að hanna hugbúnaðarkerfi frá grunni, þá er stundum ekki einu sinni ljóst hvar á að byrja þegar slík vinna er hafin. Ég tel að þú þurfir fyrst að draga mörk svo þú hafir nokkurn veginn örugga hugmynd um hvað nákvæmlega þú ætlar að hanna og bretta svo upp ermarnar og vinna innan þeirra marka. Sem upphafspunktur geturðu tekið vöru eða þjónustu (helst þá sem þér líkar mjög við) og fundið út hvernig á að útfæra hana. Þú gætir verið undrandi á því hversu einföld þessi vara lítur út og hversu mikið flókið það inniheldur í raun. Ekki gleyma: , og það er allt í lagi.
Ég held að besta ráðið sem ég get gefið hverjum sem er að byrja að hanna kerfi sé þetta: ekki gefa þér neinar forsendur! Frá upphafi þarftu að tilgreina þær staðreyndir sem vitað er um þetta kerfi og væntingar sem tengjast því. Hér eru nokkrar góðar spurningar til að hjálpa þér að byrja með hönnunina þína:
- Hvert er vandamálið sem við erum að reyna að leysa?
- Hver er hámarksfjöldi notenda sem munu hafa samskipti við kerfið okkar?
- Hvaða mynstur skrifa og lesa gögn munum við nota?
- Hver eru væntanleg bilunartilvik, hvernig ætlum við að taka á þeim?
- Hverjar eru væntingar til samræmis og framboðs kerfisins?
- Þarftu að taka tillit til einhverra krafna sem tengjast ytri sannprófun og reglugerð þegar þú vinnur?
- Hvers konar viðkvæm gögn ætlum við að geyma?
Þetta eru aðeins nokkrar spurningar sem hafa nýst bæði mér og þeim liðum sem ég hef tekið þátt í í gegnum árin í faglegu starfi. Ef þú veist svörin við þessum spurningum (og öðrum sem skipta máli fyrir það samhengi sem þú þarft að vinna í), þá geturðu smám saman kafað ofan í tæknilegar upplýsingar um vandamálið.
Stilltu upphafsstigið
Hvað á ég við með "grunnlínu" hér? Reyndar, á okkar tímum, er hægt að leysa flest vandamál í hugbúnaðariðnaðinum með því að nota núverandi aðferðir og tækni. Í samræmi við það, með því að vafra um þetta landslag, færðu ákveðið forskot þegar þú stendur frammi fyrir vandamálum sem einhver annar þurfti að leysa á undan þér. Ekki gleyma því að forrit eru skrifuð til að leysa vandamál fyrirtækja og notenda, þannig að við kappkostum að leysa vandamálið á sem einfaldasta og einfaldasta hátt (frá sjónarhóli notandans). Hvers vegna er mikilvægt að muna þetta? Kannski í hnitakerfinu þínu finnst þér gaman að leita að einstökum lausnum fyrir öll vandamál, vegna þess að þú hugsar, "hvers konar forritari er ég ef ég fylgi mynstrum alls staðar"? Reyndar, listin hér er að taka ákvarðanir um hvar og hvað á að gera. Auðvitað þarf hvert og eitt okkar að takast á við einstök vandamál af og til, sem hvert um sig er raunveruleg áskorun. Hins vegar, ef upphafsstig okkar er skýrt skilgreint, þá vitum við hvað við eigum að eyða orku okkar í: að leita að tilbúnum valkostum til að leysa vandamálið sem fyrir okkur liggur, eða rannsaka það frekar og öðlast dýpri skilning.
Ég held að ég hafi getað sannfært þig um að ef sérfræðingur skilur með öryggi hvað byggingarfræðilegur þáttur sumra dásamlegra hugbúnaðarkerfa er, þá verður þessi þekking ómissandi til að ná tökum á list arkitekts og þróa traustan grunn á þessu sviði.
Allt í lagi, hvar á að byrja? U Það er geymsla á GitHub sem heitir , þaðan sem þú getur lært hvernig á að hanna stór kerfi, auk þess að undirbúa þig fyrir viðtöl um þetta efni. Geymslan hefur kafla með dæmum , þar sem einkum er horft til þess hvernig þeir nálgast hönnun kerfa sinna td Twitter, Uber osfrv.
Hins vegar, áður en við förum yfir í þetta efni, skulum við líta nánar á mikilvægustu byggingarlistaráskoranir sem við stöndum frammi fyrir í reynd. Þetta er mikilvægt vegna þess að tilgreina þarf MARGA hliðar á þrjóskum og margþættum vanda og leysa það síðan innan ramma þeirra reglugerða sem gilda í tilteknu kerfi. , fyrrverandi starfsmaður Facebook, skrifaði , þar sem hann deildi eigin reynslu af skimun hundruðum umsækjenda. Þó að myndbandið einblíni mikið á hönnun stórra kerfa og árangursskilyrði sem eru mikilvæg þegar leitað er að umsækjanda í slíka stöðu, mun það samt þjóna sem yfirgripsmikið úrræði um það sem skiptir mestu máli við hönnun kerfa. Ég legg líka til þetta myndband.
Byggja upp þekkingu um geymslu og endurheimt gagna
Venjulega hefur ákvörðun þín um hvernig þú geymir og endurheimtir gögnin þín til langs tíma mikilvæg áhrif á afköst kerfisins. Þess vegna verður þú fyrst að skilja væntanleg skrif- og lestareiginleika kerfisins þíns. Þá þarf að geta lagt mat á þessa vísbendingar og tekið ákvarðanir út frá því mati sem gert er. Hins vegar geturðu aðeins tekist á við þessa vinnu ef þú skilur núverandi gagnageymslumynstur. Í grundvallaratriðum felur þetta í sér trausta þekkingu sem tengist .
Líta má á gagnasöfn sem gagnasöfn sem eru afar stigstærð og endingargóð. Þess vegna ætti þekking á uppbyggingu gagna að vera mjög gagnleg fyrir þig þegar þú velur tiltekinn gagnagrunn. Til dæmis, er gagnaskipulagsþjónn sem styður ýmsar tegundir gilda. Það gerir þér kleift að vinna með gagnaskipulag eins og lista og sett og lesa gögn með því að nota vel þekkt reiknirit, til dæmis, , skipuleggja slíkt starf í varanlegum og mjög aðgengilegum stíl.
Skyndimynd frá Unsplash
Þegar þú hefur nægilegan skilning á hinum ýmsu gagnageymslumynstri skaltu halda áfram að rannsaka samræmi og framboð gagna. Fyrst af öllu þarftu að skilja að minnsta kosti almennt séð, og slípa síðan þessa þekkingu með því að skoða betur stofnað mynstur и . Þannig muntu þróa með þér skilning á sviðinu og skilja að lestur og ritun gagna eru í raun tvö mjög ólík vandamál, hvert með sínar einstöku áskoranir. Vopnaður með nokkrum samkvæmni og aðgengismynstri geturðu aukið verulega afköst kerfisins á sama tíma og þú tryggir slétt gagnaflæði til forritanna þinna.
Að lokum, til að ljúka samtalinu um gagnageymsluvandamál, ættum við einnig að nefna skyndiminni. Ætti það að keyra samtímis á biðlara og netþjóni? Hvaða gögn verða í skyndiminni þinni? Og hvers vegna? Hvernig skipuleggur þú ógildingu skyndiminni? Verður það gert reglulega, með ákveðnu millibili? Ef já, hversu oft? Ég mæli með því að byrja að kynna sér þessi efni með áðurnefndur grunnur fyrir kerfishönnun.
Samskiptamynstur
Kerfi samanstanda af ýmsum hlutum; þetta gætu verið mismunandi ferli sem keyra innan sama líkamlega hnútsins eða mismunandi vélar sem keyra á mismunandi hlutum netsins þíns. Sum þessara auðlinda innan netkerfisins þíns kunna að vera einkamál, en önnur ættu að vera opinber og opin neytendum sem fá aðgang að þeim utan frá.
Tryggja þarf samskipti þessara auðlinda sín á milli, sem og upplýsingaskipti milli alls kerfisins og umheimsins. Í samhengi við kerfishönnun stöndum við enn og aftur frammi fyrir nýjum og einstökum áskorunum. Við skulum sjá hvernig þau geta verið gagnleg , og hvað bls.
Skyndimynd frá Unsplash
Þegar skipuleggja samskipti við umheiminn er það alltaf mjög mikilvægt , sem einnig þarf að taka alvarlega og vinna eftir með virkum hætti.
Tengidreifing
Ég er ekki viss um að öllum sýnist réttlætanlegt að setja þetta efni í sérstakan hluta. Engu að síður mun ég kynna þetta hugtak í smáatriðum hér og ég tel að efninu í þessum kafla sé best lýst með hugtakinu „tengidreifing“.
Kerfi eru mynduð með því að tengja marga íhluti á réttan hátt og samskipti þeirra innbyrðis eru oft skipulögð á grundvelli viðurkenndra samskiptareglna, til dæmis TCP og UDP. Hins vegar eru þessar samskiptareglur sem slíkar oft ófullnægjandi til að mæta öllum þörfum nútímakerfa, sem oft eru rekin undir miklu álagi og eru einnig mjög háð þörfum notenda. Oft þarf að finna leiðir til að dreifa tengingum til að takast á við svo mikið álag á kerfið.
Þessi dreifing byggir á hinu þekkta (DNS). Slíkt kerfi leyfir umbreytingum lénsheita eins og vegin hringrás og aðferðir sem byggjast á leynd til að hjálpa til við að dreifa álaginu.
er í grundvallaratriðum mikilvægt og nánast öll stór netkerfi sem við fáum í dag eru staðsett á bak við einn eða fleiri álagsjafnara. Álagsjafnarar hjálpa til við að dreifa beiðnum viðskiptavina yfir mörg tiltæk tilvik. Álagsjafnarar koma bæði í vélbúnaði og hugbúnaði, en í reynd þarf oftar að eiga við hugbúnað, td. и . hugmyndalega líka mjög álagsjafnara, þó það sé bil á milli fyrsta og annars . Þessi munur verður að taka með í reikninginn þegar kerfi er hannað út frá þínum þörfum.
Þú ættir líka að vita um (CDN). CDN er alþjóðlegt dreift net proxy-þjóna sem afhendir upplýsingar frá hnútum sem eru landfræðilega staðsettir nær tilteknum notanda. CDN er æskilegt að nota ef þú vinnur með truflanir skrár skrifaðar í JavaScript, CSS og HTML. Auk þess er skýjaþjónusta sem veitir umferðarstjórum algeng í dag, t.d. , sem gefur þér alþjóðlega dreifingu og minni leynd þegar þú vinnur með kraftmikið efni. Slík þjónusta nýtist þó yfirleitt í þeim tilvikum þar sem vinna þarf með ríkisfangslausum vefþjónustum.
Við skulum tala um viðskiptarökfræði. Að skipuleggja viðskiptarökfræði, verkefnaflæði og íhluti
Þannig að okkur tókst að ræða ýmsa innviðaþætti kerfisins. Líklegast hugsar notandinn ekki einu sinni um alla þessa þætti kerfisins þíns og í hreinskilni sagt er honum alveg sama um þá. Notandinn hefur áhuga á hvernig það er að hafa samskipti við kerfið þitt, hvað er hægt að ná með því að gera þetta og einnig hvernig kerfið framkvæmir notendaskipanir, hvað og hvernig það gerir við notendagögn.
Eins og titill þessarar greinar gefur til kynna ætlaði ég að tala um hugbúnaðararkitektúr og kerfishönnun. Í samræmi við það ætlaði ég ekki að fjalla um hugbúnaðarhönnunarmynstur sem lýsa því hvernig hugbúnaðaríhlutir eru búnir til. Hins vegar, því meira sem ég hugsa um það, því meira sýnist mér að mörkin á milli hugbúnaðarhönnunarmynstra og byggingarmynstra séu mjög óskýr og hugtökin tvö eru nátengd. Tökum sem dæmi (uppspretta viðburða). Þegar þú hefur tileinkað þér þetta byggingarmynstur mun það hafa áhrif á næstum alla þætti kerfisins þíns: langtímageymslu gagna, samkvæmnistigið sem notað er í kerfinu þínu, lögun íhlutanna í því osfrv., osfrv. Þess vegna ákvað ég að nefna nokkur byggingarmynstur sem tengjast viðskiptarökfræði beint. Jafnvel þó þessi grein verði að takmarka sig við einfaldan lista hvet ég þig til að kynna þér hana og velta fyrir þér hugmyndunum sem tengjast þessum mynstrum. Gjörðu svo vel:
- Af hugmyndinni , einkum, ,
Samvinnuaðferðir
Það er afar ólíklegt að þú lendir í verkefni sem þátttakandinn sem ber einn ábyrgð á kerfishönnunarferlinu. Þvert á móti þarftu líklegast að eiga samskipti við samstarfsmenn sem starfa bæði innan og utan verkefnis þíns. Í þessu tilviki gætir þú þurft að meta valdar tæknilausnir með samstarfsfólki, greina viðskiptaþarfir og skilja hvernig best er að samhliða verkefnum.
Skyndimynd frá Unsplash
Fyrsta skrefið er að þróa nákvæman og sameiginlegan skilning á því hvert viðskiptamarkmiðið sem þú ert að reyna að ná er og hvaða hreyfanlegu hlutar þú þarft að takast á við. Sérstaklega hóplíkanatækni (atburðarstorm) hjálpa til við að flýta þessu ferli verulega og auka líkurnar á árangri. Þetta verk er hægt að gera fyrir eða eftir að þú útlistar , og síðan dýpka það þegar varan þroskast. Byggt á samkvæmni sem verður náð hér, getur þú líka mótað fyrir það takmarkaða samhengi sem þú vinnur í. Þegar þú þarft að tala um arkitektúr kerfisins þíns gætirðu fundið það gagnlegt , lagt til , sérstaklega þegar þú þarft að skilja hversu mikið þú þarft að fara í smáatriði vandamálsins, sjá fyrir þér hlutina sem þú vilt miðla.
Það er líklega önnur þroskuð tækni um þetta efni sem er ekki síður gagnleg en Domain Driven Design. Hins vegar snúum við einhvern veginn aftur að því að skilja viðfangsefnið, svo þekking og reynsla á þessu sviði ætti að vera gagnlegt fyrir þig.
Heimild: www.habr.com