Suveranitatea datelor pe microserviciu

• 20.09.2018
• 4 minute de citit

• • n

  • m

  • j

  • m

In acest articol

O regula importanta pentru arhitectura microserviciilor este ca fiecare microserviciu trebuie sa detina datele si logica domeniului sau. Asa cum o aplicatie completa detine logica si datele sale, tot asa trebuie ca fiecare microserviciu sa detina logica si datele sale intr-un ciclu de viata autonom, cu implementare independenta pe microserviciu.

Aceasta inseamna ca modelul conceptual al domeniului va diferi intre subsisteme sau microservicii. Luati in considerare aplicatiile de intreprindere, unde aplicatiile de gestionare a relatiei cu clientii (CRM), subsistemele tranzactionale de cumparare si subsistemele de asistenta pentru clienti apeleaza la atribute si date unice ale entitatii clientilor si unde fiecare foloseste un context limitat (BC) diferit.

Acest principiu este similar in proiectarea bazata pe domeniu (DDD), unde fiecare context limitat sau subsistem sau serviciu autonom trebuie sa detina modelul sau de domeniu (date plus logica si comportament). Fiecare context DDD Bounded se coreleaza cu un microserviciu de afaceri (unul sau mai multe servicii). Acest punct despre modelul contextual delimitat este extins in sectiunea urmatoare.

Pe de alta parte, abordarea traditionala (date monolitice) folosita in multe aplicatii este aceea de a avea o singura baza de date centralizata sau doar cateva baze de date. Aceasta este adesea o baza de date SQL normalizata, utilizata pentru intreaga aplicatie si pentru toate subsistemele sale interne, asa cum se arata in Figura 4-7.

Figura 4-7 . Comparatia suveranitatii datelor: baza de date monolitica versus microservicii

In abordarea traditionala, exista o singura baza de date partajata intre toate serviciile, de obicei intr-o arhitectura cu niveluri. In abordarea microservicii, fiecare microserviciu detine modelul / datele sale. Abordarea bazei de date centralizate pare initial mai simpla si pare sa permita reutilizarea entitatilor din diferite subsisteme pentru a face totul coerent. Dar realitatea este ca ajungeti la tabele uriase care deservesc multe subsisteme diferite si care includ atribute si coloane care nu sunt necesare in majoritatea cazurilor. Este ca si cum ai incerca sa folosesti aceeasi harta fizica pentru a face drumetii pe un traseu scurt, a face o excursie cu o zi cu masina si a invata geografie.

O aplicatie monolitica cu o singura baza de date relationala are doua avantaje importante: tranzactiile ACID si limbajul SQL, ambele functionand in toate tabelele si datele legate de aplicatia dvs. Aceasta abordare ofera o modalitate de a scrie cu usurinta o interogare care combina date din mai multe tabele.

Cu toate acestea, accesul la date devine mult mai complicat atunci cand treceti la o arhitectura de microservicii. Chiar si atunci cand se utilizeaza tranzactii ACID intr-un microserviciu sau context limitat, este crucial sa se ia in considerare faptul ca datele detinute de fiecare microserviciu sunt private pentru microserviciul respectiv si ar trebui sa fie accesate fie sincron prin intermediul punctelor sale finale API (REST, gRPC, SOAP etc.) sau asincron prin mesagerie (AMQP sau similar).

Incapsularea datelor asigura ca microserviciile sunt cuplate slab si pot evolua independent unul de celalalt. Daca mai multe servicii acceseaza aceleasi date, actualizarile schemei ar necesita actualizari coordonate pentru toate serviciile. Acest lucru ar rupe autonomia ciclului de viata al microserviciului. Dar structurile de date distribuite inseamna ca nu puteti efectua o singura tranzactie ACID intre microservicii. La randul sau, acest lucru inseamna ca trebuie sa utilizati eventuala coerenta atunci cand un proces de afaceri acopera mai multe microservicii. Acest lucru este mult mai greu de implementat decat simplele imbinari SQL, deoarece nu puteti crea constrangeri de integritate si nu puteti utiliza tranzactii distribuite intre baze de date separate, asa cum vom explica mai tarziu. In mod similar, multe alte caracteristici ale bazei de date relationale nu sunt disponibile pentru mai multe microservicii.

