Arhitectura unui sistem de control distribuit bazat pe mediul de calcul multi-pipeline reconfigurabil L-Net. Arhitectura sistemelor distribuite

Principii pentru crearea unui sistem de procesare a informațiilor la scară întreprindere

Istoria dezvoltării echipamente informatice(și în mod corespunzător software) a început cu sisteme separate, autonome. Oamenii de știință și inginerii au fost preocupați de crearea primelor computere și în mare parte nedumeriți cu privire la modul de a face aceste grupuri de tuburi vidate să funcționeze. Cu toate acestea, această stare de lucruri nu a durat mult - ideea de a combina puterea de calcul era destul de evidentă și era în aer, saturată de zumzetul dulapurilor metalice ale primelor ENIAK și mărci. La urma urmei, ideea de a combina eforturile a două sau mai multe computere pentru a rezolva sarcini complexe care depășesc capacitățile fiecăruia dintre ele individual se află la suprafață.

Orez. 1. Schema calcul distribuit

in orice caz implementare practică ideea de a conecta computere în clustere și rețele a fost împiedicată de lipsa solutii tehniceși, în primul rând, necesitatea creării de standarde și protocoale de interacțiune. După cum știți, primele computere au apărut la sfârșitul anilor patruzeci ai secolului XX, iar prima rețea de calculatoare ARPANet, care a conectat mai multe computere din Statele Unite, a apărut abia în 1966, aproape douăzeci de ani mai târziu. Desigur, o astfel de combinație de capabilități de calcul semăna foarte vag cu arhitectura distribuită modernă, dar totuși a fost primul pas în direcția corectă.

Aspect rețele locale De-a lungul timpului, a condus la dezvoltarea unei noi zone de dezvoltare software - crearea de aplicații distribuite. A trebuit să facem asta, după cum se spune, de la zero, dar, din fericire, oamenii s-au arătat imediat interesați de astfel de aplicații companii mari, a căror structură de afaceri necesita astfel de soluții. În etapa creării aplicațiilor distribuite corporative s-au format cerințele de bază și s-au dezvoltat arhitecturile de bază ale unor astfel de sisteme, care sunt utilizate și astăzi.

Treptat, mainframe-urile și terminalele au evoluat către o arhitectură client-server, care a fost în esență prima versiune a unei arhitecturi distribuite, adică un sistem distribuit pe două niveluri. La urma urmei, în aplicațiile client-server o parte din operațiunile de calcul și logica de afaceri a fost transferată în partea clientului, care, de fapt, a devenit punctul culminant, carte de vizită această abordare.

În această perioadă a devenit evident că principalele avantaje ale aplicațiilor distribuite sunt:

· scalabilitate bună – dacă este necesar, puterea de calcul a unei aplicații distribuite poate fi crescută cu ușurință fără a-i modifica structura;

· capacitatea de a gestiona încărcarea - nivelurile intermediare ale unei aplicații distribuite fac posibilă gestionarea fluxurilor de solicitări ale utilizatorilor și redirecționarea acestora către servere mai puțin încărcate pentru procesare;

· globalitate - o structură distribuită vă permite să urmăriți distribuția spațială a proceselor de afaceri și să creați locuri de muncă pentru clienți în cele mai convenabile puncte.

Odată cu trecerea timpului, mici insule de rețele universitare, guvernamentale și corporative s-au extins, s-au fuzionat în rețele regionale și sistemele naționale. Și apoi a apărut jucătorul principal pe scenă - Internetul.

Elogii adresate lui World wide web au devenit de mult un loc obișnuit pentru publicații despre subiecte informatice. Într-adevăr, Internetul a jucat un rol decisiv în dezvoltarea calculului distribuit și a făcut din această zonă destul de specializată a dezvoltării software-ului punctul central al unei armate de programatori profesioniști. Astăzi, extinde semnificativ capacitățile aplicațiilor distribuite, permițându-vă să conectați utilizatori la distanță și făcând disponibile funcțiile aplicațiilor peste tot.

Aceasta este istoria problemei. Acum să ne uităm la ce sunt aplicațiile distribuite.

Paradigma de calcul distribuit

Imaginează-ți o întreprindere de producție, o companie comercială sau o companie de servicii destul de mare. Toate diviziile lor au deja propriile baze de date și software specific. Oficiul central colectează cumva informații despre activitățile curente ale acestor unități și oferă managerilor informații pe baza cărora aceștia iau decizii de management.

Să mergem mai departe și să presupunem că organizația pe care o luăm în considerare se dezvoltă cu succes, deschide filiale și dezvoltă noi tipuri de produse sau servicii. Mai mult, managerii progresisti la ultima intalnire au decis sa organizeze o retea de locuri de munca la distanta de la care clientii sa primeasca cateva informatii despre onorarea comenzilor lor.

În situația descrisă, șeful departamentului IT nu se poate milă decât dacă nu s-a ocupat de construcție sistem comun gestionarea fluxurilor de afaceri, deoarece fără ea să se asigure dezvoltare eficientă va fi foarte greu pentru organizație. În plus, este imposibil să faci fără un sistem de procesare a informațiilor la scară întreprindere, conceput ținând cont de sarcina în creștere și, în plus, corespunzător principalelor fluxuri de afaceri, deoarece toate departamentele trebuie să își îndeplinească nu numai sarcinile, ci și, dacă este necesar, procesează cereri de la alte departamente și chiar (un coșmar pentru un manager de proiect!) clienți.

Deci, suntem gata să formulăm cerințele de bază pentru aplicatii moderne amploarea întreprinderii, dictată de organizarea însuși a procesului de producție.

Separarea spațială. Diviziile organizaționale sunt răspândite în spațiu și au adesea software slab unificat.

Conformitatea structurală. Software-ul trebuie să reflecte în mod adecvat structura informatieiîntreprinderi - respectă principalele fluxuri de date.

Se concentreze pe informatii externe. Întreprinderile moderne sunt forțate să acorde o atenție sporită lucrului cu clienții. Prin urmare, software-ul pentru întreprinderi trebuie să poată lucra cu un nou tip de utilizator și cu solicitările acestora. Astfel de utilizatori au, evident drepturi limitateși au acces la un tip de date strict definit.

Toate cerințele enumerate pentru software-ul la scară întreprindere sunt îndeplinite de sistemele distribuite - diagrama de distribuție a calculului este prezentată în Fig. 1.

Desigur, aplicațiile distribuite nu sunt lipsite de deficiențe. În primul rând, sunt costisitoare de exploatat și, în al doilea rând, crearea unor astfel de aplicații este un proces complex și care necesită multă muncă, iar costul unei erori în etapa de proiectare este foarte mare. Cu toate acestea, dezvoltarea aplicațiilor distribuite se dezvoltă cu succes - la urma urmei, jocul merită lumânarea, deoarece un astfel de software ajută la îmbunătățirea eficienței organizației.

