Čau Habr!

Ņemot vērā pašreizējos notikumus koronavīrusa dēļ, vairāki interneta pakalpojumi ir sākuši saņemt pastiprinātu slodzi. Piemēram, Viena no Apvienotās Karalistes mazumtirdzniecības ķēdēm vienkārši pārtrauca savu tiešsaistes pasūtīšanas vietni., jo nebija pietiekami daudz jaudas. Un ne vienmēr ir iespējams paātrināt servera darbību, vienkārši pievienojot jaudīgāku aprīkojumu, bet klientu pieprasījumi ir jāapstrādā (vai tie tiks nosūtīti konkurentiem).

Šajā rakstā īsumā pastāstīšu par populārām praksēm, kas ļaus izveidot ātru un defektu izturīgu servisu. Taču no iespējamām attīstības shēmām atlasīju tikai tās, kas šobrīd ir viegli izmantot. Katram vienumam jums ir vai nu gatavas bibliotēkas, vai arī jums ir iespēja atrisināt problēmu, izmantojot mākoņa platformu.

Horizontālā mērogošana

Vienkāršākais un pazīstamākais punkts. Parasti visizplatītākās divas slodzes sadales shēmas ir horizontālā un vertikālā mērogošana. Pirmajā gadījumā jūs ļaujat pakalpojumiem darboties paralēli, tādējādi sadalot slodzi starp tiem. Otrajā pasūtāt jaudīgākus serverus vai optimizējat kodu.

Piemēram, es ņemšu abstraktu mākoņdatņu krātuvi, tas ir, kādu OwnCloud, OneDrive un tā tālāk analogu.

Zemāk ir šādas shēmas standarta attēls, taču tas tikai parāda sistēmas sarežģītību. Galu galā mums ir kaut kā jāsinhronizē pakalpojumi. Kas notiek, ja lietotājs saglabā failu no planšetdatora un pēc tam vēlas to skatīt no tālruņa?

Atšķirība starp pieejām: vertikālajā mērogošanā esam gatavi palielināt mezglu jaudu, savukārt horizontālajā mērogošanā esam gatavi pievienot jaunus mezglus, lai sadalītu slodzi.

CQRS

Komandu vaicājuma atbildības nodalīšana Diezgan svarīgs modelis, jo tas ļauj dažādiem klientiem ne tikai izveidot savienojumu ar dažādiem pakalpojumiem, bet arī saņemt vienas un tās pašas notikumu straumes. Tās priekšrocības nav tik acīmredzamas vienkāršai lietojumprogrammai, taču tas ir ārkārtīgi svarīgi (un vienkārši) aizņemtam pakalpojumam. Tās būtība: ienākošās un izejošās datu plūsmas nedrīkst krustoties. Tas ir, jūs nevarat nosūtīt pieprasījumu un gaidīt atbildi; tā vietā jūs nosūtāt pieprasījumu pakalpojumam A, bet saņemat atbildi no pakalpojuma B.

Šīs pieejas pirmais bonuss ir spēja pārtraukt savienojumu (šā vārda plašā nozīmē), izpildot ilgu pieprasījumu. Piemēram, ņemsim vairāk vai mazāk standarta secību:

1. Klients nosūtīja serverim pieprasījumu.
2. Serveris sāka ilgu apstrādes laiku.
3. Serveris atbildēja klientam ar rezultātu.

Iedomāsimies, ka 2. punktā savienojums tika pārtraukts (vai tīkls tika atkārtoti savienots, vai lietotājs devās uz citu lapu, pārtraucot savienojumu). Šajā gadījumā serverim būs grūti nosūtīt lietotājam atbildi ar informāciju par to, kas tieši tika apstrādāts. Izmantojot CQRS, secība būs nedaudz atšķirīga:

1. Klients ir abonējis atjauninājumus.
2. Klients nosūtīja serverim pieprasījumu.
3. Serveris atbildēja "pieprasījums pieņemts".
4. Serveris atbildēja ar rezultātu caur kanālu no punkta “1”.

Kā redzat, shēma ir nedaudz sarežģītāka. Turklāt šeit trūkst intuitīvās pieprasījuma-atbildes pieejas. Tomēr, kā redzat, savienojuma pārtraukums pieprasījuma apstrādes laikā neizraisīs kļūdu. Turklāt, ja lietotājs patiešām ir pieslēdzies pakalpojumam no vairākām ierīcēm (piemēram, no mobilā tālruņa un planšetdatora), varat pārliecināties, ka atbilde tiek saņemta abās ierīcēs.

