De wrâld stiet net stil. Foarútgong soarget foar nije technologyske útdagings. Yn oerienstimming mei feroarjende easken moat de arsjitektuer fan ynformaasjesystemen evoluearje. Hjoed sille wy prate oer evenemint-oandreaune arsjitektuer, concurrency, concurrency, asynchrony, en hoe't jo kinne libje freedsum mei dit alles yn Erlang.
Ynlieding
Ofhinklik fan de grutte fan it ûntwurpen systeem en de easken dêrfoar, kieze wy, de ûntwikkelders, de metoade foar it útwikseljen fan ynformaasje yn it systeem. Yn 'e measte gefallen, om de ynteraksje fan tsjinsten te organisearjen, kin in wurkopsje in skema wêze mei in brokker, bygelyks basearre op RabbitMQ of kafka. Mar soms binne de stream fan eveneminten, SLA en nivo fan kontrôle oer it systeem sa dat klearmakke messaging is net geskikt foar ús. Fansels kinne jo it systeem in bytsje komplisearje troch ferantwurdlikens te nimmen foar de transportlaach en klusterfoarming, bygelyks mei ZeroMQ of nanomsg. Mar as it systeem genôch trochstreaming en mooglikheden hat fan in standert Erlang-kluster, dan fereasket it probleem fan it ynfieren fan in ekstra entiteit in detaillearre stúdzje en ekonomyske rjochtfeardiging.
It ûnderwerp fan reaktive ferspraat applikaasjes is frij breed. Om binnen it formaat fan it artikel te hâlden, sil it ûnderwerp fan 'e diskusje fan hjoed allinich homogene omjouwings wêze boud op Erlang / Elixir. It Erlang / OTP-ekosysteem lit jo in reaktive arsjitektuer ymplementearje mei it minste bedrach. Mar yn alle gefallen sille wy in messaging-laach nedich wêze.
Teoretyske basis
Untwerp begjint mei it definiearjen fan doelen en beheiningen. It haaddoel is net op it mêd fan ûntwikkeling om 'e wille fan ûntwikkeling. Wy moatte in feilich en skalberber ark krije op basis wêrfan wy moderne applikaasjes fan ferskate nivo's kinne oanmeitsje en, wichtichste, ûntwikkelje: útgeande fan applikaasjes mei ien tsjinner dy't in lyts publyk betsjinje, dy't letter kinne ûntwikkelje ta klusters fan maksimaal 50 -60 knopen, einigje mei klusterfederaasjes. Sa is it haaddoel om profiten te maksimalisearjen troch de kosten fan ûntwikkeling en eigendom fan it definitive systeem te ferminderjen.
Lit ús markearje 4 wichtichste easken foar it definitive systeem:
- Сevenemint-rjochte.
It systeem is altyd ree om troch de stream fan eveneminten te gean en de nedige aksjes út te fieren; - Мscalability.
Yndividuele blokken kinne wurde skalearre sawol fertikaal as horizontaal. It hiele systeem moat by steat wêze fan ûneinige horizontale groei; - Оmarzje foar flaters.
Alle nivo's en alle tsjinsten moatte automatysk herstelle kinne fan mislearrings; - Гgarandearre reaksjetiid.
Tiid is weardefol en brûkers moatte net te lang wachtsje.
Unthâld it âlde mearke oer "De lytse motor dy't koe"? Om it ûntworpen systeem mei súkses it prototype-poadium te ferlitten en progressive te wêzen, moat de stifting foldogge oan de minimale easken SMOG.
Noch ien punt wurdt tafoege oan messaging as in ynfrastruktuer ark en de basis foar alle tsjinsten: gemak fan gebrûk foar programmeurs.
Event-rjochte
Foar in applikaasje te groeien fan in inkele tsjinner nei in kluster, syn arsjitektuer moat stypje losse coupling. It asynchrone model foldocht oan dizze eask. Dêryn soargje de stjoerder en ûntfanger oer de ynformaasjelading fan it berjocht en meitsje jo gjin soargen oer oerdracht en routing binnen it systeem.
Skalberens
Scalability en systeem effisjinsje binne neist elkoar. Applikaasjekomponinten moatte alle beskikbere boarnen kinne brûke. Hoe effisjinter wy de kapasiteit brûke kinne en hoe optimaler ús ferwurkingsmetoaden, hoe minder jild wy besteegje oan apparatuer.
Binnen ien masine skept Erlang in heul konkurrearjende omjouwing. De lykwicht tusken gearkomst en parallelisme kin ynsteld wurde troch te kiezen foar it oantal bestjoeringssysteem threads beskikber foar de Erlang VM en it oantal planners dy't dizze threaden brûke.
Erlang-prosessen diele gjin steat en operearje yn net-blokkearjende modus. Dit soarget foar relatyf lege latency en hegere trochslach dan tradisjonele blokkearjende applikaasjes. De planner fan Erlang soarget foar earlike tawizing fan CPU en IO, en it ûntbrekken fan blokkearjen lit de applikaasje sels reagearje tidens pykladen as mislearrings.
Op klusternivo bestiet ek it probleem mei ôffieren. It is wichtich dat alle masines yn it kluster wurde gelyk laden en dat it netwurk wurdt net oerladen. Litte wy ús in situaasje foarstelle: brûkersferkear komt telâne op ynkommende balancers (haproxy, nginx, ensfh.), se fersprieden ferwurkingsoanfragen sa lyklik mooglik tusken de set fan beskikbere backends. Binnen de applikaasje-ynfrastruktuer is de tsjinst dy't de fereaske ynterface ymplementearret allinich de lêste myl en sil in oantal oare tsjinsten moatte oanfreegje om te reagearjen op it earste fersyk. Ynterne oanfragen fereaskje ek routing en balâns.
Om gegevensstreamen effektyf te behearjen, moat berjochten ûntwikkelders in ynterface leverje om routing en loadbalancing te behearjen. Mei tank oan dit, ûntwikkelders sille wêze kinne, mei help fan microservice patroanen (aggregator, proxy, ketting, branch, ensfh), te lossen sawol standert problemen en dyjingen dy't komselden ûntstean.
Fanút in saaklik eachpunt is skaalberens ien fan 'e ark foar risikobehear. It wichtichste is om oanfragen fan klanten te foldwaan troch de apparatuer optimaal te brûken:
- As de krêft fan apparatuer nimt ta as gefolch fan foarútgong. It sil net idle wêze fanwegen ûnfolsleine software. Erlang skalen fertikaal goed en sil altyd by steat wêze om te benutten alle CPU kearnen en beskikber ûnthâld;
- Yn wolkomjouwings kinne wy it bedrach fan apparatuer beheare ôfhinklik fan 'e aktuele of foarseine lading en garandearje SLA.
marzje foar flaters
Litte wy twa axioma's beskôgje: "Falingen binne net akseptabel" en "D'r sille altyd mislearrings wêze." Foar in bedriuw betsjut softwaremislearring ferlies fan jild, en wat noch slimmer is, ferlies fan reputaasje. Balâns tusken mooglike ferliezen en de kosten fan it ûntwikkeljen fan fout-tolerante software, in kompromis kin faak fûn wurde.
Op koarte termyn besparret in arsjitektuer dy't fouttolerânsje omfettet jild op it keapjen fan off-the-shelf klusteroplossingen. Se binne djoer en se hawwe ek bugs.
Op lange termyn betellet in fouttolerante arsjitektuer himsels in protte kearen yn alle stadia fan ûntwikkeling.
Berjochten binnen de koadebasis kinne jo de ynteraksje fan komponinten binnen it systeem yn 'e ûntwikkelingsstadium yn detail útwurkje. Dit simplifies de taak om te reagearjen en te behearjen fan flaters, om't alle krityske komponinten mislearrings behannelje, en it resultearjende systeem wit hoe't it automatysk werom kin nei normaal nei in mislearring troch ûntwerp.
Responsiviteit
Nettsjinsteande mislearrings moat de applikaasje reagearje op oanfragen en foldwaan oan de SLA. De realiteit is dat minsken net wachtsje wolle, dus bedriuwen moatte har dêrop oanpasse. Hieltyd mear applikaasjes wurde ferwachte dat se heul responsyf binne.
Responsive applikaasjes wurkje yn hast echte tiid. Erlang VM wurket yn sêfte real-time modus. Foar guon gebieten, lykas aksjehannel, medisinen en kontrôle fan yndustriële apparatuer, is hurde realtime modus wichtich.
Responsive systemen ferbetterje UX en profitearje fan it bedriuw.
Foarriedige gearfetting
By it plannen fan dit artikel woe ik myn ûnderfining diele fan it meitsjen fan in messaging-makelaar en it bouwen fan komplekse systemen op basis dêrfan. Mar it teoretyske en motivearjende diel blykte frij wiidweidich te wêzen.
Yn it twadde diel fan it artikel sil ik prate oer de nuânses fan it útfieren fan útwikselingspunten, messagingpatroanen en har tapassing.
Yn it tredde diel sille wy beskôgje algemiene problemen fan it organisearjen fan tsjinsten, routing en balâns. Litte wy prate oer de praktyske kant fan skalberens en fouttolerânsje fan systemen.
Ein fan it earste diel.
foto .
Boarne: www.habr.com