Deci, paradigma de calcul distribuit presupune prezența mai multor centre (servere) pentru stocarea și procesarea informațiilor care implementează diverse funcțiiși distanțate în spațiu. Pe lângă solicitările de la clienții de sistem, aceste centre trebuie să îndeplinească și cererile reciproc, deoarece în unele cazuri eforturile comune ale mai multor servere pot fi necesare pentru a rezolva prima sarcină. Pentru a gestiona interogările complexe și funcționarea sistemului în ansamblu, este necesar un software de management specializat. Și, în sfârșit, întregul sistem trebuie să fie „cufundat” într-un fel de mediu de transport care să asigure interacțiunea părților sale.

Distribuit sisteme de calcul au următoarele proprietăți generale:

· controlabilitate - implică capacitatea unui sistem de a-și controla eficient componentele. Acest lucru se realizează prin utilizarea unui software de control;

· performanta - asigurata de capacitatea de a redistribui sarcina pe serverele de sistem folosind software de management;

· scalabilitate – dacă este necesară creșterea fizică a productivității, un sistem distribuit poate integra cu ușurință noi resurse de calcul în mediul său de transport;

· extensibilitate – la aplicațiile distribuite pot fi adăugate noi componente (software server) cu funcții noi.

Accesul la date din aplicațiile distribuite este posibil din software-ul client și alte sisteme distribuite pot fi organizate la diferite niveluri - de la software-ul client și protocoalele de transport până la protejarea serverelor de baze de date.

Orez. 2. Principalele niveluri ale arhitecturii aplicațiilor distribuite

Proprietățile enumerate ale sistemelor distribuite sunt un motiv suficient pentru a suporta complexitatea dezvoltării lor și costul ridicat de întreținere.

Arhitectura aplicațiilor distribuite

Să ne uităm la arhitectura unei aplicații distribuite care îi permite să îndeplinească funcții complexe și variate. ÎN surse diferite Sunt prezentate diferite opțiuni pentru construirea de aplicații distribuite. Și toți au dreptul să existe, deoarece astfel de aplicații rezolvă o gamă largă de probleme în multe domenii, iar dezvoltarea de neoprit a instrumentelor și tehnologiilor de dezvoltare împinge pentru îmbunătățirea continuă.

Cu toate acestea, există cele mai multe arhitectura generala aplicație distribuită, conform căreia este împărțită în mai multe straturi logice, niveluri de procesare a datelor. Aplicațiile, după cum știți, sunt concepute pentru a procesa informații și aici putem evidenția trei dintre cele mai importante funcții ale acestora:

· prezentarea datelor (nivel de utilizator). Aici utilizatorii aplicației pot vizualiza datele necesare, pot trimite o cerere de execuție, pot introduce date noi în sistem sau le pot edita;

· prelucrarea datelor (nivel intermediar, middleware). La acest nivel se concentrează logica de business a aplicației, se gestionează fluxurile de date și se organizează interacțiunea părților aplicației. Concentrarea tuturor funcțiilor de prelucrare și control a datelor la un nivel este considerată principalul avantaj al aplicațiilor distribuite;

· stocarea datelor (stratul de date). Acesta este nivelul serverului de baze de date. Serverele în sine, bazele de date, instrumentele de acces la date și diverse instrumente auxiliare se află aici.

Această arhitectură este adesea numită trei niveluri sau trei niveluri. Și de foarte multe ori, pe baza acestor „trei piloni”, se creează structura aplicației în curs de dezvoltare. Se remarcă întotdeauna că fiecare nivel poate fi împărțit în mai multe subniveluri. De exemplu, nivelul de utilizator poate fi împărțit în interfața cu utilizatorulși reguli pentru validarea și prelucrarea datelor de intrare.

Desigur, dacă luăm în considerare posibilitatea de partiționare în subnivele, atunci orice aplicație distribuită poate fi încadrată într-o arhitectură cu trei niveluri. Dar aici nu se poate să nu țină cont de încă o trăsătură caracteristică inerentă aplicațiilor distribuite - managementul datelor. Importanța acestei caracteristici este evidentă deoarece este foarte dificil să se creeze o aplicație distribuită care rulează cu adevărat (cu toate stațiile client, middleware, servere de baze de date etc.) care să nu gestioneze cererile și răspunsurile sale. Prin urmare, o aplicație distribuită trebuie să aibă încă un nivel logic - nivelul de gestionare a datelor.

Orez. 3. Distribuția logicii de afaceri pe nivelurile unei aplicații distribuite

Prin urmare, este recomandabil să împărțiți nivelul intermediar în două independente: nivelul de prelucrare a datelor (deoarece este necesar să se țină cont de avantaj important ceea ce dă este concentrarea regulilor de afaceri pentru prelucrarea datelor) și nivelul managementului datelor. Acesta din urmă asigură controlul asupra executării solicitărilor, gestionează fluxurile de date și organizează interacțiunea părților sistemului.

Astfel, se pot distinge patru niveluri principale ale arhitecturii distribuite (vezi Fig. 2):

· prezentarea datelor (nivel de utilizator);

· reguli de logica de afaceri (nivel de prelucrare a datelor);

· managementul datelor (nivel de management al datelor);

· stocarea datelor (nivel de stocare a datelor).

Trei dintre cele patru niveluri, excluzând primul, sunt direct implicate în prelucrarea datelor, iar nivelul de prezentare a datelor vă permite să le vizualizați și să le editați. Folosind acest strat, utilizatorii primesc date de la nivelul de procesare a datelor, care, la rândul său, preia informațiile din stocare și realizează toate transformările necesare ale datelor. După intrare informație nouă sau editarea unuia existent, fluxurile de date sunt direcționate în direcția opusă: de la interfața cu utilizatorul prin stratul de reguli de afaceri până la depozit.

Un alt nivel - managementul datelor - se deosebește de fluxul de date principal, dar asigură buna funcționare a întregului sistem prin gestionarea cererilor și răspunsurilor și a interacțiunii unor părți ale aplicației.

Separat, este necesar să se ia în considerare opțiunea de vizualizare a datelor în modul doar citire. În acest caz, stratul de prelucrare a datelor nu este utilizat în schema generala transfer de date, deoarece nu este nevoie să faceți nicio modificare. Iar fluxul de informații în sine este unidirecțional - de la stocare până la nivelul de prezentare a datelor.

Structura fizică a aplicațiilor distribuite

Acum să ne întoarcem la niveluri fizice aplicatii distribuite. Topologia unui sistem distribuit presupune împărțirea în mai multe servere de baze de date, servere de procesare a datelor și un set de clienți locali și la distanță. Toate pot fi amplasate oriunde: în aceeași clădire sau pe alt continent. În orice caz, părțile unui sistem distribuit trebuie să fie conectate prin linii de comunicație fiabile și sigure. În ceea ce privește viteza de transfer al datelor, aceasta depinde în mare măsură de importanța conexiunii dintre cele două părți ale sistemului în ceea ce privește prelucrarea și transmiterea datelor și, într-o măsură mai mică, de distanța acestora.

Distribuția logicii de afaceri pe nivelurile unei aplicații distribuite

Este timpul să trecem la o descriere detaliată a nivelurilor unui sistem distribuit, dar mai întâi să spunem câteva cuvinte despre distribuția funcționalității aplicației pe niveluri. Logica de afaceri poate fi implementată la oricare dintre nivelurile arhitecturii pe trei niveluri.