Interesanti, ka ienākošo ziņojumu apstrādes kods kļūst vienāds (nevis 100%) gan notikumiem, kurus ietekmējis pats klients, gan citiem notikumiem, tostarp no citiem klientiem.

Taču realitātē mēs iegūstam papildus bonusu, pateicoties tam, ka vienvirziena plūsmu var apstrādāt funkcionālā stilā (izmantojot RX un tamlīdzīgi). Un tas jau ir nopietns pluss, jo būtībā lietojumprogrammu var padarīt pilnīgi reaģējošu, turklāt izmantojot funkcionālu pieeju. Treknajām programmām tas var ievērojami ietaupīt attīstības un atbalsta resursus.

Ja šo pieeju apvienojam ar horizontālo mērogošanu, tad kā bonusu iegūstam iespēju nosūtīt pieprasījumus vienam serverim un saņemt atbildes no cita. Tādējādi klients var izvēlēties sev ērto pakalpojumu, un iekšā esošā sistēma joprojām spēs pareizi apstrādāt notikumus.

Pasākumu piegāde

Kā zināms, viena no izplatītās sistēmas galvenajām iezīmēm ir kopīga laika, kopīgas kritiskās sadaļas trūkums. Vienam procesam varat veikt sinhronizāciju (uz tiem pašiem mutexes), kuras ietvaros esat pārliecināts, ka neviens cits neizpilda šo kodu. Tomēr tas ir bīstami sadalītai sistēmai, jo tas prasīs papildu izmaksas, kā arī iznīcinās visu mērogošanas skaistumu - visi komponenti joprojām gaidīs vienu.

No šejienes mēs iegūstam svarīgu faktu - ātri sadalītu sistēmu nevar sinhronizēt, jo tad mēs samazināsim veiktspēju. No otras puses, mums bieži ir nepieciešama noteikta konsekvence starp komponentiem. Un šim nolūkam jūs varat izmantot pieeju ar iespējamā konsekvence, kur tiek garantēts, ka, ja kādu laiku pēc pēdējās atjaunināšanas (“galu galā”) dati netiek mainīti, visi vaicājumi atgriezīs pēdējo atjaunināto vērtību.

Ir svarīgi saprast, ka klasiskajām datu bāzēm to izmanto diezgan bieži spēcīga konsistence, kur katram mezglam ir viena un tā pati informācija (to bieži panāk, ja darījums tiek uzskatīts par veiktu tikai pēc otrā servera atbildes). Šeit ir daži atslābumi izolētības līmeņu dēļ, bet kopējā doma paliek nemainīga - jūs varat dzīvot pilnīgi harmonizētā pasaulē.

Tomēr atgriezīsimies pie sākotnējā uzdevuma. Ja daļu sistēmas var uzbūvēt ar iespējamā konsekvence, tad mēs varam izveidot šādu diagrammu.

Šīs pieejas svarīgas iezīmes:

• Katrs ienākošais pieprasījums tiek ievietots vienā rindā.
• Apstrādājot pieprasījumu, pakalpojums var arī ievietot uzdevumus citās rindās.
• Katram ienākošajam notikumam ir identifikators (kas nepieciešams dublēšanas atcelšanai).
• Rinda ideoloģiski darbojas pēc shēmas “tikai pievienot”. Jūs nevarat no tā noņemt elementus vai tos pārkārtot.
• Rinda darbojas pēc FIFO shēmas (atvainojos par tautoloģiju). Ja jums ir jāveic paralēla izpilde, tad vienā posmā jums vajadzētu pārvietot objektus uz dažādām rindām.

Atgādināšu, ka mēs apsveram lietu par failu glabāšanu tiešsaistē. Šajā gadījumā sistēma izskatīsies apmēram šādi:

Ir svarīgi, lai pakalpojumi diagrammā nenozīmētu atsevišķu serveri. Pat process var būt vienāds. Svarīga ir vēl viena lieta: idejiski šīs lietas ir nodalītas tā, lai varētu viegli pielietot horizontālo mērogošanu.

Un diviem lietotājiem diagramma izskatīsies šādi (pakalpojumi, kas paredzēti dažādiem lietotājiem, ir norādīti dažādās krāsās):

