Lumea nu stă pe loc. Progresul creează noi provocări tehnologice. În conformitate cu cerințele care s-au schimbat, arhitectura sistemelor informaționale trebuie să evolueze. Astăzi, vom vorbi despre arhitectura orientată pe evenimente, concurență, paralelism, asincronitate și despre cum putem coexista cu toate acestea în Erlang.
Introducere
În funcție de dimensiunile sistemului proiectat și de cerințele acestuia, noi, dezvoltatorii, alegem modalitatea de schimb de informații din sistem. În cea mai mare parte, pentru a organiza interacțiunea serviciilor, varianta de lucru poate fi un schema cu broker, de exemplu, bazată pe RabbitMQ sau Kafka. Dar uneori fluxul de evenimente, SLA și nivelul de control asupra sistemului sunt astfel încât soluția de messaging existentă nu este potrivită. Bineînțeles, putem complica puțin sistemul, asumându-ne responsabilitatea pentru nivelul de transport și formarea clusterului, de exemplu folosind ZeroMQ sau nanomsg. Dar dacă sistemului îi ajunge capacitatea de procesare și funcționalitățile clusterului Erlang standard, atunci introducerea unei entități suplimentare necesită o analiză detaliată și o justificare economică.
Tema aplicațiilor distribuite reactiv este destul de amplă. Pentru a ne încadra în formatul articolului, subiectul discuției de astăzi va fi doar mediile omogene, construite pe baza Erlang/Elixir. Ecosistemul Erlang/OTP permite implementarea unei arhitecturi reactive cu costuri de muncă minime. Dar, în orice caz, va fi necesar un strat de schimb de mesaje.
Baza teoretică
Proiectarea începe cu definirea obiectivelor și constrângerilor. Obiectivul principal nu se află în domeniul dezvoltării doar de dragul dezvoltării. Trebuie să obținem un instrument sigur și scalabil, pe baza căruia să putem crea, și, cel mai important, să dezvoltăm aplicații moderne de diferite niveluri: de la aplicații pe un singur server, care deservesc o audiență mică, ce pot evolua ulterior în clustere de până la 50-60 de noduri, până la federații de clustere. Astfel, obiectivul principal este maximizarea profitului prin reducerea costurilor de dezvoltare și deținere a sistemului final.
Să evidențiem 4 cerințe principale pentru sistemul final:
- Cuorientarea pe evenimente.
Sistemul este întotdeauna pregătit să permită trecerea unui flux de evenimente și să efectueze acțiunile necesare; - Mscalabilitate.
Modulele separate pot fi scalate atât vertical, cât și orizontal. Întreaga sistemă trebuie să aibă capacitatea de a crește orizontal nelimitat; - Ofuranță.
Toate nivelurile și toate serviciile trebuie să aibă capacitatea de a se recupera automat în caz de eșecuri; - Garanție a timpului de răspuns.
Timpul este prețios, iar utilizatorii nu ar trebui să aștepte prea mult.
Țineți minte vechea poveste despre „The little engine that could”, cunoscut și ca „Păcăliciul care a reușit”? Pentru ca sistemul proiectat să iasă cu succes din faza de prototip și să fie progresiv, fundația sa trebuie să îndeplinească cerințele minime A REUȘIT.
În mesajele ca instrumente de infrastructură și fundație pentru toate serviciile, se adaugă încă un punct: ușurința de utilizare pentru programatori.
Orientarea pe evenimente
Pentru ca aplicația să poată crește de la una server la un cluster, arhitectura sa trebuie să asigure o slabă legătură. Această cerință este abordată de modelul asincron. În acesta, expeditorul și destinatarii se ocupă de sarcina informativă a mesajului și nu se îngrijesc de transmiterea și rutarea în cadrul sistemului.
Scalabilitate
Scalabilitatea și eficiența sistemului merg mână în mână. Componentele aplicației trebuie să fie capabile să utilizeze toate resursele disponibile. Cu cât reușim să utilizăm mai eficient capacitățile și metodele noastre de procesare sunt mai optime, cu atât cheltuim mai puțini bani pe echipamente.
În cadrul unei singure mașini, Erlang creează un mediu foarte concurențial. Echilibrul între concurență și paralelism poate fi stabilit prin alegerea numărului de firuri de execuție disponibile pentru Erlang VM și numărului de planificatori care utilizează aceste firuri.
Procesele Erlang nu au un stadiu comun și funcționează în mod neblocat. Acest lucru asigură o latență relativ scăzută și o lățime de bandă mai mare decât aplicațiile tradiționale bazate pe sincronizarea blocantă. Planificatorul Erlang se ocupă de distribuția corectă a CPU și IO, iar lipsa blocajelor permite aplicației să răspundă chiar și în timpul sarcinilor de vârf sau în caz de eșecuri.
La nivel de cluster, există și o problemă cu utilizarea resurselor. Este important ca toate mașinile din cluster să fie încărcate uniform, iar rețeaua să nu fie suprasolicitată. Să imaginăm o situație: traficul utilizatorilor aterizează pe balansoarele de încărcare (haproxy, nginx, etc.), care distribuie solicitarile cât mai uniform între setul de backend-uri disponibile. În cadrul infrastructurii aplicației, serviciul care realizează interfața necesară este doar ultimul segment, și va trebui să solicite o serie de alte servicii pentru a răspunde la solicitarea inițială. Solicitările interne necesită, de asemenea, rutare și echilibrare.
Pentru a gestiona eficient fluxurile de date, sistemul de mesagerie trebuie să ofere dezvoltatorilor o interfață pentru gestionarea rutării și distribuției sarcinii. Grație acestui fapt, dezvoltatorii vor putea, utilizând modele de microservicii (aggregator, proxy, chain, branch, etc.), să rezolve atât sarcinile standard, cât și pe cele rare.
Din perspectiva afacerii, scalabilitatea este un instrument de gestionare a riscurilor. Este esențial să satisfacem cerințele clienților, utilizând optim echipamentele:
- Pe măsură ce puterea echipamentului crește datorită progresului tehnologic, acesta nu va sta nefolosit din cauza imperfecțiunilor software-ului. Erlang se scalează excelent vertical și va putea întotdeauna să utilizeze toate nucleele CPU și memoria disponibilă;
- În medii cloud, putem gestiona cantitatea de echipamente în funcție de sarcina actuală sau preconizată și putem garanta SLA.
Redundanță
Să luăm în considerare două axiome: „Defectele sunt inacceptabile” și „Defectele se vor întâmpla întotdeauna”. Pentru afaceri, eșecul software-ului înseamnă pierdere de bani și, ceea ce este și mai rău, pierderea reputației. Balansând între pierderile posibile și costul dezvoltării unui software rezistent la defecte, se poate găsi adesea un compromis.
Pe termen scurt, o arhitectură în care este realizată rezistența la defecte economisește bani prin achiziționarea de soluții gata făcute pentru clusterizare. Acestea sunt scumpe și au erori.
Pe termen lung, o arhitectură rezistentă la defecte își recuperează costurile de aplicare de mai multe ori în toate etapele de dezvoltare.
Mesajele din cadrul codului sursă sunt încă în dezvoltare, ceea ce permite detalierea interacțiunilor componentelor din sistem. Aceasta simplifică sarcina de reacție și gestionare a erorilor, deoarece toate componentele responsabile gestionează defecțiunile, iar sistemul final știe cum să revină automat la starea normală după o defecțiune, prin design.
Reactivitate
Indiferent de erori, aplicația trebuie să răspundă la cereri și să respecte SLA. Realitatea este că oamenii nu doresc să aștepte, astfel că afacerea trebuie să se adapteze. Din ce în ce mai multe aplicații sunt așteptate să ofere o reacție rapidă.
Aplicațiile reactive funcționează într-un mod aproape în timp real. Erlang VM operează în modul de timp real moale. Pentru anumite domenii, cum ar fi tranzacțiile bursiere, medicina sau gestionarea echipamentelor industriale, este important un mod de timp real strict.
Sistemele reactive îmbunătățesc UX-ul și sunt utile pentru afaceri.
Rezumat preliminar
În planificarea acestui articol, am dorit să împărtășesc experiența de a crea un broker de mesaje și de a construi sisteme complexe pe baza acestuia. Dar partea teoretică și motivațională a devenit destul de amplă.
În a doua parte a articolului, voi vorbi despre nuanțele implementării punctelor de schimb, șabloanele de schimb de mesaje și aplicarea acestora.
În a treia parte, vom analiza întrebările generale legate de organizarea serviciilor, rutare și balansare. Vom discuta despre aspectele practice ale scalabilității și rezilienței sistemelor.
Sfârșitul primei părți.
Fotografie .
Sursa: habr.com