Serverele de baze de date nu numai că pot stoca date în baze de date, ci și pot conține o parte din logica de afaceri a aplicației în proceduri stocate, declanșatoare etc.

Aplicațiile client pot implementa și reguli de prelucrare a datelor. Dacă setul de reguli este minim și se reduce în principal la proceduri de verificare a corectitudinii introducerii datelor, avem de-a face cu un client „subțire”. Un client gros, pe de altă parte, conține o mare parte din funcționalitatea aplicației.

Nivelul de prelucrare a datelor este de fapt destinat să implementeze logica de afaceri a aplicației, iar aici sunt concentrate toate regulile de bază pentru prelucrarea datelor.

Astfel, în cazul general, funcționalitatea aplicației este „răspândită” în întreaga aplicație. Întreaga varietate de distribuție a logicii de afaceri între nivelurile de aplicație poate fi reprezentată ca o curbă netedă care arată proporția regulilor de procesare a datelor concentrate într-un anumit loc. Curbele din fig. 3 sunt de natură calitativă, dar totuși ne permit să vedem cum modificările în structura aplicației pot afecta distribuția regulilor.

Iar practica confirmă această concluzie. La urma urmei, există întotdeauna câteva reguli care trebuie implementate în mod specific în procedurile stocate ale serverului de baze de date și, foarte adesea, este convenabil să transferați unele operațiuni inițiale cu date către partea clientului - cel puțin pentru a preveni procesarea cereri incorecte.

Stratul de prezentare a datelor

Nivelul de prezentare a datelor este singurul disponibil Utilizator final. Acest nivel modelează stațiile de lucru client ale unei aplicații distribuite și software-ul corespunzător. Capacitățile stației de lucru client sunt determinate în primul rând de capacitățile sistemului de operare. În funcție de tipul de interfață cu utilizatorul, software-ul client este împărțit în două grupuri: clienți care utilizează capabilități GUI (de exemplu, Windows) și clienți web. Dar, în orice caz, aplicația client trebuie să asigure execuția următoarele funcții:

· obținerea datelor;

· prezentarea datelor pentru vizualizare de către utilizator;

· editarea datelor;

· verificarea corectitudinii datelor introduse;

· salvarea modificărilor efectuate;

· Gestionarea excepțiilor și afișarea informațiilor despre erori către utilizator.

Este de dorit să se concentreze toate regulile de afaceri la nivelul de prelucrare a datelor, dar în practică acest lucru nu este întotdeauna posibil. Apoi vorbesc despre două tipuri de software client. Clientul subțire conține set minim regulile de afaceri, iar cea „grasă” implementează o parte semnificativă a logicii aplicației. În primul caz, o aplicație distribuită este mult mai ușor de depanat, modernizat și extins, în al doilea, costurile de creare și întreținere a unui nivel de gestionare a datelor pot fi reduse la minimum, deoarece unele operațiuni pot fi efectuate pe partea clientului, iar doar datele; transferul cade pe middleware.

Stratul de prelucrare a datelor

Stratul de procesare a datelor combină părțile care implementează logica de afaceri a aplicației și acționează ca intermediar între stratul de prezentare a datelor și stratul de stocare a datelor. Toate datele trec prin el și suferă modificări în ea datorită problemei care se rezolvă (vezi Fig. 2). Funcțiile acestui nivel includ următoarele:

· procesarea fluxurilor de date în conformitate cu regulile de afaceri;

· interacțiunea cu stratul de prezentare a datelor pentru a primi cereri și a returna răspunsuri;

· interacțiunea cu stratul de stocare a datelor pentru a transmite cereri și a primi răspunsuri.

Cel mai adesea, stratul de procesare a datelor este identificat cu middleware-ul unei aplicații distribuite. Această situație este pe deplin adevărată pentru un sistem „ideal” și numai parțial adevărată pentru aplicații reale(vezi Fig. 3). În ceea ce privește acestea din urmă, middleware-ul pentru ei conține o mare parte a regulilor de procesare a datelor, dar unele dintre ele sunt implementate în serverele SQL sub formă de proceduri stocate sau declanșatoare, iar unele sunt incluse în software-ul client.

Această „încețoșare” a logicii de afaceri este justificată, deoarece ne permite să simplificăm unele dintre procedurile de prelucrare a datelor. Să luăm exemplul clasic de emitere a unei comenzi. Acesta poate include numai numele acelor produse care sunt în stoc. Prin urmare, atunci când adăugați un anumit articol la o comandă și determinați cantitatea acestuia, numărul corespunzător trebuie scăzut din soldul acestui articol din depozit. Evident, cel mai bine este să implementați această logică folosind serverul de baze de date - o procedură stocată sau un declanșator.

Stratul de gestionare a datelor

Nivelul de gestionare a datelor este necesar pentru a se asigura că aplicația rămâne un întreg, este stabilă și fiabilă și are capacitatea de a se moderniza și scala. Se impune sarcini de sistem, fără ea, părți ale aplicației (servere de baze de date, servere de aplicații, middleware, clienți) nu vor putea comunica între ele, iar conexiunile întrerupte atunci când sarcina crește nu pot fi restabilite.

În plus, la nivelul de management al datelor pot fi implementate diverse servicii de sistem de aplicații. La urma urmei, există întotdeauna funcții comune întregii aplicații care sunt necesare pentru funcționarea tuturor nivelurilor aplicației, prin urmare, acestea nu pot fi localizate la niciunul dintre celelalte niveluri.

De exemplu, un serviciu de timp unificat oferă tuturor părților unei aplicații marcaje temporale ale sistemului care le mențin sincronizate. Imaginați-vă că o aplicație distribuită are un server care trimite sarcini clienților indicând un anumit termen limită pentru finalizarea acestora. Dacă termenul limită este ratat, sarcina trebuie înregistrată cu timpul de întârziere calculat. Dacă stațiile de lucru client sunt situate în aceeași clădire cu serverul, sau pe o stradă învecinată, nu este nicio problemă, algoritmul de contabilitate este simplu. Dar ce se întâmplă dacă clienții sunt localizați în alte fusuri orare - în alte țări sau chiar în străinătate? În acest caz, serverul trebuie să poată calcula diferențele pe baza fusului orar atunci când trimite joburi și primește răspunsuri, iar clienților li se va cere să adauge informații despre serviciu despre ora locală și fusul orar la rapoarte. Dacă aplicația distribuită include un serviciu unic, atunci această problemă pur și simplu nu există.

În plus față de serviciul de timp uniform, stratul de gestionare a datelor poate conține servicii de stocare Informații generale(informații despre aplicație în ansamblu), generarea de rapoarte generale etc.

Deci, funcțiile stratului de gestionare a datelor includ:

· gestionarea părților unei aplicații distribuite;

· gestionarea conexiunilor și canalelor de comunicare între părți ale aplicației;

· gestionarea fluxurilor de date între clienți și servere și între servere;

· managementul sarcinii;

· implementare servicii de sistem aplicatii.