Bonusi no šādas kombinācijas:

• Informācijas apstrādes pakalpojumi ir nodalīti. Arī rindas ir nodalītas. Ja mums ir jāpalielina sistēmas caurlaidspēja, mums vienkārši jāuzsāk vairāk pakalpojumu vairākos serveros.
• Kad mēs saņemam informāciju no lietotāja, mums nav jāgaida, līdz dati tiek pilnībā saglabāti. Gluži pretēji, mums vienkārši jāatbild “ok” un tad pamazām jāsāk strādāt. Tajā pašā laikā rinda izlīdzina virsotnes, jo jauna objekta pievienošana notiek ātri, un lietotājam nav jāgaida pilnīga visa cikla iziešana.
• Kā piemēru es pievienoju dublēšanas pakalpojumu, kas mēģina sapludināt identiskus failus. Ja tas darbojas ilgstoši 1% gadījumu, klients to gandrīz nepamanīs (skatīt augstāk), kas ir liels pluss, jo mums vairs netiek prasīts XNUMX% ātrums un uzticamība.

Tomēr trūkumi ir uzreiz redzami:

• Mūsu sistēma ir zaudējusi savu stingro konsekvenci. Tas nozīmē, ka, piemēram, abonējot dažādus pakalpojumus, teorētiski varat iegūt citu stāvokli (jo vienam no pakalpojumiem var nebūt laika saņemt paziņojumu no iekšējās rindas). Citas sekas ir tas, ka sistēmai tagad nav kopīga laika. Tas ir, nav iespējams, piemēram, kārtot visus notikumus vienkārši pēc ierašanās laika, jo pulksteņi starp serveriem var nebūt sinhroni (turklāt vienāds laiks divos serveros ir utopija).
• Nevienu notikumu tagad nevar vienkārši atcelt (kā to var izdarīt ar datu bāzi). Tā vietā jums jāpievieno jauns notikums − kompensācijas pasākums, kas mainīs pēdējo stāvokli uz vajadzīgo. Kā piemērs no līdzīgas jomas: nepārrakstot vēsturi (kas dažos gadījumos ir slikti), jūs nevarat atsaukt apņemšanos git formātā, taču varat izveidot īpašu atcelšanas apņemšanās, kas būtībā tikai atgriež veco stāvokli. Tomēr gan kļūdainā apņemšanās, gan atcelšana paliks vēsturē.
• Datu shēma var mainīties atkarībā no laidiena, taču vecos notikumus vairs nevarēs atjaunināt uz jauno standartu (jo notikumus principā nevar mainīt).

Kā redzat, notikumu avots labi darbojas ar CQRS. Turklāt sistēmas ieviešana ar efektīvām un ērtām rindām, bet bez datu plūsmu atdalīšanas jau pati par sevi ir sarežģīta, jo būs jāpievieno sinhronizācijas punkti, kas neitralizēs visu rindu pozitīvo efektu. Piemērojot abas pieejas vienlaikus, ir nepieciešams nedaudz pielāgot programmas kodu. Mūsu gadījumā, nosūtot failu uz serveri, atbilde nāk tikai “ok”, kas nozīmē tikai to, ka “faila pievienošanas darbība tika saglabāta”. Formāli tas nenozīmē, ka dati jau ir pieejami citās ierīcēs (piemēram, dedublikācijas pakalpojums var atjaunot indeksu). Tomēr pēc kāda laika klients saņems paziņojumu stilā “fails X ir saglabāts”.

Rezultātā:

• Failu nosūtīšanas statusu skaits palielinās: klasiskā “fails nosūtīts” vietā mēs iegūstam divus: “fails ir pievienots rindai serverī” un “fails ir saglabāts krātuvē”. Pēdējais nozīmē, ka citas ierīces jau var sākt saņemt failu (pielāgots tam, ka rindas darbojas dažādos ātrumos).
• Tā kā iesniegšanas informācija tagad tiek saņemta pa dažādiem kanāliem, mums ir jārod risinājumi faila apstrādes statusa saņemšanai. Rezultātā: atšķirībā no klasiskā pieprasījuma-atbildes, failu apstrādes laikā klientu var restartēt, taču pašas apstrādes statuss būs pareizs. Turklāt šis vienums būtībā darbojas ārpus kastes. Rezultātā mēs tagad esam iecietīgāki pret neveiksmēm.

