El món no s'atura. El progrés crea nous reptes tecnològics. D'acord amb els requeriments canviants, l'arquitectura dels sistemes d'informació ha d'evolucionar. Avui parlarem de l'arquitectura basada en esdeveniments, la concurrència, la concurrència, l'asincronia i com es pot viure en pau amb tot això a Erlang.
Introducció
Depenent de la mida del sistema dissenyat i dels requisits per a aquest, nosaltres, els desenvolupadors, triem el mètode d'intercanvi d'informació al sistema. En la majoria dels casos, per organitzar la interacció dels serveis, una opció de treball pot ser un esquema amb un corredor, per exemple, basat en RabbitMQ o kafka. Però, de vegades, el flux d'esdeveniments, el SLA i el nivell de control del sistema són tals que els missatges fets no són adequats per a nosaltres. Per descomptat, podeu complicar una mica el sistema assumint la responsabilitat de la capa de transport i la formació de clúster, per exemple, utilitzant ZeroMQ o nanomsg. Però si el sistema té prou rendiment i capacitats d'un clúster Erlang estàndard, aleshores la qüestió d'introduir una entitat addicional requereix un estudi detallat i una justificació econòmica.
El tema de les aplicacions distribuïdes reactives és força ampli. Per mantenir-se dins del format de l'article, el tema de la discussió d'avui només seran entorns homogenis construïts sobre Erlang/Elixir. L'ecosistema Erlang/OTP us permet implementar una arquitectura reactiva amb el menor esforç. Però en qualsevol cas, necessitarem una capa de missatgeria.
Base teòrica
El disseny comença amb la definició d'objectius i limitacions. L'objectiu principal no es troba en l'àrea de desenvolupament pel bé del desenvolupament. Hem d'aconseguir una eina segura i escalable sobre la base de la qual puguem crear i, sobretot, desenvolupar aplicacions modernes de diversos nivells: a partir d'aplicacions d'un sol servidor al servei d'un públic reduït, que després es poden desenvolupar en clústers de fins a 50 -60 nodes, acabant amb federacions de clúster. Així, l'objectiu principal és maximitzar els beneficis reduint el cost de desenvolupament i propietat del sistema final.
Destaquem 4 requisits principals per al sistema final:
- Сorientat a esdeveniments.
El sistema està sempre preparat per passar pel flux d'esdeveniments i realitzar les accions necessàries; - Мescalabilitat.
Els blocs individuals es poden escalar tant verticalment com horitzontalment. Tot el sistema ha de ser capaç de creixement horitzontal infinit; - Оfalta de tolerància.
Tots els nivells i tots els serveis haurien de poder recuperar-se automàticament dels errors; - Гtemps de resposta garantit.
El temps és valuós i els usuaris no haurien d'esperar massa.
Recordeu el vell conte de fades sobre "El petit motor que podria"? Perquè el sistema dissenyat surti amb èxit de l'etapa del prototip i sigui progressiu, la seva base ha de complir els requisits mínims. SMOG.
A la missatgeria s'afegeix un punt més com a eina d'infraestructura i base de tots els serveis: la facilitat d'ús per als programadors.
Orientat a esdeveniments
Perquè una aplicació creixi d'un únic servidor a un clúster, la seva arquitectura ha de suportar un acoblament fluix. El model asíncron compleix aquest requisit. En ell, l'emissor i el destinatari es preocupen per la càrrega d'informació del missatge i no es preocupen per la transmissió i l'encaminament dins del sistema.
Escalabilitat
L'escalabilitat i l'eficiència del sistema estan al costat de l'altra. Els components de l'aplicació han de poder utilitzar tots els recursos disponibles. Com més eficient puguem utilitzar la capacitat i com més òptims siguin els nostres mètodes de processament, menys diners gastem en equips.
Dins d'una única màquina, Erlang crea un entorn altament competitiu. L'equilibri entre concurrència i paral·lelisme es pot establir escollint el nombre de fils del sistema operatiu disponibles per a la màquina virtual Erlang i el nombre de programadors que utilitzen aquests fils.
Els processos Erlang no comparteixen estat i operen en mode no bloquejador. Això proporciona una latència relativament baixa i un rendiment més elevat que les aplicacions tradicionals basades en el bloqueig. El programador d'Erlang garanteix una assignació justa de CPU i IO, i l'absència de bloqueig permet que l'aplicació respongui fins i tot durant les càrregues punta o fallades.
A nivell de clúster, el problema amb l'eliminació també existeix. És important que totes les màquines del clúster estiguin carregades uniformement i que la xarxa no estigui sobrecarregada. Imaginem una situació: el trànsit d'usuaris arriba als equilibradors entrants (haproxy, nginx, etc.), distribueixen les sol·licituds de processament de la manera més uniforme possible entre el conjunt de backends disponibles. Dins de la infraestructura d'aplicacions, el servei que implementa la interfície requerida és només l'última milla i haurà de sol·licitar una sèrie d'altres serveis per respondre a la sol·licitud inicial. Les sol·licituds internes també requereixen encaminament i equilibri.
Per gestionar de manera eficaç els fluxos de dades, la missatgeria ha de proporcionar als desenvolupadors una interfície per gestionar l'encaminament i l'equilibri de càrrega. Gràcies a això, els desenvolupadors podran, utilitzant patrons de microserveis (agregador, proxy, cadena, branca, etc.), resoldre tant els problemes estàndard com els que poques vegades sorgeixen.
Des del punt de vista empresarial, l'escalabilitat és una de les eines de gestió del risc. El més important és satisfer les peticions dels clients utilitzant de manera òptima l'equip:
- Quan la potència dels equips augmenta com a conseqüència del progrés. No estarà inactiu a causa d'un programari imperfecte. Erlang escala bé verticalment i sempre podrà utilitzar tots els nuclis de la CPU i la memòria disponible;
- En entorns al núvol, podem gestionar la quantitat d'equips en funció de la càrrega actual o prevista i garantir un SLA.
falta de tolerància
Considerem dos axiomes: "Els fracassos són inacceptables" i "Sempre hi haurà fracassos". Per a una empresa, la fallada del programari significa pèrdua de diners i, el que és pitjor, pèrdua de reputació. Sovint es pot trobar un compromís entre possibles pèrdues i el cost del desenvolupament de programari tolerant a errors.
A curt termini, una arquitectura que incorpori tolerància a fallades permet estalviar diners en la compra de solucions de clustering disponibles. Són cars i també tenen errors.
A llarg termini, una arquitectura tolerant a errors es compensa moltes vegades en totes les etapes de desenvolupament.
La missatgeria dins de la base de codi us permet elaborar amb detall la interacció dels components dins del sistema en l'etapa de desenvolupament. Això simplifica la tasca de respondre i gestionar les fallades, ja que tots els components crítics gestionen les fallades i el sistema resultant sap com tornar automàticament a la normalitat després d'una fallada per disseny.
Capacitat de resposta
Independentment dels errors, l'aplicació ha de respondre a les sol·licituds i complir el SLA. La realitat és que la gent no vol esperar, de manera que les empreses s'han d'adaptar en conseqüència. S'espera que cada cop més aplicacions siguin altament sensibles.
Les aplicacions responsives funcionen gairebé en temps real. Erlang VM funciona en mode suau en temps real. Per a algunes àrees, com ara el comerç d'accions, la medicina i el control d'equips industrials, el mode dur en temps real és important.
Els sistemes responsius milloren la UX i beneficien el negoci.
Resum preliminar
Quan planejava aquest article, volia compartir la meva experiència de crear un corredor de missatgeria i construir sistemes complexos basats en ell. Però la part teòrica i motivacional va resultar ser força extensa.
A la segona part de l'article, parlaré dels matisos de la implementació de punts d'intercanvi, els patrons de missatgeria i la seva aplicació.
A la tercera part considerarem qüestions generals d'organització dels serveis, encaminament i equilibri. Parlem de la part pràctica de l'escalabilitat i la tolerància a errors dels sistemes.
Final de la primera part.
Sessió De Fotos .
Font: www.habr.com