Hæ Habr!

Í ljósi núverandi atburða vegna kransæðavíruss er fjöldi netþjónustur farinn að fá aukið álag. Til dæmis, Ein af bresku verslunarkeðjunum hætti einfaldlega við pöntunarsíðu sína á netinu., vegna þess að það var ekki nóg afkastagetu. Og það er ekki alltaf hægt að flýta fyrir netþjóni með því einfaldlega að bæta við öflugri búnaði, heldur verður að vinna úr beiðnum viðskiptavina (eða þær fara til keppinauta).

Í þessari grein mun ég tala stuttlega um vinsælar venjur sem gera þér kleift að búa til hraðvirka og bilunarþolna þjónustu. Hins vegar, úr mögulegum þróunarkerfum, valdi ég aðeins þau sem eru núna Auðvelt í notkun. Fyrir hvern hlut hefur þú annað hvort tilbúin bókasöfn eða þú hefur tækifæri til að leysa vandamálið með því að nota skýjapallur.

Lárétt mælikvarði

Einfaldasti og þekktasti punkturinn. Venjulega eru algengustu tvö álagsdreifingarkerfin lárétt og lóðrétt mælikvarði. Í fyrra tilvikinu þú leyfir þjónustu að keyra samhliða og dreifir þannig álaginu á milli þeirra. Í seinni þú pantar öflugri netþjóna eða fínstillir kóðann.

Til dæmis mun ég taka abstrakt skýjaskrárgeymslu, það er einhverja hliðstæðu af OwnCloud, OneDrive, og svo framvegis.

Staðlað mynd af slíkri hringrás er hér að neðan, en hún sýnir aðeins hversu flókið kerfið er. Eftir allt saman þurfum við einhvern veginn að samstilla þjónustuna. Hvað gerist ef notandinn vistar skrá úr spjaldtölvunni og vill síðan skoða hana úr símanum?

Munurinn á aðferðunum: í lóðréttum mælikvarða erum við tilbúin til að auka kraft hnúta og í láréttri mælingu erum við tilbúin að bæta við nýjum hnútum til að dreifa álaginu.

CQRS

Skipunarfyrirspurn Ábyrgðaraðgreining Frekar mikilvægt mynstur, þar sem það gerir mismunandi viðskiptavinum ekki aðeins kleift að tengjast mismunandi þjónustu, heldur einnig að fá sömu viðburðarstrauma. Kostir þess eru ekki svo augljósir fyrir einfalt forrit, en það er afar mikilvægt (og einfalt) fyrir annasama þjónustu. Kjarni þess: komandi og útleið gagnaflæði ættu ekki að skerast. Það er, þú getur ekki sent beiðni og búist við svari, í staðinn sendir þú beiðni til þjónustu A, en færð svar frá þjónustu B.

Fyrsti bónus þessarar aðferðar er hæfileikinn til að rjúfa tenginguna (í víðtækum skilningi þess orðs) á meðan þú framkvæmir langa beiðni. Til dæmis, tökum meira eða minna staðlaða röð:

1. Viðskiptavinurinn sendi beiðni til þjónsins.
2. Miðlarinn byrjaði í langan vinnslutíma.
3. Þjónninn svaraði viðskiptavininum með niðurstöðunni.

Við skulum ímynda okkur að í lið 2 hafi tengingin verið rofin (eða netið hafi verið tengt aftur, eða notandinn hafi farið á aðra síðu og rofið tenginguna). Í þessu tilviki verður erfitt fyrir þjóninn að senda svar til notanda með upplýsingum um hvað nákvæmlega var unnið. Með því að nota CQRS verður röðin aðeins öðruvísi:

1. Viðskiptavinurinn hefur gerst áskrifandi að uppfærslum.
2. Viðskiptavinurinn sendi beiðni til þjónsins.
3. Miðlarinn svaraði „beiðni samþykkt“.
4. Miðlarinn svaraði með niðurstöðunni í gegnum rásina frá punkti „1“.

Eins og þú sérð er kerfið aðeins flóknara. Þar að auki vantar leiðandi beiðni-svar nálgun hér. Hins vegar, eins og þú sérð, mun sambandsrof meðan á vinnslu beiðni stendur ekki leiða til villu. Þar að auki, ef notandinn er í raun tengdur við þjónustuna úr nokkrum tækjum (til dæmis úr farsíma og spjaldtölvu), geturðu gengið úr skugga um að svarið komi til beggja tækjanna.