Trebuie remarcat faptul că stratul de gestionare a datelor este adesea creat pe baza unor soluții gata făcute furnizate pieței de software de diverși producători. Dacă dezvoltatorii au ales arhitectura CORBA pentru aplicația lor, atunci aceasta include un broker de cerere de obiecte (ORB), dacă platforma este Windows, au la dispoziție o varietate de instrumente: tehnologia COM+ (dezvoltare Microsoft Transaction Server, tehnologie MTS). ), tehnologia de procesare a cozilor de mesaje MSMQ, tehnologia Microsoft BizTalk etc.

Nivel de stocare a datelor

Nivelul de stocare a datelor combină serverele SQL și bazele de date utilizate de aplicație. Oferă soluții pentru următoarele sarcini:

· stocarea datelor într-o bază de date și menținerea acestora în stare de funcționare;

· procesarea cererilor la nivel de prelucrare a datelor si returnarea rezultatelor;

· implementarea unei părți a logicii de business a unei aplicații distribuite;

management baze de date distribuite date folosind instrumentele administrative ale serverelor de baze de date.

Pe lângă funcțiile evidente - stocarea datelor și procesarea interogărilor, nivelul poate conține o parte din logica de afaceri a aplicației în proceduri stocate, declanșatoare, constrângeri etc. Și structura bazei de date a aplicației în sine (tabele și câmpurile acestora, indecși, chei externe, etc.) ) există o implementare a structurii de date cu care funcționează aplicația distribuită și o implementare a unor reguli de logica de afaceri. De exemplu, utilizarea unei chei străine într-un tabel al bazei de date necesită crearea unei restricții corespunzătoare privind manipularea datelor, deoarece înregistrările din tabelul principal nu pot fi șterse dacă există înregistrări corespunzătoare legate de cheie externă Mese.

Majoritatea serverelor de baze de date suportă o varietate de proceduri de administrare, inclusiv gestionarea bazelor de date distribuite. Acestea includ replicarea datelor, arhivarea de la distanță, mijloacele de acces la baze de date la distanță date, etc. Posibilitatea de a utiliza aceste instrumente trebuie luată în considerare atunci când dezvoltați structura propriei aplicații distribuite.

Conectarea la baze de date Servere SQL realizate în principal folosind software-ul client-server. În plus, pot fi utilizate suplimentar diverse tehnologii de acces la date, de exemplu ADO (ActiveX Data Objects) sau ADO.NET. Dar la proiectarea unui sistem, este necesar să se țină cont de faptul că tehnologiile de acces la date intermediare din punct de vedere funcțional nu aparțin stratului de stocare a datelor.

Extensii la nivel de bază

Nivelurile de arhitectură a aplicațiilor distribuite discutate mai sus sunt de bază. Ele formează structura aplicația care se creeazăîn general, dar în același timp, firesc, nu pot asigura implementarea vreunei aplicații - domeniile și sarcinile sunt prea vaste și diverse. Pentru astfel de cazuri, arhitectura unei aplicații distribuite poate fi extinsă cu straturi suplimentare care sunt concepute pentru a reflecta caracteristicile aplicației create.

Printre altele, există două extensii cele mai frecvent utilizate ale nivelurilor de bază.

Stratul de interfață de afaceri se află între stratul de interfață cu utilizatorul și stratul de procesare a datelor. Se ascunde de aplicații client detalii privind structura și implementarea regulilor de business la nivel de prelucrare a datelor, asigurând abstracția codului de program al aplicațiilor client din caracteristicile de implementare ale logicii aplicației.

Ca rezultat, dezvoltatorii de aplicații client folosesc un anumit set de functiile necesare- analog al interfeței de programare a aplicațiilor (API). Acest lucru permite ca software-ul client să fie independent de implementarea stratului de procesare a datelor.

Desigur, atunci când faceți modificări majore în sistem, este imposibil să faceți fără modificări globale, dar nivelul interfeței de afaceri vă permite să nu faceți acest lucru decât dacă este absolut necesar.

Stratul de acces la date este situat între stratul de stocare a datelor și stratul de procesare a datelor. Vă permite să faceți structura aplicației independentă de o anumită tehnologie de stocare a datelor. În astfel de cazuri, obiectele software la nivel de procesare a datelor transmit cereri și primesc răspunsuri folosind tehnologia de acces la date selectată.

La implementarea aplicațiilor pe Platforma Windows Cea mai des folosită tehnologie de acces la date este ADO, deoarece oferă o modalitate universală de a accesa o mare varietate de surse de date - de la servere SQL la foi de calcul. Pentru aplicațiile pe platforma .NET se folosește tehnologia ADO.NET.

Sisteme multicalculatoare eterogene

Cel mai mare număr Sistemele distribuite existente în prezent sunt construite conform schemei multicomputer eterogene. Aceasta înseamnă că computerele care fac parte din acest sistem pot fi extrem de diverse, de exemplu, ca tip de procesor, dimensiunea memoriei și performanța I/O. În practică, rolul unora dintre aceste calculatoare poate fi îndeplinit de înalte performanțe sisteme paralele, de exemplu multiprocesor sau multicomputer omogen.

Rețeaua care le conectează poate fi, de asemenea, foarte eterogenă.

Un exemplu de eterogenitate este crearea de sisteme mari multicomputer folosind rețelele existenteși canale. De exemplu, existența unor sisteme distribuite universitare constând din rețele locale ale diferitelor facultăți interconectate prin canale de mare viteză nu este neobișnuită. ÎN sisteme globale diferite stații pot fi la rândul lor conectate prin rețele publice, de ex. servicii de rețea, oferit de operatorii comerciali de telecomunicații, de exemplu SMDS sau Releu cadru.

Spre deosebire de sistemele discutate în paragrafele anterioare, multe sisteme multicomputer eterogene la scară largă necesită o abordare globală. Aceasta înseamnă că aplicația nu poate presupune că anumite performanțe sau anumite servicii îi vor fi disponibile în orice moment.

Trecând la problemele de scalare inerente sistemelor eterogene și ținând cont de necesitatea unei abordări globale inerente majorității dintre ele, observăm că crearea de aplicații pentru sisteme multicomputer eterogene necesită software specializat. Sistemele distribuite fac față acestei probleme. Pentru a se asigura că dezvoltatorii de aplicații nu trebuie să-și facă griji cu privire la hardware-ul pe care îl folosesc, sistemele distribuite oferă un înveliș software care protejează aplicațiile de ceea ce se întâmplă în hardware (adică oferă transparență).

Cea mai veche și fundamentală arhitectură distribuită este arhitectura client-server, în care o parte (clientul) inițiază comunicarea prin trimiterea unei cereri către cealaltă parte (server). Serverul procesează cererea și, dacă este necesar, trimite un răspuns clientului (Fig. 2.7).

Orez. 2.7. Model de interacțiune client-server

Interacțiunea în cadrul modelului client-server poate fi fie sincronă, când clientul așteaptă ca serverul să finalizeze procesarea cererii sale, fie asincronă, în care clientul trimite o cerere către server și își continuă execuția fără a aștepta un răspuns din partea Server. Modelul client și server poate fi folosit ca bază pentru descrierea diferitelor interacțiuni. Luați în considerare interacțiunea componente software care formează un sistem distribuit.

Orez. 2.8. Niveluri logice de aplicație