Sharding

Kā aprakstīts iepriekš, notikumu avotu sistēmām trūkst stingras konsekvences. Tas nozīmē, ka mēs varam izmantot vairākas krātuves bez sinhronizācijas starp tām. Pievēršoties savai problēmai, mēs varam:

• Atdaliet failus pēc veida. Piemēram, attēlus/video var atšifrēt un izvēlēties efektīvāku formātu.
• Atsevišķi konti pēc valsts. Daudzu likumu dēļ tas var būt nepieciešams, taču šī arhitektūras shēma šādu iespēju nodrošina automātiski

Ja vēlaties pārsūtīt datus no vienas krātuves uz citu, tad vairs nepietiek ar standarta līdzekļiem. Diemžēl šajā gadījumā jums ir jāpārtrauc rinda, jāveic migrācija un pēc tam jāsāk. Vispārīgā gadījumā datus nevar pārsūtīt “lidojumā”, taču, ja notikumu rinda ir pilnībā saglabāta un jums ir iepriekšējo krātuves stāvokļu momentuzņēmumi, notikumus varam atskaņot šādi:

• Notikuma avotā katram notikumam ir savs identifikators (ideālā gadījumā, kas nesamazinās). Tas nozīmē, ka krātuvei varam pievienot lauku - pēdējā apstrādātā elementa id.
• Mēs dublējam rindu, lai visus notikumus varētu apstrādāt vairākām neatkarīgām krātuvēm (pirmā ir tā, kurā dati jau ir glabāti, bet otrā ir jauna, bet vēl tukša). Otrā rinda, protams, vēl netiek apstrādāta.
• Mēs palaižam otro rindu (tas ir, mēs sākam notikumu atkārtošanu).
• Kad jaunā rinda ir salīdzinoši tukša (tas ir, vidējā laika starpība starp elementa pievienošanu un izgūšanu ir pieņemama), varat sākt lasītāju pārslēgšanu uz jauno krātuvi.

Kā redzat, mūsu sistēmā nebija un joprojām nav stingras konsekvences. Pastāv tikai iespējamā konsekvence, tas ir, garantija, ka notikumi tiek apstrādāti tādā pašā secībā (bet, iespējams, ar atšķirīgu kavēšanos). Un, izmantojot to, mēs varam salīdzinoši viegli pārsūtīt datus, neapturot sistēmu, uz otru zemeslodes pusi.

Tādējādi, turpinot mūsu piemēru par failu glabāšanu tiešsaistē, šāda arhitektūra jau sniedz mums vairākas priekšrocības:

• Mēs varam dinamiskā veidā pārvietot objektus tuvāk lietotājiem. Tādā veidā jūs varat uzlabot pakalpojuma kvalitāti.
• Mēs varam uzglabāt dažus datus uzņēmumos. Piemēram, uzņēmumu lietotāji bieži pieprasa, lai viņu dati tiktu glabāti kontrolētos datu centros (lai izvairītos no datu noplūdes). Izmantojot sadalīšanu, mēs to varam viegli atbalstīt. Un uzdevums ir vēl vienkāršāks, ja klientam ir saderīgs mākonis (piemēram, Azure paša mitināts).
• Un vissvarīgākais ir tas, ka mums tas nav jādara. Galu galā mēs būtu ļoti apmierināti ar vienu krātuvi visiem kontiem (lai ātri sāktu darbu). Un šīs sistēmas galvenā iezīme ir tā, ka, lai gan tā ir paplašināma, sākotnējā posmā tā ir diezgan vienkārša. Jums vienkārši nav uzreiz jāraksta kods, kas darbojas ar miljonu atsevišķu neatkarīgu rindu utt. Ja nepieciešams, to var izdarīt nākotnē.

Statiskā satura mitināšana

Šis punkts var šķist diezgan acīmredzams, taču tas joprojām ir nepieciešams vairāk vai mazāk standarta ielādes lietojumprogrammai. Tās būtība ir vienkārša: viss statiskais saturs tiek izplatīts nevis no tā paša servera, kurā atrodas lietojumprogramma, bet gan no īpašiem, kas īpaši paredzēti šim uzdevumam. Rezultātā šīs darbības tiek veiktas ātrāk (nosacījuma nginx apkalpo failus ātrāk un lētāk nekā Java serveris). Plus CDN arhitektūra (Satura piegādes tīkls) ļauj mums atrast mūsu failus tuvāk gala lietotājiem, kas pozitīvi ietekmē darba ērtības ar pakalpojumu.