Athyglisvert er að kóðinn til að vinna úr mótteknum skilaboðum verður sá sami (ekki 100%) bæði fyrir atburði sem voru undir áhrifum frá viðskiptavininum sjálfum og fyrir aðra atburði, þar á meðal frá öðrum viðskiptavinum.

Hins vegar fáum við í raun og veru aukabónus vegna þess að hægt er að meðhöndla einstefnuflæði í hagnýtum stíl (með því að nota RX og svipað). Og þetta er nú þegar alvarlegur plús, þar sem í raun er hægt að gera forritið fullkomlega hvarfgjarnt og einnig með hagnýtri nálgun. Fyrir fituforrit getur þetta verulega sparað þróunar- og stuðningsauðlindir.

Ef við sameinum þessa nálgun með láréttri stærðarstærð, þá fáum við sem bónus möguleika á að senda beiðnir á einn netþjón og fá svör frá öðrum. Þannig getur viðskiptavinurinn valið þá þjónustu sem hentar honum og kerfið inni mun samt geta unnið rétt úr atburðum.

Uppruni viðburða

Eins og þú veist er einn helsti eiginleiki dreifðs kerfis skortur á sameiginlegum tíma, sameiginlegum mikilvægum hluta. Fyrir eitt ferli geturðu gert samstillingu (á sömu mutexes), þar sem þú ert viss um að enginn annar sé að keyra þennan kóða. Hins vegar er þetta hættulegt fyrir dreift kerfi, þar sem það mun krefjast kostnaðar og mun einnig drepa alla fegurð mælingar - allir íhlutir munu enn bíða eftir einum.

Héðan fáum við mikilvæga staðreynd - ekki er hægt að samstilla hratt dreift kerfi, því þá munum við draga úr afköstum. Á hinn bóginn þurfum við oft ákveðna samkvæmni milli þátta. Og fyrir þetta geturðu notað nálgunina með endanlegt samræmi, þar sem tryggt er að ef engar gagnabreytingar verða í einhvern tíma eftir síðustu uppfærslu ("á endanum") munu allar fyrirspurnir skila síðasta uppfærða gildi.

Það er mikilvægt að skilja að fyrir klassíska gagnagrunna er það nokkuð oft notað sterkt samræmi, þar sem hver hnút hefur sömu upplýsingar (þetta næst oft í því tilviki þar sem viðskiptin eru talin stofnuð fyrst eftir að annar þjónninn svarar). Það eru nokkrar slökur hér vegna einangrunarstiganna, en almenn hugmynd er sú sama - þú getur lifað í algjörlega samhæfðum heimi.

Hins vegar skulum við hverfa aftur að upprunalega verkefninu. Ef hægt er að byggja hluta af kerfinu með endanlegt samræmi, þá getum við smíðað eftirfarandi skýringarmynd.

Mikilvægir eiginleikar þessarar aðferðar:

• Hver beiðni sem berast er sett í eina biðröð.
• Meðan á að vinna úr beiðni getur þjónustan einnig sett verkefni í aðrar biðraðir.
• Hver komandi atburður hefur auðkenni (sem er nauðsynlegt fyrir aftvítekningu).
• Biðröðin virkar hugmyndafræðilega samkvæmt „aðeins bæta við“ kerfinu. Þú getur ekki fjarlægt þætti úr því eða endurraðað þeim.
• Biðröðin virkar samkvæmt FIFO kerfinu (afsakið tautology). Ef þú þarft að framkvæma samhliða framkvæmd, þá ættirðu á einu stigi að færa hluti í mismunandi biðraðir.

Leyfðu mér að minna þig á að við erum að íhuga málið með skráageymslu á netinu. Í þessu tilviki mun kerfið líta eitthvað svona út:

Mikilvægt er að þjónustan á skýringarmyndinni þýði ekki endilega sérstakan netþjón. Jafnvel ferlið getur verið það sama. Annað er mikilvægt: hugmyndafræðilega eru þessir hlutir aðskildir á þann hátt að auðvelt er að beita láréttum mælikvarða.

Og fyrir tvo notendur mun skýringarmyndin líta svona út (þjónusta sem er ætluð mismunandi notendum er sýnd í mismunandi litum):

Bónus frá slíkri samsetningu:

• Upplýsingavinnsluþjónusta er aðskilin. Biðraðirnar eru líka aðskildar. Ef við þurfum að auka afköst kerfisins, þá þurfum við bara að setja fleiri þjónustu á fleiri netþjóna.
• Þegar við fáum upplýsingar frá notanda þurfum við ekki að bíða þar til gögnin eru alveg vistuð. Þvert á móti þurfum við bara að svara „ok“ og byrja svo smám saman að vinna. Á sama tíma jafnar röðin út toppa, þar sem að bæta við nýjum hlut á sér stað fljótt og notandinn þarf ekki að bíða eftir fullri ferð í gegnum alla lotuna.
• Sem dæmi bætti ég við aftvíföldunarþjónustu sem reynir að sameina eins skrár. Ef það virkar í langan tíma í 1% tilvika mun viðskiptavinurinn varla taka eftir því (sjá hér að ofan), sem er stór plús, þar sem við þurfum ekki lengur að vera XNUMX% hraði og áreiðanleg.

Hins vegar eru ókostirnir strax sýnilegir:

• Kerfið okkar hefur glatað ströngu samræmi. Þetta þýðir að ef þú ert til dæmis áskrifandi að mismunandi þjónustu, þá geturðu fræðilega séð fengið annað ástand (þar sem ein af þjónustunum gæti ekki haft tíma til að fá tilkynningu frá innri biðröð). Sem önnur afleiðing hefur kerfið nú engan sameiginlegan tíma. Það er, til dæmis er ómögulegt að flokka alla atburði einfaldlega eftir komutíma, þar sem klukkur á milli netþjóna eru kannski ekki samstilltar (að auki er sami tími á tveimur netþjónum útópía).
• Enga atburði er nú einfaldlega hægt að snúa til baka (eins og hægt væri að gera með gagnagrunni). Þess í stað þarftu að bæta við nýjum atburði - bótaatburður, sem mun breyta síðasta ástandi í það sem krafist er. Sem dæmi frá svipuðu svæði: án þess að endurskrifa sögu (sem er slæmt í sumum tilfellum), geturðu ekki afturkallað commit í git, en þú getur gert sérstaka afturköllunarskuldbindingu, sem í rauninni skilar bara gamla ríkinu. Hins vegar verða bæði ranga skuldbindingin og afturköllunin áfram í sögunni.
• Gagnaskemað gæti breyst frá útgáfu til útgáfu, en ekki er lengur hægt að uppfæra gamla atburði í nýja staðalinn (þar sem ekki er hægt að breyta atburðum í grundvallaratriðum).

Eins og þú sérð virkar Event Sourcing vel með CQRS. Ennfremur, að innleiða kerfi með skilvirkum og þægilegum biðröðum, en án þess að aðskilja gagnaflæði, er nú þegar erfitt í sjálfu sér, vegna þess að þú verður að bæta við samstillingarpunktum sem munu óvirkja öll jákvæð áhrif biðröðanna. Með því að beita báðum aðferðum í einu er nauðsynlegt að stilla forritskóðann örlítið. Í okkar tilviki, þegar þú sendir skrá á netþjóninn, kemur svarið aðeins „allt í lagi“, sem þýðir aðeins að „aðgerðin við að bæta við skránni var vistuð. Formlega þýðir þetta ekki að gögnin séu nú þegar tiltæk á öðrum tækjum (td getur aftvíföldunarþjónustan endurbyggt vísitöluna). Hins vegar, eftir nokkurn tíma, mun viðskiptavinurinn fá tilkynningu í stíl við „skrá X hefur verið vistuð.

Þar af leiðandi:

• Fjöldi skráasendingarstaða er að aukast: í stað hins klassíska „skrá send“ fáum við tvær: „skránni hefur verið bætt við biðröðina á þjóninum“ og „skráin hefur verið vistuð í geymslu.“ Hið síðarnefnda þýðir að önnur tæki geta þegar byrjað að taka á móti skránni (aðlagað fyrir þá staðreynd að biðraðir starfa á mismunandi hraða).
• Vegna þess að skilaupplýsingarnar koma nú eftir mismunandi leiðum þurfum við að koma með lausnir til að fá vinnslustöðu skrárinnar. Sem afleiðing af þessu: ólíkt klassísku beiðni-svari, er hægt að endurræsa biðlarann ​​á meðan unnið er úr skránni, en staða þessarar vinnslu sjálfrar verður rétt. Þar að auki virkar þessi hlutur í rauninni út úr kassanum. Þar af leiðandi: Við erum nú umburðarlyndari gagnvart mistökum.

