La mondo ne staras senmove. Progreso kreas novajn teknologiajn defiojn. Konforme al ŝanĝiĝantaj postuloj, la arkitekturo de informsistemoj devas evolui. Hodiaŭ ni parolos pri okazaĵa arkitekturo, samtempeco, samtempeco, malsinkronio, kaj kiel vi povas vivi pace kun ĉio ĉi en Erlang.
Enkonduko
Depende de la grandeco de la desegnita sistemo kaj la postuloj por ĝi, ni, la programistoj, elektas la metodon por interŝanĝi informojn en la sistemo. Plejofte, por organizi la interagadon de servoj, funkcia opcio povas esti skemo kun makleristo, ekzemple, bazita sur RabbitMQ aŭ kafka. Sed foje la fluo de eventoj, SLA kaj nivelo de kontrolo super la sistemo estas tiaj, ke preta mesaĝado ne taŭgas por ni. Kompreneble, vi povas iomete kompliki la sistemon prenante respondecon pri la transporttavolo kaj formado de aretoj, ekzemple uzante ZeroMQ aŭ nanomsg. Sed se la sistemo havas sufiĉe da trafluo kaj kapabloj de norma Erlang-areto, tiam la temo de enkonduko de plia ento postulas detalan studon kaj ekonomian pravigon.
La temo de reaktivaj distribuitaj aplikoj estas sufiĉe ampleksa. Por konservi en la formato de la artikolo, la temo de la hodiaŭa diskuto estos nur homogenaj medioj konstruitaj sur Erlang/Elixir. La ekosistemo Erlang/OTP ebligas al vi efektivigi reaktivan arkitekturon kun la plej malgranda peno. Sed ĉiukaze ni bezonos mesaĝan tavolon.
Teoria bazo
Dezajno komenciĝas per difinado de celoj kaj limoj. La ĉefa celo ne estas en la areo de evoluo pro disvolviĝo. Ni devas akiri sekuran kaj skaleblan ilon surbaze de kiu ni povas krei kaj, plej grave, evoluigi modernajn aplikojn de diversaj niveloj: komencante de unu-servilaj aplikaĵoj servantaj al malgranda publiko, kiu poste povas disvolviĝi en aretojn de ĝis 50. -60 nodoj, finiĝantaj per clusterfederacioj. Tiel, la ĉefa celo estas maksimumigi profitojn reduktante la koston de disvolviĝo kaj proprieto de la fina sistemo.
Ni reliefigu 4 ĉefajn postulojn por la fina sistemo:
- Сevento-orientita.
La sistemo ĉiam pretas trapasi la fluon de eventoj kaj plenumi la necesajn agojn; - Мskaleblo.
Individuaj blokoj povas esti skalitaj kaj vertikale kaj horizontale. La tuta sistemo devas esti kapabla je senfina horizontala kresko; - Оkulpo toleremo.
Ĉiuj niveloj kaj ĉiuj servoj devus povi aŭtomate resaniĝi de misfunkciadoj; - Гgarantiita respondotempo.
Tempo estas valora kaj uzantoj ne devus atendi tro longe.
Ĉu vi memoras la malnovan fabelon pri "La motoreto, kiu povus"? Por ke la desegnita sistemo sukcese eliru la prototipan stadion kaj estu progresema, ĝia fundamento devas plenumi la minimumajn postulojn. SMOGO.
Unu plia punkto aldoniĝas al mesaĝado kiel infrastruktura ilo kaj la bazo por ĉiuj servoj: facileco de uzo por programistoj.
Event-orientita
Por ke aplikaĵo kresku de ununura servilo al areto, ĝia arkitekturo devas apogi lozan kunigon. La nesinkrona modelo plenumas ĉi tiun postulon. En ĝi, la sendinto kaj ricevanto zorgas pri la informa ŝarĝo de la mesaĝo kaj ne zorgas pri transdono kaj envojigo ene de la sistemo.
Skalebleco
Skalebleco kaj sistema efikeco estas unu apud la alia. Aplikaj komponantoj devas povi uzi ĉiujn disponeblajn rimedojn. Ju pli efike ni povas uzi kapaciton kaj ju pli optimumajn niajn pretigmetodojn, des malpli da mono ni elspezas por ekipaĵo.
Ene de ununura maŝino, Erlang kreas tre konkurencivan medion. La ekvilibro inter samtempeco kaj paraleleco povas esti agordita elektante la nombron da operaciumaj fadenoj haveblaj al la Erlang VM kaj la nombro da planistoj kiuj utiligas ĉi tiujn fadenojn.
Erlang-procezoj ne kunhavas staton kaj funkcias en ne-bloka reĝimo. Ĉi tio disponigas relative malaltan latentecon kaj pli altan trairon ol tradiciaj blok-bazitaj aplikoj. La planilo de Erlang certigas justan asignadon de CPU kaj IO, kaj la foresto de blokado permesas al la aplikaĵo respondi eĉ dum pintaj ŝarĝoj aŭ fiaskoj.
Sur la aretnivelo, la problemo kun forigo ankaŭ ekzistas. Gravas, ke ĉiuj maŝinoj en la areto estas egale ŝarĝitaj kaj ke la reto ne estas troŝarĝita. Ni imagu situacion: uzanttrafiko alteriĝas sur envenantajn ekvilibrilojn (haproxy, nginx, ktp), ili distribuas petojn por prilaborado kiel eble plej egale inter la aro de disponeblaj backends. Ene de la aplika infrastrukturo, la servo efektiviganta la postulatan interfacon estas nur la lasta mejlo kaj devos peti kelkajn aliajn servojn por respondi al la komenca peto. Internaj petoj ankaŭ postulas vojigon kaj ekvilibron.
Por efike administri datumfluojn, mesaĝado devas provizi programistojn per interfaco por administri vojigon kaj ŝarĝbalancadon. Dank' al tio, programistoj povos, uzante mikroservajn ŝablonojn (agregator, prokurilo, ĉeno, branĉo ktp), solvi kaj normajn problemojn kaj tiujn, kiuj malofte aperas.
De komerca vidpunkto, skaleblo estas unu el la risko-administrad iloj. La ĉefa afero estas kontentigi klientajn petojn optimume uzante la ekipaĵon:
- Kiam la potenco de ekipaĵo pliiĝas kiel rezulto de progreso. Ĝi ne estos senaktiva pro neperfekta programaro. Erlang skalas vertikale bone kaj ĉiam povos uzi ĉiujn CPU-kernojn kaj disponeblan memoron;
- En nubaj medioj, ni povas administri la kvanton da ekipaĵo depende de la nuna aŭ antaŭvidita ŝarĝo kaj garantii SLA.
kulpo toleremo
Ni konsideru du aksiomojn: "Malsukcesoj estas neakcepteblaj" kaj "Ĉiam estos fiaskoj." Por komerco, programaro fiasko signifas perdon de mono, kaj kio estas pli malbona, perdo de reputacio. Ekvilibrado inter eblaj perdoj kaj la kosto de evoluigado de mistolerema programaro, kompromiso ofte povas esti trovita.
Baldaŭte, arkitekturo, kiu enhavas misfunkciadon, ŝparas monon por aĉetado de nekomercaj grupaj solvoj. Ili estas multekostaj kaj ili ankaŭ havas cimojn.
Longperspektive, mistolerema arkitekturo multfoje pagas por si en ĉiuj stadioj de evoluo.
Mesaĝado ene de la kodbazo permesas vin ellabori detale la interagadon de komponantoj ene de la sistemo en la evolufazo. Ĉi tio simpligas la taskon respondi kaj administri malsukcesojn, ĉar ĉiuj kritikaj komponentoj pritraktas fiaskojn, kaj la rezulta sistemo scias kiel aŭtomate reveni al normalo post fiasko laŭ dezajno.
Respondeco
Sendepende de fiaskoj, la aplikaĵo devas respondi al petoj kaj plenumi la SLA. La realo estas, ke homoj ne volas atendi, do entreprenoj devas adaptiĝi laŭe. Pli kaj pli da aplikoj estas atenditaj esti tre respondemaj.
Respondema aplikoj funkcias en preskaŭ reala tempo. Erlang VM funkcias en mola realtempa reĝimo. Por iuj areoj, kiel akcia komerco, medicino kaj kontrolo de industria ekipaĵo, malmola realtempa reĝimo gravas.
Respondema sistemoj plibonigas UX kaj profitigas la komercon.
Prepara resumo
Planante ĉi tiun artikolon, mi volis kunhavigi mian sperton pri kreado de mesaĝa makleristo kaj konstruado de kompleksaj sistemoj bazitaj sur ĝi. Sed la teoria kaj instiga parto montriĝis sufiĉe vasta.
En la dua parto de la artikolo, mi parolos pri la nuancoj de efektivigado de interŝanĝpunktoj, mesaĝaj ŝablonoj kaj ilia apliko.
En la tria parto ni konsideros ĝeneralajn aferojn pri organizado de servoj, vojigo kaj ekvilibro. Ni parolu pri la praktika flanko de skaleblo kaj faŭltoleremo de sistemoj.
Fino de la unua parto.
Foto .
fonto: www.habr.com