Vienkāršākais un standarta statiskā satura piemērs ir vietnes skriptu un attēlu kopa. Ar tiem viss ir vienkārši – tie ir zināmi iepriekš, pēc tam arhīvs tiek augšupielādēts CDN serveros, no kurienes tie tiek izplatīti gala lietotājiem.

Tomēr patiesībā statiskam saturam varat izmantot pieeju, kas ir nedaudz līdzīga lambda arhitektūrai. Atgriezīsimies pie sava uzdevuma (tiešsaistes failu krātuve), kurā mums ir jāizplata faili lietotājiem. Vienkāršākais risinājums ir izveidot pakalpojumu, kas pēc katra lietotāja pieprasījuma veic visas nepieciešamās pārbaudes (autorizāciju utt.) un pēc tam lejupielādē failu tieši no mūsu krātuves. Šīs pieejas galvenais trūkums ir tāds, ka statisko saturu (un fails ar noteiktu pārskatīšanu faktiski ir statisks saturs) izplata tas pats serveris, kurā ir biznesa loģika. Tā vietā varat izveidot šādu diagrammu:

• Serveris nodrošina lejupielādes URL. Tā var būt formā file_id + key, kur atslēga ir mini-digitālais paraksts, kas dod tiesības piekļūt resursam nākamajās XNUMX stundās.
• Failu izplata vienkāršs nginx ar šādām opcijām:
  • Satura kešatmiņa. Tā kā šis pakalpojums var atrasties uz atsevišķa servera, mēs esam atstājuši sev rezervi nākotnei ar iespēju visus jaunākos lejupielādētos failus saglabāt diskā.
  • Atslēgas pārbaude savienojuma izveides laikā
• Pēc izvēles: straumēšanas satura apstrāde. Piemēram, ja mēs saspiežam visus pakalpojuma failus, mēs varam veikt izsaiņošanu tieši šajā modulī. Rezultātā: IO darbības tiek veiktas tur, kur tām ir nozīme. Java arhivētājs viegli atvēlēs daudz papildu atmiņas, taču pakalpojuma ar biznesa loģiku pārrakstīšana Rust/C++ nosacījumos var būt arī neefektīva. Mūsu gadījumā tiek izmantoti dažādi procesi (vai pat pakalpojumi), un tāpēc mēs varam diezgan efektīvi nodalīt biznesa loģiku un IO darbības.

Šī shēma nav ļoti līdzīga statiskā satura izplatīšanai (jo mēs nekur neaugšupielādējam visu statisko pakotni), taču patiesībā šī pieeja ir tieši saistīta ar nemainīgu datu izplatīšanu. Turklāt šo shēmu var vispārināt citos gadījumos, kad saturs nav vienkārši statisks, bet to var attēlot kā nemainīgu un neizdzēšamu bloku kopu (lai gan tos var pievienot).

Kā vēl viens piemērs (pastiprināšanai): ja esat strādājis ar Jenkins/TeamCity, tad zināt, ka abi risinājumi ir rakstīti Java. Abi no tiem ir Java process, kas apstrādā gan veidošanas orķestrēšanu, gan satura pārvaldību. Jo īpaši viņiem abiem ir tādi uzdevumi kā “pārsūtīt failu/mapi no servera”. Piemēram: artefaktu izdošana, pirmkoda pārsūtīšana (kad aģents nevis lejupielādē kodu tieši no repozitorija, bet serveris to dara viņa vietā), piekļuve žurnāliem. Visi šie uzdevumi atšķiras pēc to IO slodzes. Tas ir, izrādās, ka serverim, kas atbild par sarežģītu biznesa loģiku, vienlaikus ir jāspēj efektīvi izspiest lielas datu plūsmas caur sevi. Un pats interesantākais ir tas, ka šādu darbību var deleģēt tam pašam nginx pēc tieši tādas pašas shēmas (izņemot to, ka pieprasījumam jāpievieno datu atslēga).

Tomēr, ja mēs atgriežamies mūsu sistēmā, mēs iegūstam līdzīgu diagrammu:

Kā redzat, sistēma ir kļuvusi radikāli sarežģītāka. Tagad tas nav tikai mini process, kas glabā failus lokāli. Tagad nav vajadzīgs vienkāršākais atbalsts, API versiju kontrole utt. Tāpēc pēc visu diagrammu uzzīmēšanas vislabāk ir detalizēti izvērtēt, vai paplašināmība ir izmaksu vērta. Taču, ja vēlaties sistēmu paplašināt (tai skaitā strādāt ar vēl lielāku lietotāju skaitu), tad nāksies meklēt līdzīgus risinājumus. Bet rezultātā sistēma ir arhitektoniski gatava palielinātai slodzei (gandrīz katru komponentu var klonēt horizontālai mērogošanai). Sistēmu var atjaunināt, to neapturot (vienkārši dažas darbības tiks nedaudz palēninātas).

Kā jau teicu pašā sākumā, tagad vairāki interneta pakalpojumi ir sākuši saņemt pastiprinātu slodzi. Un daži no tiem vienkārši pārstāja darboties pareizi. Patiesībā sistēmas neizdevās tieši tajā brīdī, kad uzņēmumam vajadzēja pelnīt naudu. Tas ir, tā vietā, lai atliktu piegādi, tā vietā, lai ieteiktu klientiem “plānot piegādi nākamajiem mēnešiem”, sistēma vienkārši teica: “Dodieties pie saviem konkurentiem”. Faktiski tā ir zemas produktivitātes cena: zaudējumi radīsies tieši tad, kad peļņa būs vislielākā.

Secinājums

Visas šīs pieejas bija zināmas iepriekš. Tas pats VK jau sen ir izmantojis statiskā satura mitināšanas ideju, lai parādītu attēlus. Daudzas tiešsaistes spēles izmanto Sharding shēmu, lai sadalītu spēlētājus reģionos vai atdalītu spēļu vietas (ja pasaule ir tāda). Event Sourcing pieeja tiek aktīvi izmantota e-pastā. Lielākā daļa tirdzniecības lietojumprogrammu, kurās pastāvīgi tiek saņemti dati, faktiski ir balstītas uz CQRS pieeju, lai varētu filtrēt saņemtos datus. Nu, horizontālā mērogošana daudzos pakalpojumos ir izmantota diezgan ilgu laiku.

Tomēr vissvarīgākais ir tas, ka visi šie modeļi ir kļuvuši ļoti viegli pielietojami mūsdienu lietojumprogrammās (ja tie, protams, ir piemēroti). Mākoņi piedāvā uzreiz sadalīšanu un horizontālo mērogošanu, kas ir daudz vienkāršāk nekā pašam pasūtīt dažādus serverus dažādos datu centros. CQRS ir kļuvis daudz vienkāršāks, kaut vai tikai tādu bibliotēku attīstības dēļ kā RX. Apmēram pirms 10 gadiem reta vietne varēja to atbalstīt. Event Sourcing ir arī neticami viegli iestatāms, pateicoties gataviem konteineriem ar Apache Kafka. Pirms 10 gadiem tas būtu bijis jauninājums, tagad tas ir ierasts. Līdzīgi ir ar statiskā satura mitināšanu: ērtāku tehnoloģiju (tostarp detalizētas dokumentācijas un lielas atbilžu datu bāzes) dēļ šī pieeja ir kļuvusi vēl vienkāršāka.

Līdz ar to vairāku diezgan sarežģītu arhitektūras modeļu īstenošana tagad ir kļuvusi daudz vienkāršāka, kas nozīmē, ka labāk to iepriekš apskatīt tuvāk. Ja desmit gadus vecā lietojumprogrammā kāds no iepriekš minētajiem risinājumiem tika atmests ieviešanas un darbības augsto izmaksu dēļ, tagad jaunā lietojumprogrammā vai pēc pārstrukturēšanas varat izveidot pakalpojumu, kas jau būs arhitektoniski paplašināms ( veiktspējas ziņā) un gatavi jauniem klientu pieprasījumiem (piemēram, lai lokalizētu personas datus).

Un pats galvenais: lūdzu, neizmantojiet šīs pieejas, ja jums ir vienkārša lietojumprogramma. Jā, tie ir skaisti un interesanti, bet vietnei, kuras maksimums ir 100 cilvēku, bieži var iztikt ar klasisku monolītu (vismaz ārpusē visu iekšā var sadalīt moduļos utt.).

Avots: www.habr.com