Sharding

Eins og lýst er hér að ofan skortir viðburðauppsprettukerfi strangt samræmi. Þetta þýðir að við getum notað nokkrar geymslur án samstillingar á milli þeirra. Þegar við nálgumst vandamál okkar getum við:

• Aðgreina skrár eftir tegund. Til dæmis er hægt að afkóða myndir/myndbönd og velja skilvirkara snið.
• Aðskilið reikninga eftir löndum. Vegna margra laga getur þetta verið krafist, en þetta arkitektúrkerfi veitir slíkt tækifæri sjálfkrafa

Ef þú vilt flytja gögn úr einni geymslu í aðra, þá duga ekki lengur staðlaðar leiðir. Því miður, í þessu tilfelli, þarftu að stöðva biðröðina, gera flutninginn og hefja hana síðan. Í almennu tilvikinu er ekki hægt að flytja gögn „í flugi“, hins vegar, ef viðburðarröð er geymd að fullu og þú ert með skyndimyndir af fyrri geymslustöðu, þá getum við endurspilað atburðina sem hér segir:

• Í Event Source hefur hver atburður sitt auðkenni (helst ekki minnkandi). Þetta þýðir að við getum bætt reit við geymsluna - auðkenni síðasta unnar þáttar.
• Við afritum biðröðina þannig að hægt sé að vinna úr öllum atburðum fyrir nokkrar sjálfstæðar geymslur (fyrsta er sú sem gögnin eru þegar geymd í og ​​sú seinni er ný, en samt tóm). Seinni röðin er auðvitað ekki í vinnslu ennþá.
• Við ræsum seinni biðröðina (það er, við byrjum að spila atburði aftur).
• Þegar nýja biðröðin er tiltölulega tóm (þ.e. að meðaltali tímamismunur á milli þess að bæta við einingu og sækja hann er ásættanlegt), geturðu byrjað að skipta um lesendur yfir í nýju geymsluna.

Eins og þú sérð höfðum við ekki, og höfum enn ekki, strangt samræmi í kerfinu okkar. Það er aðeins að lokum samræmi, það er trygging fyrir því að atburðir séu gerðir í sömu röð (en hugsanlega með mismunandi töfum). Og með því að nota þetta getum við tiltölulega auðveldlega flutt gögn án þess að stöðva kerfið hinum megin á hnettinum.

Svona, áframhaldandi dæmi okkar um netgeymslu fyrir skrár, gefur slíkur arkitektúr okkur nú þegar fjölda bónusa:

• Við getum fært hluti nær notendum á kraftmikinn hátt. Þannig geturðu bætt gæði þjónustunnar.
• Við gætum geymt einhver gögn innan fyrirtækja. Til dæmis krefjast Enterprise notendur oft að gögn þeirra séu geymd í stjórnuðum gagnaverum (til að forðast gagnaleka). Með klippingu getum við auðveldlega stutt þetta. Og verkefnið er enn auðveldara ef viðskiptavinurinn er með samhæft ský (td, Azure hýst sjálf).
• Og það mikilvægasta er að við þurfum ekki að gera þetta. Þegar öllu er á botninn hvolft, til að byrja með, værum við nokkuð ánægð með eina geymslu fyrir alla reikninga (til að byrja fljótt að vinna). Og lykilatriði þessa kerfis er að þó það sé stækkanlegt, þá er það frekar einfalt á upphafsstigi. Þú þarft bara ekki að skrifa strax kóða sem virkar með milljón aðskildum sjálfstæðum biðröðum osfrv. Ef nauðsyn krefur er hægt að gera þetta í framtíðinni.

Static Content Hosting

Þetta atriði kann að virðast nokkuð augljóst, en það er samt nauðsynlegt fyrir meira eða minna venjulegt hlaðið forrit. Kjarni þess er einfaldur: öllu kyrrstöðu efni er dreift ekki frá sama netþjóni þar sem forritið er staðsett, heldur frá sérstökum sem eru sérstaklega tileinkaðir þessu verkefni. Þess vegna eru þessar aðgerðir gerðar hraðar (skilyrt nginx þjónar skrám hraðar og ódýrara en Java netþjónn). Auk CDN arkitektúr (Content Delivery Network) gerir okkur kleift að staðsetja skrárnar okkar nær endanotendum, sem hefur jákvæð áhrif á þægindin við að vinna með þjónustuna.