Să luăm în considerare o aplicație tipică, care, în conformitate cu conceptele moderne, poate fi împărțită în următoarele niveluri logice (Fig. 2.8): interfață cu utilizatorul (UI), logica aplicației (AL) și accesul la date (DA), lucrând cu o bază de date (DB). Utilizatorul sistemului interacționează cu acesta prin intermediul interfeței cu utilizatorul, baza de date stochează descrierea datelor domeniul subiectului aplicația, iar stratul logic al aplicației implementează toți algoritmii legați de domeniul aplicației.

Întrucât în practică diferiți utilizatori ai unui sistem sunt de obicei interesați să acceseze aceleași date, cel mai simplu mod de a distribui funcțiile unui astfel de sistem între mai multe computere este separarea niveluri logice aplicație între o parte de server a aplicației, responsabilă cu accesarea datelor, și părțile client situate pe mai multe computere, implementând interfața cu utilizatorul. Logica aplicației poate fi atribuită serverului, clienților sau împărțită între aceștia (Figura 2.9).

Orez. 2.9. Arhitectură cu două niveluri

Arhitectura aplicațiilor construite pe acest principiu se numește client-server sau cu două legături. În practică, astfel de sisteme nu sunt adesea clasificate ca fiind distribuite, dar formal pot fi considerate cei mai simpli reprezentanți ai sistemelor distribuite.

Dezvoltarea arhitecturii client-server este arhitectura pe trei niveluri, în care interfața cu utilizatorul, logica aplicației și accesul la date sunt separate în componente independente ale sistemului care pot rula pe computere independente (Figura 2.10).

Orez. 2.10. Arhitectură cu trei niveluri

Cererea utilizatorului în astfel de sisteme este procesată secvenţial de partea client a sistemului, serverul logic al aplicaţiei şi serverul bazei de date. Cu toate acestea, de obicei, un sistem distribuit este înțeles ca un sistem cu o arhitectură mai complexă decât una cu trei niveluri.

Orez. 2.11. Sistem distribuit vânzări cu amănuntul

În legătură cu aplicațiile de automatizare a întreprinderilor, sistemele distribuite sunt de obicei numite sisteme cu logica aplicației distribuite între mai multe componente ale sistemului, fiecare dintre acestea putând fi executată pe un computer separat. De exemplu, implementarea logicii de aplicare a unui sistem de vânzări cu amănuntul trebuie să utilizeze cereri către logica de aplicare a terților, cum ar fi furnizorii de bunuri, sisteme plăți electronice sau băncile care oferă credite de consum (Figura 2.11).

Un alt exemplu de sistem distribuit sunt rețelele schimb direct de date între clienți (rețele peer-to-peer). Dacă exemplul anterior avea o arhitectură „arboresc”, atunci rețelele de schimb direct sunt organizate mai mult într-un mod complex, Figura 2.12. Există sisteme similare în prezent, probabil unul dintre cele mai mari sisteme distribuite existente, care conectează milioane de computere.

Orez. 2.12. Sistem de schimb direct de date între clienți

