Pasaule nestāv uz vietas. Progress rada jaunus tehnoloģiskus izaicinājumus. Informācijas sistēmu arhitektūrai ir jāattīstās atbilstoši mainīgajām prasībām. Šodien mēs runāsim par notikumu virzītu arhitektūru, vienlaicību, vienlaicību, asinhroniju un to, kā jūs varat mierīgi dzīvot ar visu to Erlangā.
Ievads
Atkarībā no projektētās sistēmas izmēra un tai izvirzītajām prasībām mēs, izstrādātāji, izvēlamies informācijas apmaiņas metodi sistēmā. Vairumā gadījumu, lai organizētu pakalpojumu mijiedarbību, darba iespēja var būt shēma ar brokeri, piemēram, pamatojoties uz RabbitMQ vai kafka. Bet dažreiz notikumu plūsma, SLA un kontroles līmenis pār sistēmu ir tāds, ka gatava ziņojumapmaiņa mums nav piemērota. Protams, jūs varat nedaudz sarežģīt sistēmu, uzņemoties atbildību par transporta slāni un klasteru veidošanos, piemēram, izmantojot ZeroMQ vai nanomsg. Bet, ja sistēmai ir pietiekama standarta Erlang klastera caurlaidspēja un iespējas, tad jautājums par papildu entītiju ieviešanu prasa detalizētu izpēti un ekonomisko pamatojumu.
Reaktīvo izplatīto lietojumprogrammu tēma ir diezgan plaša. Lai ievērotu raksta formātu, šodienas diskusijas tēma būs tikai viendabīga vide, kas balstīta uz Erlang/Elixir. Erlang/OTP ekosistēma ļauj ieviest reaktīvu arhitektūru ar vismazāko piepūli. Bet jebkurā gadījumā mums būs nepieciešams ziņojumapmaiņas slānis.
Teorētiskā bāze
Dizains sākas ar mērķu un ierobežojumu noteikšanu. Galvenais mērķis nav attīstības jomā attīstības labad. Jāiegūst drošs un mērogojams rīks, uz kura pamata varam izveidot un, galvenais, attīstīt dažāda līmeņa modernas aplikācijas: sākot no viena servera aplikācijām, kas apkalpo nelielu auditoriju, kas vēlāk var izvērsties klasteros līdz pat 50. -60 mezgli, kas beidzas ar klasteru federācijām. Tādējādi galvenais mērķis ir palielināt peļņu, samazinot galīgās sistēmas izstrādes un īpašumtiesību izmaksas.
Izcelsim 4 galvenās prasības gala sistēmai:
- Сuz pasākumiem orientēts.
Sistēma vienmēr ir gatava iziet cauri notikumu plūsmai un veikt nepieciešamās darbības; - Мmērogojamība.
Atsevišķus blokus var mērogot gan vertikāli, gan horizontāli. Visai sistēmai jāspēj bezgalīgi attīstīties horizontāli; - Оkļūdu tolerance.
Visiem līmeņiem un visiem pakalpojumiem jāspēj automātiski atgūties no kļūmēm; - Гgarantēts reakcijas laiks.
Laiks ir vērtīgs, un lietotājiem nevajadzētu pārāk ilgi gaidīt.
Vai atceries veco pasaku par “Mazo dzinēju, kas varētu”? Lai projektētā sistēma veiksmīgi izietu no prototipa stadijas un būtu progresīva, tās pamatam jāatbilst minimālajām prasībām SMOG.
Ziņojumapmaiņai kā infrastruktūras rīkam un visu pakalpojumu pamatam ir pievienots vēl viens punkts: programmētāju lietošanas vienkāršība.
Orientēts uz pasākumiem
Lai lietojumprogramma no viena servera kļūtu par kopu, tās arhitektūrai ir jāatbalsta brīva savienošana. Asinhronais modelis atbilst šai prasībai. Tajā sūtītājs un saņēmējs rūpējas par ziņojuma informācijas slodzi un neuztraucas par pārraidi un maršrutēšanu sistēmas ietvaros.
Mērogojamība
Mērogojamība un sistēmas efektivitāte ir blakus viena otrai. Lietojumprogrammu komponentiem jāspēj izmantot visus pieejamos resursus. Jo efektīvāk mēs varam izmantot jaudu un optimālākas mūsu apstrādes metodes, jo mazāk naudas mēs tērējam iekārtām.
Vienā iekārtā Erlang rada ļoti konkurētspējīgu vidi. Līdzsvaru starp vienlaicību un paralēlismu var iestatīt, izvēloties Erlang VM pieejamo operētājsistēmas pavedienu skaitu un plānotāju skaitu, kas izmanto šos pavedienus.
Erlang procesi nedala stāvokli un darbojas nebloķējošā režīmā. Tas nodrošina salīdzinoši zemu latentumu un lielāku caurlaidspēju nekā tradicionālās lietojumprogrammas, kuru pamatā ir bloķēšana. Erlang plānotājs nodrošina taisnīgu CPU un IO sadali, un bloķēšanas neesamība ļauj lietojumprogrammai reaģēt pat maksimālās slodzes vai kļūmju laikā.
Klasteru līmenī pastāv arī problēma ar iznīcināšanu. Ir svarīgi, lai visas mašīnas klasterī būtu vienmērīgi noslogotas un tīkls netiktu pārslogots. Iedomāsimies situāciju: lietotāju trafika nonāk pie ienākošajiem balansētājiem (haproxy, nginx utt.), tie sadala apstrādes pieprasījumus pēc iespējas vienmērīgāk starp pieejamo aizmugursistēmu kopu. Lietojumprogrammas infrastruktūrā pakalpojums, kas ievieš nepieciešamo saskarni, ir tikai pēdējā jūdze, un tam būs jāpieprasa vairāki citi pakalpojumi, lai atbildētu uz sākotnējo pieprasījumu. Iekšējiem pieprasījumiem ir nepieciešama arī maršrutēšana un līdzsvarošana.
Lai efektīvi pārvaldītu datu plūsmas, ziņojumapmaiņai ir jānodrošina izstrādātājiem saskarne maršrutēšanas un slodzes līdzsvarošanas pārvaldībai. Pateicoties tam, izstrādātāji, izmantojot mikropakalpojumu modeļus (agregatoru, starpniekserveri, ķēdi, filiāli utt.), varēs atrisināt gan standarta problēmas, gan tās, kas rodas reti.
No biznesa viedokļa mērogojamība ir viens no riska pārvaldības instrumentiem. Galvenais ir apmierināt klientu vēlmes, optimāli izmantojot aprīkojumu:
- Kad progresa rezultātā palielinās aprīkojuma jauda. Nepilnīgas programmatūras dēļ tas nedarbosies dīkstāvē. Erlang labi mērogojas vertikāli un vienmēr varēs izmantot visus CPU kodolus un pieejamo atmiņu;
- Mākoņvidēs varam pārvaldīt aprīkojuma daudzumu atkarībā no pašreizējās vai prognozētās slodzes un garantēt SLA.
kļūdu tolerance
Apskatīsim divas aksiomas: “Neveiksmes ir nepieņemamas” un “Neveiksmes vienmēr būs”. Uzņēmumam programmatūras kļūme nozīmē naudas zaudēšanu un, kas ir vēl ļaunāk, reputācijas zaudēšanu. Līdzsvarojot starp iespējamiem zaudējumiem un defektu izturīgas programmatūras izstrādes izmaksām, bieži var atrast kompromisu.
Īstermiņā arhitektūra, kas ietver kļūdu toleranci, ietaupa naudu, iegādājoties gatavus klasterizācijas risinājumus. Tie ir dārgi, un tiem ir arī kļūdas.
Ilgtermiņā defektu izturīga arhitektūra atmaksājas daudzkārt visos attīstības posmos.
Ziņojumapmaiņa koda bāzes ietvaros ļauj detalizēti izstrādāt komponentu mijiedarbību sistēmā izstrādes stadijā. Tas vienkāršo reaģēšanas un kļūmju pārvaldības uzdevumu, jo visi kritiskie komponenti apstrādā kļūmes, un iegūtā sistēma zina, kā automātiski atgriezties normālā režīmā pēc izstrādātas kļūmes.
Atsaucība
Neatkarīgi no kļūmēm lietojumprogrammai ir jāatbild uz pieprasījumiem un jāatbilst SLA. Realitāte ir tāda, ka cilvēki nevēlas gaidīt, tāpēc uzņēmumiem ir attiecīgi jāpielāgojas. Paredzams, ka arvien vairāk lietojumprogrammu būs ļoti atsaucīgas.
Atsaucīgas lietojumprogrammas darbojas gandrīz reāllaikā. Erlang VM darbojas mīkstā reāllaika režīmā. Dažās jomās, piemēram, akciju tirdzniecībai, medicīnai un rūpniecisko iekārtu kontrolei, cietais reāllaika režīms ir svarīgs.
Adaptīvās sistēmas uzlabo lietotāja pieredzi un sniedz labumu uzņēmumam.
Iepriekšējs kopsavilkums
Plānojot šo rakstu, vēlējos dalīties pieredzē par ziņojumapmaiņas brokera izveidi un uz tā bāzes veidotu sarežģītas sistēmas. Bet teorētiskā un motivējošā daļa izrādījās diezgan apjomīga.
Raksta otrajā daļā es runāšu par apmaiņas punktu ieviešanas niansēm, ziņojumapmaiņas modeļiem un to pielietojumu.
Trešajā daļā apskatīsim vispārīgus pakalpojumu organizēšanas, maršrutēšanas un balansēšanas jautājumus. Parunāsim par sistēmu mērogojamības un kļūdu tolerances praktisko pusi.
Pirmās daļas beigas.
foto .
Avots: www.habr.com