Einfaldasta og staðlaðasta dæmið um kyrrstætt efni er sett af skriftum og myndum fyrir vefsíðu. Allt er einfalt með þá - þeir eru þekktir fyrirfram, síðan er skjalasafninu hlaðið upp á CDN netþjóna, þaðan sem þeim er dreift til endanotenda.

Hins vegar, í raun og veru, fyrir kyrrstætt efni, geturðu notað nálgun sem er nokkuð svipuð lambda arkitektúr. Snúum okkur aftur að verkefninu okkar (skráageymslu á netinu), þar sem við þurfum að dreifa skrám til notenda. Einfaldasta lausnin er að búa til þjónustu sem, fyrir hverja notendabeiðni, gerir allar nauðsynlegar athuganir (heimild o.s.frv.) og hleður síðan niður skránni beint úr geymslunni okkar. Helsti ókosturinn við þessa nálgun er að kyrrstæðu efni (og skrá með ákveðinni endurskoðun er í raun kyrrstætt efni) er dreift af sama netþjóni sem inniheldur viðskiptarökfræðina. Í staðinn geturðu búið til eftirfarandi skýringarmynd:

• Miðlarinn veitir niðurhalsslóð. Það getur verið af formi file_id + key, þar sem lykill er smástafræn undirskrift sem gefur rétt til aðgangs að auðlindinni næsta sólarhringinn.
• Skránni er dreift með einföldum nginx með eftirfarandi valkostum:
  • Skyndiminni efnis. Þar sem þessi þjónusta getur verið staðsett á sérstökum netþjóni höfum við skilið eftir okkur varasjóð fyrir framtíðina með getu til að geyma allar nýjustu niðurhalaðar skrárnar á disknum.
  • Athugar lykilinn þegar tenging er stofnuð
• Valfrjálst: streymandi efnisvinnsla. Til dæmis, ef við þjöppum öllum skrám í þjónustunni, þá getum við gert uppþjöppun beint í þessari einingu. Þar af leiðandi: IO aðgerðir eru gerðar þar sem þær eiga heima. Skjalavörður í Java mun auðveldlega úthluta miklu aukaminni, en að endurskrifa þjónustu með viðskiptarökfræði yfir í Rust/C++ skilyrði getur líka verið árangurslaust. Í okkar tilviki eru mismunandi ferlar (eða jafnvel þjónustur) notaðir og því getum við á skilvirkan hátt aðskilið viðskiptarökfræði og IO aðgerðir.

Þetta kerfi er ekki mjög líkt því að dreifa kyrrstæðu efni (þar sem við hleðum ekki upp öllum kyrrstöðupakkanum einhvers staðar), en í raun og veru snýst þessi nálgun einmitt um að dreifa óbreytanlegum gögnum. Þar að auki er hægt að alhæfa þetta kerfi yfir í önnur tilvik þar sem innihaldið er ekki einfaldlega kyrrstætt, heldur er hægt að tákna það sem safn óbreytanlegra og óeyðanlegra blokka (þó hægt sé að bæta þeim við).

Sem annað dæmi (til styrkingar): ef þú hefur unnið með Jenkins/TeamCity, þá veistu að báðar lausnirnar eru skrifaðar í Java. Báðir eru þeir Java ferli sem sér um bæði byggingaskipan og innihaldsstjórnun. Sérstaklega hafa þeir báðir verkefni eins og „flytja skrá / möppu frá þjóninum. Sem dæmi: gefa út gripi, flytja frumkóða (þegar umboðsmaðurinn sækir kóðann ekki beint úr geymslunni, en þjónninn gerir það fyrir hann), aðgangur að annálum. Öll þessi verkefni eru mismunandi hvað varðar IO álag þeirra. Það er, það kemur í ljós að þjónninn sem ber ábyrgð á flóknum viðskiptarökfræði verður á sama tíma að geta á áhrifaríkan hátt ýtt miklu gagnaflæði í gegnum sig. Og það sem er áhugaverðast er að hægt er að framselja slíka aðgerð til sama nginx samkvæmt nákvæmlega sama kerfi (nema að gagnalyklinum ætti að bæta við beiðnina).