(Materialul site-ului http://se.math.spbu.ru)

Introducere.

Astăzi, aproape toate sistemele software mari sunt distribuite. Sistem distribuit- un sistem în care prelucrarea informațiilor nu este concentrată pe un singur computer, ci este distribuită între mai multe computere. La proiectarea sistemelor distribuite, care are multe în comun cu proiectarea de software în general, ar trebui să se țină seama de unele caracteristici specifice.

Există șase caracteristici principale ale sistemelor distribuite.

Partajarea resurselor. Sistemele distribuite permit partajarea resurse atât hardware (hard disk, imprimante), cât și software (fișiere, compilatoare).
Deschidere.Aceasta este capacitatea de a extinde sistemul prin adăugarea de noi resurse.
Paralelism.În sistemele distribuite, mai multe procese pot rula simultan pe diferite computere din rețea. Aceste procese pot interacționa în timp ce rulează.
Scalabilitate . Sub scalabilitate se înțelege posibilitatea de a adăuga noi proprietăți și metode.
Toleranta la erori. Prezența mai multor computere permite duplicarea informațiilor și rezistența la unele hardware și erori de software. Sistemele distribuite pot suporta funcționalitate parțială în cazul unei erori. O defecțiune completă a sistemului are loc numai în cazul unor erori de rețea.
Transparenţă.Utilizatorii sunt furnizați acces complet la resursele din sistem, în timp ce, în același timp, informațiile despre distribuția resurselor în întregul sistem sunt ascunse acestora.

Sistemele distribuite au, de asemenea, o serie de dezavantaje.

Complexitate. Este mult mai dificil de înțeles și de evaluat proprietățile sistemelor distribuite în ansamblu, acestea sunt mai dificil de proiectat, testat și întreținut. De asemenea, performanța sistemului depinde de viteza rețelei, nu de procesoarele individuale. Redistribuirea resurselor poate schimba semnificativ viteza sistemului.
Siguranță. De obicei, sistemul poate fi accesat din mai multe mașini diferite, mesajele din rețea pot fi vizualizate și interceptate. Prin urmare, este mult mai dificil să mențineți securitatea într-un sistem distribuit.
Controlabilitate. Sistemul poate consta din diferite tipuri de computere pe care pot fi instalate versiuni diferite sisteme de operare. Erorile de pe o mașină se pot răspândi în moduri imprevizibile la alte mașini.
Imprevizibilitate . Reacția sistemelor distribuite la unele evenimente este imprevizibilă și depinde de sarcina completa sistem, organizarea acestuia și încărcarea rețelei. Deoarece acești parametri se pot schimba constant, timpul de răspuns la o solicitare poate diferi semnificativ din când în când.

Din aceste neajunsuri, se poate observa că la proiectarea sistemelor distribuite apar o serie de probleme de care dezvoltatorii trebuie să țină cont.

Identificarea resurselor . Resursele din sistemele distribuite sunt situate pe computere diferite, astfel încât sistemul de denumire a resurselor ar trebui proiectat astfel încât utilizatorii să poată deschide cu ușurință și să facă referire la resursele de care au nevoie. Un exemplu este sistemul URL (Uniform Resource Locator), care definește numele paginilor Web.
Comunicare. Funcționalitatea universală a Internetului și implementarea eficientă a protocoalelor TCP/IP pe Internet pentru majoritatea sistemelor distribuite servesc ca exemplu al modului cel mai eficient de a organiza comunicarea între computere. Cu toate acestea, în unele cazuri în care sunt necesare performanțe sau fiabilitate speciale, pot fi utilizate instrumente specializate.
Calitatea serviciului sistemului . Acest parametru reflectă performanța, disponibilitatea și fiabilitatea. Calitatea serviciului este influențată de o serie de factori: distribuția proceselor, resurse, hardware și capabilități de adaptare a sistemului.
Arhitectura software . Arhitectura software descrie distribuția funcțiile sistemului de componentele sistemului, precum și distribuția acestor componente între procesoare. Dacă se dorește menținerea unui serviciu de sistem de înaltă calitate, alegerea arhitecturii potrivite este esențială.

Sarcina designerilor de sisteme distribuite este de a proiecta software și hardware pentru a oferi toate caracteristicile necesare unui sistem distribuit. Și aceasta necesită cunoașterea avantajelor și dezavantajelor diferitelor arhitecturi de sisteme distribuite. Există trei tipuri de arhitecturi de sistem distribuite.

Arhitectura client/server . În acest model, sistemul poate fi reprezentat ca set de servicii furnizate de servere clienților. În astfel de sisteme, serverele și clienții diferă semnificativ unul de celălalt.
Arhitectură cu trei niveluri . În acest model, serverul oferă servicii clienților nu direct, ci printr-un server logic de afaceri.

Primele două modele au fost deja menționate de mai multe ori să ne oprim mai în detaliu asupra celui de-al treilea.

Arhitectura obiectelor distribuite . În acest caz, nu există nicio diferență între servere și clienți, iar sistemul poate fi reprezentat ca un set de obiecte care interacționează, a căror locație nu contează. semnificație deosebită. Nu există nicio diferență între furnizorul de servicii și utilizatorii acestora.

Această arhitectură este utilizată pe scară largă în zilele noastre și mai este numită arhitecturi de servicii web. Un serviciu web este o aplicație accesibilă prin Internet și care furnizează unele servicii, a căror formă nu depinde de furnizor (de vreme ce se utilizează formatul universal de date - XML) și de platforma de operare. ÎN timp dat Există trei tehnologii diferite care susțin conceptul de sisteme de obiecte distribuite. Acestea sunt tehnologiile EJB, CORBA și DCOM.

În primul rând, câteva cuvinte despre ce este XML în general. XML este un format de date universal care este utilizat pentru a furniza servicii Web. Serviciile web se bazează pe standarde și protocoale deschise: SOAP, UDDI și WSDL.

SAPUN ( Simple Object Access Protocol), dezvoltat de consorțiul W3C, definește formatul cererilor către serviciile Web. Mesajele dintre un serviciu Web și utilizatorul acestuia sunt ambalate în așa-numitele plicuri SOAP (uneori numite și plicuri XML). Mesajul în sine poate conține fie o solicitare de a efectua o acțiune, fie un răspuns - rezultatul efectuării acestei acțiuni.
WSDL (Web Service Description Language).Interfața serviciului Web este descrisă în documentele WSDL (și WSDL este un subset de XML). Înainte de a implementa un serviciu, dezvoltatorul își scrie descrierea pe Limbajul WSDL, indică adresa serviciului Web, protocoalele acceptate, o listă de operațiuni acceptabile, formatele de solicitare și răspuns.
UDDI (Descriere universală, descoperire și integrare) - protocol pentru căutarea serviciilor Web pe Internet ( http://www.uddi.org/). Este un registru de afaceri în care furnizorii de servicii web înregistrează servicii, iar dezvoltatorii găsesc serviciile necesare pentru a le include în aplicațiile lor.

Din raport poate părea că serviciile Web sunt cea mai bună și nici o soluție alternativă, iar singura întrebare este alegerea instrumentelor de dezvoltare. Cu toate acestea, nu este. Există o alternativă la serviciile Web, Web-ul semantic, despre care a vorbit creatorul WWW Tim Berners-Lee în urmă cu cinci ani.

Dacă sarcina serviciilor Web este de a facilita comunicarea între aplicații, atunci Web-ul semantic este conceput să rezolve mult mai multe problema complexa- utilizarea mecanismelor de metadate pentru a crește eficacitatea valorii informațiilor care pot fi găsite pe Web. Acest lucru se poate face prin abandonarea abordării orientate pe document în favoarea uneia orientate pe obiecte.

Bibliografie

SommervilleI. Inginerie software.
Dranica A. Java vs. NET. - „Computerra”, #516.
Resurse de internet.

Traducere

M-am alăturat Uber acum doi ani ca dezvoltator mobil, care are ceva experiență în dezvoltarea backend. Aici dezvoltam funcționalitatea de plată în aplicație - și pe parcurs am rescris aplicația în sine. După care am trecut la managementul dezvoltatorilor și am condus echipa în sine. Acest lucru mi-a permis să devin mult mai familiar cu backend-ul, deoarece echipa mea este responsabilă pentru multe dintre sistemele noastre backend care permit plățile.

Înainte de a lucra la Uber, nu aveam experiență de lucru cu sisteme distribuite. Am primit o educație tradițională în Informatică, după care am lucrat în dezvoltare full-stack timp de zece ani. Deci, în timp ce aș putea să desenez diverse diagrame și să vorbesc despre compromisuri ( compromisuri) în sisteme, până atunci nu înțelegeam și nu percepeam suficient de bine conceptele de distribuție, cum ar fi consistența ( consistenta), disponibilitate ( disponibilitate) sau idempotenta ( idempotenta).

ÎN acest post Voi vorbi despre câteva dintre conceptele pe care trebuia să le învăț și să le pun în practică atunci când construiesc sistemul de plată distribuit pe scară largă, foarte disponibil, pe care îl rulează Uber astăzi. Acesta este un sistem cu o încărcare de până la câteva mii de solicitări pe secundă, în care funcționalitatea critică de plată trebuie să funcționeze corect chiar și în cazurile în care anumite părți ale sistemului nu mai funcționează.

Este aceasta o listă completă? Cel mai probabil nu. Cu toate acestea, dacă aș fi învățat personal despre aceste concepte mai devreme, mi-ar fi făcut viața mult mai ușoară.

Deci, să începem scufundarea în SLA, consistență, durabilitatea datelor, persistența mesajelor, idempotnța și alte lucruri pe care trebuia să le învăț în noul meu loc de muncă.

SLA

ÎN sisteme mari, care procesează milioane de evenimente pe zi, unele lucruri sunt pur și simplu obligate să meargă prost. De aceea, înainte de a vă aprofunda în planificarea sistemului, trebuie să faceți cel mai mult pas important- decideți ce înseamnă un sistem „sănătos” pentru noi. Gradul de „sănătate” trebuie să fie ceva care De fapt poate fi măsurat. O modalitate obișnuită de a măsura starea de sănătate a unui sistem este prin SLA-uri ( acorduri de nivel de servicii). Iată câteva dintre cele mai comune tipuri de SLA pe care le-am întâlnit în practică:

Disponibilitate: Procentul de timp în care serviciul este activ. Deși poate fi tentant să obțineți o disponibilitate de 100%, obținerea acestui rezultat poate fi cu adevărat o provocare și, de asemenea, destul de costisitoare. Chiar și sisteme mari și critice, cum ar fi o rețea carduri VISA, Gmail sau ISP-urile nu au disponibilitate de 100% - de-a lungul anilor vor acumula secunde, minute sau ore petrecute în timpul nefuncționării. Pentru multe sisteme, se ia în considerare disponibilitatea de patru nouă (99,99%, sau aproximativ 50 de minute de oprire pe an) Valabilitate ridicată. Pentru a ajunge la acest nivel, trebuie să muncești din greu.
Precizie: este acceptabilă pierderea sau inexactitatea datelor? Dacă da, ce procent este acceptabil? Pentru sistemul de plată la care lucram, această cifră trebuia să fie de 100%, deoarece nu exista nicio modalitate de a pierde date.
Debit/Putere (capacitate): Ce sarcină ar trebui să suporte sistemul? Această valoare este de obicei exprimată în solicitări pe secundă.
Latența: Cât timp ar trebui să răspundă sistemul? Cât timp ar trebui să dureze pentru a deservi 95% și 99% din solicitări? În astfel de sisteme, de obicei multe dintre solicitări sunt „zgomot”, astfel încât latențele p95 și p99 sunt considerate a fi mai lungi. uz practicîn lumea reală.

De ce sunt necesare SLA-uri la creare sistem mare plăți? Creăm un nou sistem care să îl înlocuiască pe cel existent. Pentru a ne asigura că facem totul corect și că noul nostru sistem va fi „mai bun” decât predecesorul său, am folosit un SLA pentru a ne defini așteptările pentru acesta. Accesibilitatea a fost una dintre cele mai importante cerințe. Odată ce am definit obiectivul, trebuia să înțelegem compromisurile din arhitectură pentru a atinge aceste obiective.

Scalare orizontală și verticală

Pe măsură ce afacerea care utilizează sistemul nostru nou creat crește, sarcina asupra acestuia va crește doar. La un moment dat, instalatia existenta nu va putea rezista la creșteri suplimentare ale sarcinii și va trebui să creștem capacitatea de încărcare. Două strategii comune de scalare sunt scalarea verticală sau orizontală.

Scalare orizontală constă în adăugare Mai mult mașini (sau unități) în sistem pentru a crește lățime de bandă (capacitate). Scalare orizontală este cea mai mare mod popular scalarea sistemelor distribuite.

Scalare verticală este în esență „cumpărați o mașină mai mare/mai puternică” - o mașină (virtuală) cu mai multe nuclee, mai bine putere de calculȘi mai multa memorie. În cazul sistemelor distribuite, scalare verticală de obicei, mai puțin popular, deoarece poate fi mai scump decât scalarea orizontală. Cu toate acestea, unele site-uri mari bine-cunoscute, cum ar fi Stack Overflow, s-au scalat cu succes pe verticală pentru a face față sarcinii.

De ce are sens o strategie de scalare atunci când construiți un sistem de plată mare? Suntem pe stadiu timpuriu am hotărât că vom construi un sistem care se va scala pe orizontală. Deși scalarea verticală este acceptabilă în unele cazuri, sistemul nostru de plăți și-a atins deja sarcina proiectată și am fost pesimiști în ceea ce privește ipoteza că un singur mainframe super costisitor ar putea face față acestei sarcini astăzi, cu atât mai puțin în viitor. În plus, au existat mai multe persoane în echipa noastră care au lucrat pentru furnizori mari de servicii de plată și au avut experiențe negative în încercarea de a se extinde pe verticală chiar și cel mult mașini puternice, care putea fi cumpărat cu bani în acei ani.

Consecvență

Disponibilitatea oricărui sistem este importantă. Sistemele distribuite sunt adesea construite din mașini a căror disponibilitate individuală este mai mică decât disponibilitatea întregului sistem. Scopul nostru să fie să construim un sistem cu o disponibilitate de 99,999% (timp de nefuncționare este de aproximativ 5 minute/an). Folosim mașini/noduri care au o disponibilitate medie de 99,9% (sunt timpi de nefuncționare de aproximativ 8 ore/an). Modul direct de a obține indicatorul de disponibilitate de care avem nevoie este să adăugați mai multe astfel de mașini/noduri la cluster. Chiar dacă unele dintre noduri sunt oprite, altele vor continua să fie operaționale, iar disponibilitatea generală a sistemului va fi mai mare decât disponibilitatea componentelor sale individuale.

Consecvența este problema cheieîn sisteme cu înaltă disponibilitate. Un sistem este consecvent dacă toate nodurile văd și returnează aceleași date în același timp. Spre deosebire de modelul nostru anterior, în care am adăugat mai multe noduri pentru a obține o disponibilitate mai mare, asigurarea faptului că sistemul rămâne consistent nu este la fel de banal. Pentru a se asigura că fiecare nod conține aceleași informații, trebuie să își trimită mesaje unul altuia pentru a rămâne sincronizat în orice moment. Cu toate acestea, mesajele trimise de ei unul altuia pot să nu fie livrate - se pot pierde și unele dintre noduri pot fi inaccesibile.

Consecvența este conceptul care mi-a luat cel mai mult timp să înțeleg și să apreciez. Există mai multe tipuri de consistență, cea mai utilizată în sistemele distribuite este consistența puternică ( consistenta puternica), consistență slabă ( consistență slabă) și eventual consistență ( eventuala consistenta). Puteți citi o analiză practică utilă a avantajelor și dezavantajelor fiecărui model în acest articol. De obicei, cu cât nivelul necesar de consistență este mai slab, cu atât sistemul poate rula mai repede - dar cu atât este mai probabil să nu returneze cel mai recent set de date.

De ce merită luată în considerare consistența atunci când creați un mare sistem de plata? Datele din sistem trebuie să fie consistente. Dar cât de consecvenți sunt? Pentru unele părți ale sistemului, numai datele foarte consistente vor fi potrivite. De exemplu, trebuie să stocăm într-o formă foarte consistentă informațiile că o plată a fost inițiată. Pentru alte părți ale sistemului care nu sunt la fel de critice, consecvența poate fi considerată în cele din urmă un compromis rezonabil.

Acest lucru este bine ilustrat prin enumerarea tranzacțiilor recente: acestea pot fi implementate folosind o eventuală consistență ( eventuala consistenta) - adică ultima tranzacție poate să nu apară în unele părți ale sistemului decât un timp mai târziu, dar din această cauză, interogarea listă va returna rezultatul cu mai puțină întârziere sau va necesita mai puține resurse pentru a fi executată.

Durabilitatea datelor

Durabilitatea înseamnă că, odată ce datele sunt adăugate cu succes în depozitul de date, acestea vor fi disponibile pentru noi în viitor. Acest lucru va fi adevărat chiar dacă nodurile sistemului sunt offline, eșuează sau datele nodului sunt deteriorate.

Diverse baze de date distribuite au diferite niveluri durabilitatea datelor. Unii dintre ei susțin durabilitatea datelor la nivel de mașină/nod, alții o fac la nivel de cluster, iar unii nu oferă deloc această funcționalitate. O anumită formă de replicare este de obicei folosită pentru a crește longevitatea - dacă datele sunt stocate pe mai multe noduri și unul dintre noduri se defectează, datele vor fi în continuare disponibile. , ceea ce explică de ce obținerea durabilității în sistemele distribuite poate fi o provocare majoră.

De ce contează durabilitatea datelor la construirea unui sistem de plată? Dacă datele sunt critice (de exemplu, plăți), atunci nu ne putem permite să le pierdem în multe părți ale sistemului nostru. Depozitele de date distribuite pe care le-am construit trebuiau să susțină durabilitatea datelor la nivel de cluster - astfel încât, chiar dacă instanțe au eșuat, tranzacțiile finalizate să fie păstrate. În zilele noastre, majoritatea serviciilor de stocare distribuite - cum ar fi Cassandra, MongoDB, HDFS sau Dynamodb - suportă durabilitate la diferite niveluri și toate pot fi configurate pentru a oferi durabilitate la nivel de cluster.

Persistența și durabilitatea mesajului

Nodurile din sistemele distribuite efectuează calcule, stochează date și își trimit mesaje unul altuia. O caracteristică cheie a trimiterii mesajelor este cât de fiabil vor ajunge mesajele. Pentru critice sisteme importante Există adesea o cerință ca niciun mesaj să nu fie pierdut.

În cazul sistemelor distribuite, mesageria ( mesagerie) se realizează de obicei folosind un serviciu de mesagerie distribuit - RabbitMQ, Kafka sau altele. Acești brokeri de mesaje pot suporta (sau sunt configurați să suporte) diferite niveluri de fiabilitate a livrării mesajelor.

Persistența mesajului înseamnă că atunci când nodul care procesează mesajul eșuează, mesajul va fi în continuare disponibil pentru procesare după rezolvarea problemei. Durabilitatea mesajelor este utilizată de obicei la nivelul cozii de mesaje. Cu o coadă de mesaje durabilă, dacă coada (sau nodul) este offline atunci când este trimis un mesaj, va primi în continuare mesajul când revine online. Bun articol detaliat despre această problemă disponibil la link.

De ce contează siguranța și durabilitatea mesajelor atunci când construiești sisteme mari de plată? Aveam mesaje pe care nu ne puteam permite să le pierdem - de exemplu, un mesaj că o persoană a inițiat o plată pentru o călătorie. Aceasta însemna că sistemul de mesagerie pe care îl folosim trebuie să fie fără pierderi: fiecare mesaj trebuia livrat o singură dată. Cu toate acestea, crearea unui sistem care să livreze fiecare mesaj neted o dată mai degrabă decât macar o dată - acestea sunt sarcini care variază semnificativ în dificultate. Am decis să implementăm un sistem de mesagerie care să livreze cel puțin o dată și am ales o magistrală de mesaje ( magistrala de mesagerie), deasupra căruia am decis să-l construim (am ales Kafka, creând un cluster fără pierderi, ceea ce era necesar în cazul nostru).

Idempotenta

În cazul sistemelor distribuite, orice poate merge prost - conexiunile pot cădea la mijloc sau solicitările pot expira. Clienții vor repeta aceste solicitări frecvent. Un sistem idempotent garantează că indiferent de ce se întâmplă, indiferent de câte ori cerere specifică indiferent cât de executată, executarea efectivă a acestei solicitări are loc o singură dată. Bun exemplu- aceasta este efectuarea unei plăți. Dacă un client creează o cerere de plată, cererea are succes, dar dacă clientul expiră, atunci clientul poate repeta aceeași cerere. În cazul unui sistem idempotent, persoana care efectuează plata nu va fi taxată de două ori; dar pentru un sistem non-idemponet acesta este un fenomen complet posibil.

Proiectarea sistemelor distribuite idempotente necesită un fel de strategie de blocare distribuită. Aici intră în joc conceptele pe care le-am discutat mai devreme. Să presupunem că intenționăm să implementăm idempotity folosind blocarea optimistă pentru a evita actualizările concurente. Pentru ca noi să folosim blocarea optimistă, sistemul trebuie să fie strict consecvent - astfel încât, în timp ce o operație rulează, să putem verifica dacă a început o altă operație, folosind o formă de versiuni.

Există multe modalități de a obține idempotenta și fiecare alegere specifică va depinde de constrângerile sistemului și de tipul de operație efectuată. Proiectarea abordărilor idempotente este o provocare demnă pentru un dezvoltator - doar uitați-vă la postările lui Ben Nadel în care vorbește despre diverse strategii pe care le-a folosit, care includ atât blocaje distribuite, cât și constrângeri ( constrângeri) Bază de date. Când proiectați un sistem distribuit, idempotenta poate fi cu ușurință una dintre părțile pe care le-ați trecut cu vederea. În practica noastră, am întâlnit cazuri în care echipa mea a fost arsă nesigurându-mă că idempotenta corectă era disponibilă pentru unele operațiuni cheie.

De ce contează idempotenta atunci când construiești un sistem de plată mare? Cel mai important lucru: pentru a evita debitările duble și rambursările duble. Având în vedere că sistemul nostru de mesagerie are cel puțin o dată, livrare fără pierderi, trebuie să presupunem că toate mesajele pot fi livrate de mai multe ori, iar sistemele trebuie să garanteze idempotenta. Am ales să gestionăm acest lucru utilizând versiunea și blocarea optimistă, în cazul în care sistemele noastre implementează un comportament idempotent folosind un magazin puternic consistent ca sursă de date.

Sharding și cvorum

Sistemele distribuite trebuie adesea să stocheze mult mai multe date decât poate gestiona un singur nod. Deci, cum stocăm setul de date pe numărul potrivit de mașini? Cea mai populară tehnică pentru aceasta este fragmentarea. Datele sunt partiționate orizontal folosind un hash atribuit partiției. În timp ce multe baze de date distribuite implementează astăzi sharding-ul sub capotă, este un subiect interesant care merită explorat în sine, în special reharding. Foursquare a suferit o perioadă de nefuncționare de 17 ore în 2010 din cauza unui caz marginal de sharding, după care compania a distribuit un raport care face lumină asupra rădăcinii problemei.

Multe sisteme distribuite au date sau calcule care sunt replicate pe mai multe noduri. Pentru a se asigura că operațiunile sunt efectuate în mod consecvent, se definește o abordare de vot, în care un anumit număr de noduri trebuie să aibă același rezultat pentru ca o operațiune să fie considerată reușită. Acest proces se numește cvorum.

De ce au sens cvorumul și shardingul atunci când se construiește un sistem de plată mare la Uber? Ambele concepte sunt simple și sunt folosite aproape peste tot. I-am întâlnit când am stabilit replicarea în Cassandra. Cassandra (și alte sisteme distribuite) utilizează cvorum și cvorum local ( cvorum local) pentru a asigura coerența între clustere.

Model de actor

Vocabularul obișnuit pe care îl folosim pentru a descrie practicile de programare - lucruri precum variabile, interfețe, apeluri de metode - presupune sisteme ale unei singure mașini. Când vorbim despre sisteme distribuite, trebuie să folosim abordări diferite. O modalitate obișnuită de a descrie astfel de sisteme este modelul actorului, în care vedem codul în termeni de comunicare. Acest model este popular deoarece coincide cu modelul mental al modului în care ne imaginăm, de exemplu, interacțiunea oamenilor într-o organizație. Un alt mod, nu mai puțin popular, de a descrie sistemele distribuite este CSP, procese secvențiale care interacționează.

Modelul de actor se bazează pe actori care își trimit mesaje unul altuia și reacţionează la ele. Fiecare actor poate face un set limitat de lucruri - să creeze alți actori, să trimită mesaje altora sau să decidă ce să facă cu următorul mesaj. Cu câteva reguli simple, putem descrie destul de bine sistemele complexe distribuite care se pot restaura după ce un actor eșuează. Dacă nu sunteți familiarizat cu această abordare, atunci vă recomand articolul