Mergand si mai departe, diferitele microservicii utilizeaza adesea diferite tipuri de baze de date. Aplicatiile moderne stocheaza si proceseaza diverse tipuri de date, iar o baza de date relationala nu este intotdeauna cea mai buna alegere. Pentru unele cazuri de utilizare, o baza de date NoSQL precum Azure CosmosDB sau MongoDB ar putea avea un model de date mai convenabil si sa ofere performante si scalabilitate mai bune decat o baza de date SQL precum SQL Server sau Azure SQL Database. In alte cazuri, o baza de date relationala este in continuare cea mai buna abordare. Prin urmare, aplicatiile bazate pe microservicii folosesc adesea un amestec de baze de date SQL si NoSQL, care este uneori numita abordarea de persistenta poliglota.

O arhitectura partitionata, persistenta poliglota pentru stocarea datelor are multe avantaje. Acestea includ servicii cuplate slab si performante mai bune, scalabilitate, costuri si manevrabilitate. Cu toate acestea, poate introduce unele provocari de gestionare a datelor distribuite, asa cum este explicat in „Identificarea limitelor modelului de domeniu” mai tarziu in acest capitol.

Relatia dintre microservicii si modelul Bounded Context

Conceptul de microserviciu deriva din modelul Bounded Context (BC) in proiectarea bazata pe domenii (DDD). DDD se ocupa de modele mari, impartindu-le in mai multe BC si fiind explicite cu privire la limitele lor. Fiecare BC trebuie sa aiba propriul model si baza de date; in mod similar, fiecare microserviciu detine datele sale conexe. In plus, fiecare BC are de obicei propriul limbaj omniprezent pentru a ajuta comunicarea intre dezvoltatorii de software si expertii din domeniu.

Acei termeni (in principal entitati de domeniu) in limbajul omniprezent pot avea nume diferite in diferite contexte limitate, chiar si atunci cand entitati de domeniu diferite au aceeasi identitate (adica ID-ul unic utilizat pentru a citi entitatea din stocare). De exemplu, intr-un context de limitare a profilului de utilizator, entitatea din domeniul utilizatorului poate partaja identitatea cu entitatea din domeniul cumparatorului din contextul de limitare a comenzii.

Un microserviciu este, asadar, ca un context limitat, dar specifica, de asemenea, ca este un serviciu distribuit. Este construit ca un proces separat pentru fiecare context limitat si trebuie sa utilizeze protocoalele distribuite mentionate anterior, cum ar fi HTTP / HTTPS, WebSockets sau AMQP. Cu toate acestea, modelul Bounded Context nu specifica daca Bounded Context este un serviciu distribuit sau daca este pur si simplu o granita logica (cum ar fi un subsistem generic) intr-o aplicatie de implementare monolitica.

Este important sa subliniem ca definirea unui serviciu pentru fiecare context delimitat este un loc bun pentru a incepe. Dar nu trebuie sa va limitati designul. Uneori trebuie sa proiectati un context limitat sau un microserviciu de afaceri compus din mai multe servicii fizice. Dar, in cele din urma, ambele tipare – Context limitat si microserviciu – sunt strans legate.

DDD beneficiaza de microservicii obtinand limite reale sub forma de microservicii distribuite. Dar ideile cum ar fi sa nu impartasesti modelul intre microservicii sunt ceea ce iti doresti si intr-un context limitat.

Resurse aditionale

• Chris Richardson. Model: baza de date per serviciu

  https://microservices.io/patterns/data/database-per-service.html

• Martin Fowler. BoundedContext

  https://martinfowler.com/bliki/BoundedContext.html

• Martin Fowler. PolyglotPersistence

  https://martinfowler.com/bliki/PolyglotPersistence.html

• Alberto Brandolini. Proiectare strategica bazata pe domeniu cu mapare contextuala

  https://www.infoq.com/articles/ddd-contextmapping