Hins vegar, ef við snúum aftur til kerfisins okkar, fáum við svipaða skýringarmynd:

Eins og þú sérð er kerfið orðið verulega flóknara. Nú er það ekki bara smáferli sem geymir skrár á staðnum. Nú er það sem þarf ekki einfaldasta stuðninginn, API útgáfustýringu osfrv. Þess vegna, eftir að allar skýringarmyndir hafa verið teiknaðar, er best að meta í smáatriðum hvort stækkanleiki sé þess virði kostnaðurinn. Hins vegar, ef þú vilt geta stækkað kerfið (þar á meðal til að vinna með enn stærri fjölda notenda), þá verður þú að fara í svipaðar lausnir. En þar af leiðandi er kerfið byggingarlega tilbúið fyrir aukið álag (nánast alla hluti er hægt að klóna fyrir lárétta mælikvarða). Hægt er að uppfæra kerfið án þess að stöðva það (einfaldlega hægt á sumum aðgerðum).

Eins og ég sagði í upphafi, þá er fjöldi netþjónustur farinn að fá aukið álag. Og sumir þeirra fóru einfaldlega að hætta að virka rétt. Reyndar biluðu kerfin einmitt á því augnabliki þegar fyrirtækið átti að græða peninga. Það er, í stað þess að fresta afhendingu, í stað þess að stinga upp á við viðskiptavini „skipuleggja afhendingu þína fyrir næstu mánuði,“ sagði kerfið einfaldlega „farðu til keppinauta þinna. Í raun er þetta verð lágrar framleiðni: tap verður einmitt þegar hagnaðurinn væri mestur.

Ályktun

Allar þessar aðferðir voru þekktar áður. Sama VK hefur lengi notað hugmyndina um Static Content Hosting til að birta myndir. Margir netleikir nota Sharding kerfið til að skipta leikmönnum í svæði eða til að aðgreina leikjastaði (ef heimurinn sjálfur er einn). Viðburðauppspretta nálgun er virk notuð í tölvupósti. Flest viðskiptaforrit þar sem gögn eru stöðugt að berast eru í raun byggð á CQRS nálgun til að geta síað gögnin sem berast. Jæja, lárétt mælikvarði hefur verið notaður í mörgum þjónustum í nokkuð langan tíma.

Hins vegar, mikilvægast, er orðið mjög auðvelt að nota öll þessi mynstur í nútíma forritum (ef þau eiga við, auðvitað). Ský bjóða upp á Sharding og lárétta skala strax, sem er miklu auðveldara en að panta mismunandi sérstaka netþjóna í mismunandi gagnaver sjálfur. CQRS er orðið miklu auðveldara, þó ekki væri nema vegna þróunar bókasöfna eins og RX. Fyrir um 10 árum síðan gat sjaldgæf vefsíða stutt þetta. Uppruni viðburða er líka ótrúlega auðvelt að setja upp þökk sé tilbúnum ílátum með Apache Kafka. Fyrir 10 árum hefði þetta verið nýjung, nú tíðkast það. Það er það sama með Static Content Hosting: Vegna þægilegri tækni (þar á meðal þeirrar staðreyndar að það er ítarleg skjöl og stór gagnagrunnur af svörum) hefur þessi nálgun orðið enn einfaldari.

Fyrir vikið er útfærsla nokkurra frekar flókinna byggingarmynstra nú orðin mun einfaldari, sem þýðir að betra er að skoða það betur fyrirfram. Ef í tíu ára gamalli umsókn var ein af lausnunum hér að ofan hætt vegna mikils kostnaðar við innleiðingu og rekstur, geturðu nú, í nýju forriti, eða eftir endurþáttun, búið til þjónustu sem verður þegar byggingarfræðilega bæði stækkanleg ( hvað varðar frammistöðu) og tilbúnar að nýjum beiðnum frá viðskiptavinum (til dæmis til að staðsetja persónuupplýsingar).

Og síðast en ekki síst: vinsamlegast ekki nota þessar aðferðir ef þú ert með einfalt forrit. Já, þeir eru fallegir og áhugaverðir, en fyrir síðu með hámarksheimsókn upp á 100 manns geturðu oft komist af með klassískan einlita (allavega að utan, allt inni má skipta í einingar osfrv.).

Heimild: www.habr.com