Lumea nu sta pe loc. Progresul creează noi provocări tehnologice. În conformitate cu cerințele în schimbare, arhitectura sistemelor informaționale trebuie să evolueze. Astăzi vom vorbi despre arhitectura bazată pe evenimente, concurență, concurență, asincronie și despre cum puteți trăi liniștit cu toate acestea în Erlang.
Introducere
În funcție de dimensiunea sistemului proiectat și de cerințele pentru acesta, noi, dezvoltatorii, alegem metoda de schimb de informații în sistem. În cele mai multe cazuri, pentru a organiza interacțiunea serviciilor, o opțiune de lucru poate fi o schemă cu un broker, de exemplu, bazată pe RabbitMQ sau kafka. Dar, uneori, fluxul de evenimente, SLA și nivelul de control asupra sistemului sunt de așa natură încât mesajele gata făcute nu sunt potrivite pentru noi. Desigur, puteți complica puțin sistemul asumându-vă responsabilitatea pentru stratul de transport și formarea clusterului, de exemplu folosind ZeroMQ sau nanomsg. Dar dacă sistemul are suficient debit și capabilități ale unui cluster Erlang standard, atunci problema introducerii unei entități suplimentare necesită un studiu detaliat și o justificare economică.
Tema aplicațiilor distribuite reactive este destul de larg. Pentru a rămâne în formatul articolului, subiectul discuției de astăzi vor fi doar medii omogene construite pe Erlang/Elixir. Ecosistemul Erlang/OTP vă permite să implementați o arhitectură reactivă cu cel mai mic efort. Dar, în orice caz, vom avea nevoie de un strat de mesagerie.
Baza teoretica
Designul începe cu definirea obiectivelor și constrângerilor. Scopul principal nu este în zona dezvoltării de dragul dezvoltării. Trebuie să obținem un instrument securizat și scalabil pe baza căruia să putem crea și, cel mai important, să dezvoltăm aplicații moderne de diferite niveluri: pornind de la aplicații cu un singur server care deservesc un public restrâns, care ulterior se poate dezvolta în clustere de până la 50. -60 de noduri, care se termină cu federații de cluster. Astfel, scopul principal este de a maximiza profiturile prin reducerea costurilor de dezvoltare și de proprietate asupra sistemului final.
Să evidențiem 4 cerințe principale pentru sistemul final:
- Сorientat pe evenimente.
Sistemul este întotdeauna gata să treacă prin fluxul de evenimente și să efectueze acțiunile necesare; - Мscalabilitate.
Blocurile individuale pot fi scalate atât pe verticală, cât și pe orizontală. Întregul sistem trebuie să fie capabil de o creștere orizontală infinită; - Оtoleranta la greseli.
Toate nivelurile și toate serviciile ar trebui să se poată recupera automat după defecțiuni; - Гtimp de răspuns garantat.
Timpul este valoros și utilizatorii nu ar trebui să aștepte prea mult.
Îți amintești de vechiul basm despre „Micul motor care ar putea”? Pentru ca sistemul proiectat să iasă cu succes din etapa de prototip și să fie progresiv, fundația sa trebuie să îndeplinească cerințele minime SMOG.
Încă un punct se adaugă mesageriei ca instrument de infrastructură și bază pentru toate serviciile: ușurința de utilizare pentru programatori.
Orientat pe evenimente
Pentru ca o aplicație să se dezvolte de la un singur server la un cluster, arhitectura sa trebuie să suporte cuplare liberă. Modelul asincron îndeplinește această cerință. În ea, expeditorul și destinatarul îi pasă de încărcarea de informații a mesajului și nu își fac griji cu privire la transmiterea și rutarea în cadrul sistemului.
Scalabilitate
Scalabilitatea și eficiența sistemului sunt una lângă alta. Componentele aplicației trebuie să poată utiliza toate resursele disponibile. Cu cât putem utiliza mai eficient capacitatea și cu cât metodele noastre de procesare sunt mai optime, cu atât cheltuim mai puțini bani pe echipamente.
Într-o singură mașină, Erlang creează un mediu extrem de competitiv. Echilibrul dintre concurență și paralelism poate fi stabilit prin alegerea numărului de fire de execuție ale sistemului de operare disponibile pentru VM Erlang și a numărului de programatori care utilizează aceste fire.
Procesele Erlang nu împart starea și funcționează în modul neblocant. Acest lucru oferă o latență relativ scăzută și un randament mai mare decât aplicațiile tradiționale bazate pe blocare. Planificatorul Erlang asigură alocarea corectă a CPU și IO, iar absența blocării permite aplicației să răspundă chiar și în timpul sarcinilor de vârf sau defecțiunilor.
La nivel de cluster, există și problema cu eliminarea. Este important ca toate mașinile din cluster să fie încărcate uniform și ca rețeaua să nu fie supraîncărcată. Să ne imaginăm o situație: traficul utilizatorilor aterizează pe balansoarele de intrare (haproxy, nginx, etc), ei distribuie cererile de procesare cât mai uniform posibil între setul de backend-uri disponibile. În cadrul infrastructurii aplicației, serviciul care implementează interfața necesară este doar ultimul kilometru și va trebui să solicite o serie de alte servicii pentru a răspunde cererii inițiale. Cererile interne necesită, de asemenea, rutare și echilibrare.
Pentru a gestiona eficient fluxurile de date, mesageria trebuie să ofere dezvoltatorilor o interfață pentru a gestiona rutarea și echilibrarea încărcăturii. Datorită acestui fapt, dezvoltatorii vor putea, folosind modele de microservicii (agregator, proxy, lanț, ramură etc.), să rezolve atât problemele standard, cât și cele care apar rar.
Din punct de vedere al afacerii, scalabilitatea este unul dintre instrumentele de management al riscului. Principalul lucru este de a satisface cerințele clienților prin utilizarea optimă a echipamentului:
- Când puterea echipamentului crește ca urmare a progresului. Nu va fi inactiv din cauza software-ului imperfect. Erlang se scalează bine pe verticală și va putea întotdeauna să utilizeze toate nucleele CPU și memoria disponibilă;
- În mediile cloud, putem gestiona cantitatea de echipamente în funcție de sarcina curentă sau estimată și putem garanta SLA.
toleranta la greseli
Să luăm în considerare două axiome: „Eșecurile sunt inacceptabile” și „Întotdeauna vor exista eșecuri”. Pentru o afacere, eșecul software înseamnă pierderea de bani și, ceea ce este mai rău, pierderea reputației. Echilibrarea între posibilele pierderi și costul dezvoltării unui software tolerant la erori, se poate găsi adesea un compromis.
Pe termen scurt, o arhitectură care încorporează toleranța la erori economisește bani pentru achiziționarea de soluții de clustering de la raft. Sunt scumpe și au și bug-uri.
Pe termen lung, o arhitectură tolerantă la erori se amortizează de multe ori în toate etapele de dezvoltare.
Mesageria din baza de cod vă permite să stabiliți în detaliu interacțiunea componentelor din cadrul sistemului în etapa de dezvoltare. Acest lucru simplifică sarcina de a răspunde și de a gestiona defecțiunile, deoarece toate componentele critice gestionează defecțiunile, iar sistemul rezultat știe cum să revină automat la normal după o defecțiune prin proiectare.
Receptivitatea
Indiferent de eșecuri, aplicația trebuie să răspundă solicitărilor și să respecte SLA. Realitatea este că oamenii nu vor să aștepte, așa că companiile trebuie să se adapteze în consecință. Din ce în ce mai multe aplicații sunt de așteptat să fie foarte receptive.
Aplicațiile responsive funcționează aproape în timp real. Erlang VM funcționează în modul soft în timp real. Pentru unele domenii, cum ar fi tranzacționarea acțiunilor, medicamentele și controlul echipamentelor industriale, modul dur în timp real este important.
Sistemele responsive îmbunătățesc UX și beneficiază de afaceri.
Rezumat preliminar
Când am planificat acest articol, am vrut să împărtășesc experiența mea de a crea un broker de mesagerie și de a construi sisteme complexe bazate pe acesta. Dar partea teoretică și motivațională s-a dovedit a fi destul de extinsă.
În a doua parte a articolului, voi vorbi despre nuanțele implementării punctelor de schimb, modelele de mesagerie și aplicarea acestora.
În a treia parte vom lua în considerare aspectele generale de organizare a serviciilor, rutare și echilibrare. Să vorbim despre partea practică a scalabilității și toleranței la erori a sistemelor.
Sfârșitul primei părți.
fotografie .
Sursa: www.habr.com