PROGRAMUL DE STUDIU: MANAGEMENT ÎN TEHNOLOGIA [626573]

UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ Ș I TEHNOLOGIA
INFORMA Ț IEI
PROGRAMUL DE STUDIU: MANAGEMENT ÎN TEHNOLOGIA
INFORMA Ț IEI
FORMA DE ÎNVĂȚĂMÂNT ZI

Managementul proiectelor IT bazate
pe arhitecturi de tip micro-servicii

COORDONATOR ​ ​ Ș TIIN Ț IFIC
Profesor dr. ing. Cornelia GYŐRÖDI

ABSOLVENT: [anonimizat]-Radu MOLDOVAN-DU Ș E

ORADEA
2017

CUPRINS

CUPRINS 1
PREFA Ț A 2
Scopul lucrării 2
Con ț inutul lucrării 2
INTRODUCERE 3
Microservicii 3
Arhitectura bazată pe microservicii 3
I. Aspecte generale ale arhitecturii bazate pe microservicii 4
I.1 Principiile arhitecturii bazate pe microservicii 4
I.2 Comunicarea între servicii 8
I.3 Gazduirea microserviciilor 11
I.4 Monitorizarea ș i logarea erorilor 13
I.5 Procese de automatizare 14
II. Managementul proiectelor IT bazate pe arhitecturi de tip micro-servicii 15
II.1 Avantajele ș i dezavantajele implementării unei arhitecturi bazata pe microservicii 16
II.2 Cerin ț ele pentru implementarea unei arhitecturi bazată pe microservicii 18
II.3 Migrarea de la o arhitectura monolitică la o arhitectura bazata pe microservicii 23
III. De la monolit la microservicii – exemplu practic 26
III.1 Detaliile proiectului 26
III.2 Identificarea problemelor ș i a contextelor 28
III.3 Decuplarea contextelor 30
III.4 Implementarea microserviciilor 32
CONCLUZII 34
BIBLIOGRAFIE 35
Anexa 36

1

PREFA Ț A

Scopul lucrării

Pe măsură ce cloud computing-ul se dezvoltă ș i tot mai multe solu ț ii IT migrează spre
cloud, atât complexitatea proiectelor cât ș i varietatea tehnologiilor folosite în aceste solu ț ii
necesită o mai bună organizare ș i coordonare. Echipele care dezvoltă astfel de solu ț ii pot fi
împăr ț ite în mai multe zone geografice ceea ce aduce de asemenea un plus de complexitate în
managementul proiectelor.
Arhitectura software a evoluat mult în ultimii ani, iar o abordare nouă bazată pe
microservicii vine cu un set de principii care să ajute arhitec ț ii ș i dezvoltatorii software să treacă
peste obstacolele care apar în dezvoltarea proiectelor tot mai complexe.
Scopul acestei lucrări este de a prezenta contextul în care se pretează o arhitectura bazata
pe microservicii, care sunt avantajele ș i dezavantajele unei astfel de arhitecturi precum ș i o
modalitate de migrare de la o arhitectura monolitică spre o arhitectură bazată pe microservicii.

Con ț inutul lucrării

Lucrarea de fa ț ă cuprinde trei capitole. În Capitolul I sunt prezentate aspecte de bază ale
arhitecturii bazate pe microservicii care ne ajută să în ț elegem mai bine modul de func ț ionare a
microserviciilor. Tot în primul capitol sunt descrise câteva practici ș i tehnici esen ț iale unei
arhitecturi bazate pe microservicii.
Capitolul II aduce în discu ț ie aspecte legate de managementul unor astfel de proiecte
bazate pe microservicii care ne ajuta sa luam deciziile cele mai bune atunci când dorim sa trecem
la o arhitectură bazată pe microservicii.
Pentru a concretiza aspectele teoretice ale acestei lucrări în Capitolul III vor fi
exemplificate aplicarea tehnicilor prezentate în Capitolul I ș i II printr-un proiect de migrare de la
o solu ț ie monolitică la o s olu ț ie bazată pe microservicii.

2

INTRODUCERE

Microservicii
De ș i nu exista o defini ț ie a microserviciilor ele pot fi considerate ca ni ș te servicii
autonome care rulează independent unele de altele dar care totu ș i lucrează împreună.
Wikipedia dă o defini ț ie mai abstractă ș i spune că, microserviciile sunt o variantă de
arhitectură orientată pe servicii (SOA) care structurează o aplica ț ie ca ș i o colec ț ie de servicii
slab cuplate[1].
Microserviciile se referă de fapt la o noua abordare în care o aplica ț ie mai complexă este
construită din mai multe păr ț i independente care au ca ș i avantaj dezvoltarea independentă,
testarea independentă, actualizarea independentă iar între ț inerea lor poate fi făcută de către
echipe independente. Totu ș i echipele trebuie să discute între ele pentru a stabili modul în care
microserviciile comunică între ele, iar comunicarea între microservicii trebuie să fie făcută prin
mecanisme simple.
Pe scurt microserviciile sunt:
● Servicii lansate independent
● Servicii care respectă principiul singularită ț ii
● Servicii care comunică prin intermediul API-urilor
● Servicii cu nivel de coeziune ridicat
Arhitectura bazată pe microservicii
Modelul arhitecturii microserviciilor câ ș tigă repede teren în industria IT ca ș i o
alternativă viabilă la arhitectura monolitică ș i arhitectura orientată pe servicii[7]. Pentru că acest
model arhitectural este încă în proces de evolu ț ie, nu există momentan un standard al acestei
arhitecturi ș i de aceea poa te crea confuzie printre dezvoltatori.
Indiferent de topologia sau stilul de implementare ales, sunt mai multe concepte de bază
comune care se aplică acestui stil arhitectural. Primul dintre aceste concepte este no ț iunea de
separately deployed units (lansare separata a unitătilor) ​ [7]. A ș a cum este ilustrat în figura 1,
fiecare componentă a arhitecturii bazate pe microservicii este implementată ca o unitate separată,

3

permi ț ând o lansare mai u ș oară printr-o livrare eficientă, scalabili tate sporită ș i un grad ridicat de
separare a componentelor în cadrul aplica ț iei[7].
Un alt concept de bază al acestei arhitecturi este ca arhitectura bazată pe microservicii
este o arhitectură distribuită, ceea ce înseamnă că toate componentele sunt decuplate între ele iar
comunicarea se face prin protocoale de acces remote cum ar fi AMQP, REST, SOAP, etc.

Fig. 1. Exemplul unui modelul de bază al arhitecturii bazate pe microservicii[8]
I. Aspecte generale ale arhitecturii bazate pe microservicii

Înainte să trecem la implementarea unei arhitecturi care are la bază microservicii trebuie
să cunoa ș tem câteva aspecte generale pentru a în ț elege mai bine modul lor de func ț ionare. De ș i
acest stil nou de arhitectură ne ajută în rezolvarea unor probleme complexe, dacă nu în ț elegem
toate aspectele care stau la baza func ț ionarii corecte a întregului sistem, putem u ș or să e ș uăm în
realizarea proiectului sau el sa nu mai fie sustenabil din punct de vedere opera ț ional sau
financiar.
I.1 Principiile arhitecturii bazate pe microservicii
Arhitectura domeniului unui microserviciu define ș te modul în care se implementează
acel microserviciu. Structura internă a fiecărui microserviciu trebuie să fie decisă independent.
Acest lucru face ca echipele implicate în dezvoltarea microserviciilor să ac ț ioneze în mare

4

masură în mod autonom. Este totu ș i important să se respecte normele stabilite pentru a men ț ine
microserviciile la un nivel u ș or de în ț eles, simplu de între ț inut ș i de asemenea cu posibilitate de
inlocuire.
I.1.1 Nivel de coeziune ridicat (Hight Cohesion)

Arhitectura globală a sistemului influen ț ează arhitectura individuală a microserviciului,
de aceea microserviciile trebuie să aibe doar o singură responsabilitate în ceea ce prive ș te
domeniul[9]. Despre definirea responsabilită ț ii vom vorbi în Capitoul II, sec ț iunea II.3. Dacă
miroserviciile au mai mult decât o responsabilitate acestea pot fi la randul lor împăr ț ite în mai
multe microservicii. Împăr ț irea asigură faptul că microserviciile rămân mici ș i astfel sunt mai
u ș or de în ț eles, de între ț inut ș i de înlocuit[9]. Men ț inerea unui nivel de coeziune ridicat în cadrul
microserviciilor poate fi realizat prin adoptarea altor principii de programare cum ar fi:
principiile SOLID, principiile OOP.

I.1.2 Cuplarea slaba a serviciilor (Autonomous)

Atunci când microserviciile sunt slab cuplate înseamnă ca fiecare serviciu ar trebui să
poată fi modificat independent fără a fi nevoie de schimbări asupra altor microservicii[8]. Cu alte
cuvinte o schimbare în interiorul unui microserviciu nu trebuie sa implice niciodată schimbări ale
păr ț ilor de cod care consu mă acel serviciu[8]. Cuplarea slabă a serviciilor poate fi asigurată prin
implementarea unor contracte ș i interfe ț e comune de comunica re, iar toate comunicările să se
facă strict prin aceste interfe ț e.

I.1.3 Contextele delimitate (Bounded contexts)

Cartea lui Eric Evans cu privire la business domain, Domain-Driven Design, se
concentrează asupra modului de a crea sisteme care modelează domenii din lumea reală. Cartea
este plină de idei minunate, dar introduce un concept foarte important ș i anume: conceptul de
context limitat[8]. Ideea este că orice domeniu dat constă din mai multe contexte delimitate ș i în
cadrul fiecărui context se găsesc sunt informa ț ii care nu trebuie să fie comunicate în afară,
precum ș i informa ț ii care sunt distribuite către alte contexte delim itate. Fiecare context delimitat
are o interfa ț ă explicită, unde se decide ce modele să împărtă ș ească cu alte contexte[8]. Acelea ș i

5

principii se aplică ș i în cazul microserviciilor, fiecare dintre microservicii având un context
delimitat ș i o interfa ț ă prin care expune doar datele care sunt necesare la procesarea de către
consumatorii externi ai microserviciului. Fiecare microserviciu va reprezenta o func ț ie de
business asa cum se poate vedea în exemplificarea din figura 2.

Fig. I.1.3.1. Exemplificarea domeniilor delimitate in cadrul microserviciilor [3]

Conceptul microserviciilor derivă din modelul contextelor delimitate din DDD unde
modelele mari se împart în mai multe contexte delimitate. Fiecare context delimitat are propriul
model ș i propria bază de d ate[5].

I.1.4 Scalabilitatea (Scalability)

Arhitectura bazată pe microservicii trebuie să ofere o viziune cat mai bună asupra
scalabilită ț ii care să fie ex primată prin trei dimensiuni de scalabilitate.
Prima dimensiune de scalabilitate se referă la clonarea aplica ț iilor ș i a datelor pe mai
multe servere, de regulă servere virtuale. Un punct comun de acces către aceste servere, numit
load balancer, va decide către care din servere să se facă cererea datelor, iar apoi cererea va fi

6

direc ț ionată mai departe către acel server. Răspunsul către client va fi făcut tot prin punctul
comun de acces. Fiecare server trebuie să găzduiască aceea ș i versiune a microserviciilor ș i
trebuie să aibe acces la toate datele necesare. Acest tip de scalare se poate întâlni sub numele de
scalare pe orizontală.
A doua dimensiune de scalabilitate reprezintă împăr ț irea aplica ț iei pe oricare din criteriile
următoare: împăr ț irea pe date, împăr ț irea pe func ț ionalită ț i sau împăr ț irea pe date ș i
func ț ionalită ț i. Aceste separări pot fi numite ș i separări pe resurse ș i ele se fac în cadrul aceluia ș i
server. Acest tip de scalare se poate întâlni sub numele de scalare pe verticală.
A treia dimensiune de scalabilitate se referă la tipul cererii sau la informa ț iile despre
originea cererii ș i constă în redirec ț ionarea lor către servere dedic ate în func ț ie de criteriile alese.
De exemplu cererile pentru căutate de tip text vor fi redirec ț ionate tot timpul către un server care
găzduie ș te o solu ț ie de search engine.
În toate cele trei cazuri de scalabilitate dacă un server nu mai este disponibil sau resursele
nu sunt suficiente trebuie sa se asigure înlocuirea serverului sau suplimentarea resurselor în mod
automat.

Fig. I.1.4.1. Scalarea pe orizontală ș i verticală [9]

I.1.5 Logarea erorilor ș i monitorizarea (Observable)

La baza unei arhitecturi bazate pe microservicii trebuie să se implementeze un sistem
central de monitorizare a tuturor serviciilor precum ș i un sistem central de logare al erorilor.

7

Acest lucru asigură posibilitatea de a urmări dacă sistemul func ț ionează iar dacă apar erori să se
poată lua măsurile necesare pentru îndepărtarea lor.
Necesitatea logării erorilor ș i a monitorizării este data de folosirea tranzac ț iilor
distribuite, dorin ț a de rezolvare rapidă a erorilor, dorin ț a de a avea un feedback imediat în cazul
deploy-urilor, scalabilitatea automată, dorin ț a de a se ș ti care par ț i din sistem sunt mai folosite ș i
dorin ț a de monitorizare a datelor de business [2].

I.1.6 Automatizarea (Automation)

Automatizarea în cazul solu ț iilor bazate pe microservicii implică folosirea mai multor
tool-uri specifice:
● Continuous integration tools
○ Necesită folosirea unui sistem de control al codului sursă (source control)
○ Necesită folosirea unui tool de rulare automată a testelor după check-in
○ Se va asigura calitatea codului scris ș i a check-in-ului
○ Se va asigura rezolvarea urgentă a erorilor apărute
○ Solu ț ia va fi pregătită pentru echipa de testare ș i apoi pentru lansare în produc ț ie
● Continuous deployment tools
○ Setarea tool-ului de deploy automat se va face o singură dată
○ Avantajele fiind date de lansări în produc ț ie mai dese
I.2 Comunicarea între servicii

În 2002, Jeff Bezos a trimis un e-mail către Amazon spunând că "toate echipele î ș i vor
expune datele ș i func ț ionalitatea prin intermediul interfe ț elor" ș i "nu va permite nici o altă formă
de comunicare"[10].
Microserviciile trebuie să fie integrate ș i să comunice cu restul par ț ilor din aplica ț ie, iar
pentru aceasta sunt posibile diferite nivele de integrare, exemplificate ș i în figura I.2.1:
● Microserviciile con ț in o interfa ț ă grafică. Aceasta înseamnă că microserviciile pot fi
integrate la nivel de UI[9].
● Microserviciile pot fi integrate de asemenea la nivel logic. Ele pot folosi protocoale de
comunicare HTTP, AMPQ sau TCP[9].

8

● În final, integrarea poate fi făcută la nivel de baza de date prin folosirea datelor replicate
în bazele de date a microserviciilor[9].

Fig. I.2.1 Diferite nivele de integrare, sursa
http://meuslivros.github.io/microservices-flexible-software-architectures/images/00039.jpeg

Cele două protocoale utilizate în mod obi ș nuit la comunicare sunt HTTP request/response
ș i mesageria asincronă atu nci când se fac actualizări pe mai multe microservicii.
I.2.1 Tipurile de comunicare

Clientul ș i servici ile pot comunica prin mai multe tipuri diferite de comunicare, fiecare
vizând un alt scenariu ș i alte obiective. Ini ț ial, aceste tipuri de comunica ț ii pot fi clasificate pe
două axe[5].
Prima axă define ș te dacă protocolul este sincron sau asincron:
● Protocolul sincron. HTTP este un protocol sincron. Clientul trimite o cerere ș i a ș teaptă un
răspuns din partea serviciului. Aceasta este independentă de execu ț ia codului clientului
care ar putea fi sincronă (firul este blocat) sau asincron (firul nu este blocat ș i răspunsul
va ajunge în final la un apel în cele din urmă). Punctul important aici este că protocolul
(HTTP / HTTPS) este sincron ș i codul client poate continua sarcina numai atunci când
prime ș te răspunsu l serverului HTTP[5].
● Protocolul asincron. Alte protocoale precum AMQP (un protocol acceptat de mai multe
sisteme de operare ș i medii de tip cloud) utilizează mesaje asincrone. Codul clientului sau

9

expeditorul mesajului nu a ș teaptă, de obicei, un răspuns. Trimite doar mesajul ca atunci
când trimite un mesaj la o coadă RabbitMQ sau la orice alt broker de mesaje[5].
A doua axă define ș te dacă comunicarea are un singur receptor sau mai multe receptoare:
● Receptor unic. Fiecare cerere trebuie prelucrată de un singur receptor sau serviciu[5].
● Receptoare multiple. Fiecare cerere poate fi procesată de la unu la mai mul ț i receptori.
Acest tip de comunicare trebuie să fie asincronă. Un exemplu este mecanismul de
publicare / abonare utilizat în modele cum ar fi arhitectura bazată pe evenimente. Aceasta
se bazează pe o interfa ț ă event-bus sau un broker de mesaje atunci când se propagă
actualizările de date între mai multe microservicii prin evenimente[5].
I.2.2 Stilurile de comunicare

Există numeroase protocoale ș i alegeri care se pot utiliza pentru comunicare, în func ț ie de
tipul de comunicare utilizată. Dacă se utilizează un mecanism de comunica ț ii pe bază de
solicitare/răspuns sincron, protocoalele precum abordările HTTP ș i REST sunt cele mai
frecvente[5].
Dacă comunicarea este internă între servicii, de regulă se folosesc mecanisme de
comunicare în format binar utilizând TCP. Alternativ, se pot utiliza mecanisme de comunicare
asincrone, bazate pe mesaje, cum ar fi AMQP[5].
Există, de asemenea, mai multe formate de mesaje, cum ar fi JSON sau XML, sau chiar
formate binare, care pot fi mai eficiente în cazul comunicărilor interne[5].

Fig. I.2.2.1 Comunicare sincronă HTTP REST în format JSON/XML [5]

10

I.3 Gazduirea microserviciilor

Microserviciile pot fi găzduite pe diferite platforme ș i configura ț ii. Voi aborda însă trei
tipuri de găzduire care sunt cel mai des întâlmite în cazul microserviciilor.
I.3.1 Gazduirea în cloud pe ma ș ini virtuale
Acest tip de găzduire presupune configurarea de ma ș ini virtuale pe care vor rula
microserviciile. Problema la acest tip de găzduire este acela ca scalabilitatea automată este
posibilă doar pe orizontală. Acest lucru înseamnă ca dacă unul dintre microservicii va folosi mai
multe resurse va trebui să configurăm un nou VM care va fi o clona a primului VM. Avantajul
este acela că este o tehnologie standardizată ș i matură care stă la baza platformelor de cloud.

Fig. I.3.1.1 Microservicii găzduite pe ma ș ini virtuale[3]
I.3.2 Gazduirea în cloud folosind Docker

Docker ​ este un proiect open-source pentru automatizarea deploymentului aplica ț iilor ca
ș i containere portabile care pot rula în cloud sau on-premises[6]. Imaginile containerelor Docker
pot rula nativ pe Linux sau pe Windows, dar imaginile Windows pot rula numai pe gazde
Windows, iar imaginile Linux pot rula numai pe gazde Linux. Gazdele pot fi un server sau un
VM. O ​ imagine container ​ este un pachet executabil care con ț ine tot ce este necesar pentru a rula
un sistem de operare ș i ni ș te aplica ț ii[13]. Containerele rulează într-un engine dedicat ș i ele pot

11

rula pe orice ma ș ină virtu ală care rulează acest engine. Mai multe containere pot rula pe aceea ș i
ma ș ină virtuală, între ele neexistând conflicte. ​ Container ​ este o instan ț ă unei imagini container.

Fig. I.3.2.1 Comparare între VM ș i Docker[6]

Deci microserviciile vor fi găzduite fiecare într-un astfel de container. Folosind un cluster
ș i orchestrare putem rula oricâte instan ț e dorim de pe orice conta iner pe baza unor reguli foarte
simple pentru load-balancing. Deoarece folosim containere individuale pentru fiecare serviciu,
putem scala doar un punct de intrare special care se dovede ș te a fi puternic utilizat. Folosind
containere, toate mediile de la dezvoltare la produc ț ie sunt identice pentru aplica ț ie[13].

Fig. I.3.2.2 Microservicii găzduite în containere[3]

12

I.3.3. Gazduirea pe servere proprii

Găzduirea pe servere proprii presupune să ne configurăm noi toată infrastructura. Putem
să avem ma ș ini virtuale ș i containere dar va trebui să le facem noi ș i mentenan ț a. Scalarea în
acest caz va avea de suferit în sensul că nu va fi posibil să avem o scalare automatizată 100%.
Cel mai indicat este ca solu ț iile bazate pe microservicii să fie hostate în cloud.
I.4 Monitorizarea ș i logarea erorilor

Monitorizarea ș i logarea erorilor este poate unul dintre cele mai importante aspecte în
cazul arhitecturilor bazate pe microservicii. Acestea trebuie să fie sisteme centralizate care
colectează informa ț ii ș i mesaje de eroare de la toate microservicii le care fac parte din arhitectură.
Fără aceste sisteme de centralizare ar fi practic imposibil să urmărim func ț ionarea sistemului ș i
să luăm deciziile corecte la timp. Colectarea acestor date despre microservicii este una complexă
deoarece având un număr mare de containere care rulează, fiecare cu propriile lor fi ș iere de log,
volumul de date este mare, iar structura lor diferă de la caz la caz. Sistemul central va trebui să
poată să prelucreze toate aceste date, să le structureze ș i să le expună într-un mod cat mai u ș or de
urmărit.

Fig. I.4.1 Sistem cetral de monitorizare ș i logare a erorilor[3]

13

I.5 Procese de automatizare

Procesul de automatizare în cazul proiectelor bazate pe arhitecturi de tip microservcii
constă în adoptarea a două practici cunoscute de mai mult timp în development, primul având
legătură cu scriere codului sursă, iar cel de al doilea având legătură cu lansarea în produc ț ie a
modificărilor. Pentru ambele se folosesc un set specific de unelte pe care le voi exemplifica
sec ț iunile următoare.

I.5.1 Integrare continuă (CI – Continuous integration)

Continuous integration (CI) este practica din ingineria software de unificare a spa ț iilor
de lucru ale dezvoltatorilor într-un depozit comun de mai multe ori pe zi. ​ Scopul său principal este
cel de a evita problemele de integrare[11].
CI a fost creat la început cu inten ț ia de a fi utilizat în combina ț ie cu testele automate scrise prin
practicile de test-driven development, ceea ce a presupus rularea tuturor testelor unitare ș i verificarea că
acestea trec înainte de comiterea modificărilor în depozitul central. Alte elaborări ale conceptului au introdus ș i
servere de build, care rulează automat testele unitare periodic, sau chiar după fiecare commit, raportând
dezvoltatorului rezultatele[11].

I.5.2 ​ Livrarea continuă ​ (CD – Continuous delivery)

Livrarea continuă (CD) ​ este o abordare de inginerie software în care echipele produc
software în cicluri scurte, asigurându-se că software-ul poate fi eliberat în siguran ț ă în orice
moment. Acesta vizează construirea, testarea ș i lansarea de software mai rapid ș i mai frecvent.
Abordarea ajută la reducerea costurilor, a timpului ș i a riscului de a aduce modificări, permi ț ând
actualizări incrementale ale aplica ț iilor în produc ț ie. Un proces de desfă ș urare simplu ș i repetabil
este important pentru livrarea continuă ​ [12] ​ .

14

Fig. I.5.2.1. Diagrama procesului de livrare continuă
II. Managementul proiectelor IT bazate pe arhitecturi de tip
micro-servicii
De multe ori începerea unui proiect nou are sens sub formă de monolit, în mod deosebit
în proiecte lean în care cerin ț ele ș i produsul în sine nu sunt foarte bine închegate de la început. În
astfel de proiecte, modelele datelor domeniului aplica ț iei se transformă ș i se modifică mult, o
dată ce aplica ț ia pivotează iar cerin ț ele evoluează. Pe măsură ce p roiectul ș i produsul se
maturizează, modelul ș i domeniul datelor se sedimentează ș i devine din ce în ce mai stabil. Este
momentul în care unele domenii din aplica ț ie vor deveni mai active decât altele[5].

Fig. II.1. Evolu ț ia productivită ț ii ș i momentul trecerii la o arhitectură bazată pe microservicii în func ț ie de
complexitatea proiectului [4]

15

Complexitatea care ne determină să aduce o schimbare arhitecturii proiectului poate să se
datoreze mai multor cauze, cum ar fi, echipe de dezvoltare mari, func ț ionalită ț i care evoluează
mult, scalabilitate, etc. [4].
Înainte să facem trecerea de la o arhitectură monolitică la o arhitectură bazată pe
microservicii, probabil ne vom întreba dacă este o alegere bună. Raspunsul ar trebui să fie
”depinde”, după care are trebui să analizăm to ț i factorii de care depinde această alegere. În
subcapitolul următor voi enumera care sunt avantajele ș i care sunt dezavantajele implementările
unei arhitecturi bazate pe microservicii, pentru a ne da seama care ar putea fi factorii de care ar
depinde această alegere.
II.1 Avantajele ș i dezavantajele implementării unei arhitecturi bazata pe
microservicii

Sunt foarte multe materiale pe internet care prezintă avantajele ș i dezavantajele unei
arhitecturi bazate pe microservicii, dar cele mai multe fac referire cam la acelea ș i lucruri. Voi
incerca să extrag câteva dintre ele.
Cei de la Microsoft, în materialul ”NET Microservices Architecture for Containerized
NET Applications”, au enumerat următoarele beneficii[6]:
● Fiecare microserviciu este relativ mic, u ș or de între ț inut ș i de dezvoltat.
○ Este u ș or pentru un nou dezvoltator să il în ț eleagă ș i să se integreze în echipă
○ Îi fac pe dezvoltatori să fie mai productivi
○ Fiecare microserviciu poate să fie proiectat, dezvoltat ș i lansat individual
● Este posibilă scalarea individuală a fiecărei instan ț e de microservicii
● Se poate împăr ț i lucrul pe proiect la mai multe echipe
● Erorile care pot să apară sunt mai izolate ș i nu afectează toată solu ț ia
● Se pot folosi cele mai noi tehnologii pentru a dezvolta microservicii
Tot cei de la Microsoft au enumerat ș i câteva dezavantaje:
● Aplica ț iile distribu ite cum sunt cele bazate microservicii adaugă un grad de complexitate
pentru dezvoltatori, de exemplu prin faptul că trebuie implementată o comunicare între
servicii folosind protocolul HTTP sau AMPQ.
● Lansarea în produc ț ie poate să fie uneori mai complexă deoarece este nevoie de o
infrastructură orientată pe microservicii cum ar fi un orchestrator pentru administrarea
resurselor.

16

● Tranzac ț iile atom ice nu sunt posibile între mai multe microservicii lucru care poate să
afecteze consisten ț a datelor.
● Va fi nevoie de resurse mai multe pentru a rula un astfel de sistem, asta datorită
granularită ț ii mari ș i a faptului că microserviciile pot fi dis tribuite pe foarte mule servere.

Totu ș i pentru o m ai bună analiză propun următorul tabel:
Tabel II.1.1. Avantajele ș i dezavantajele unei arhitecturi bazată pe microservicii

Criteriu Tip Detalii
Lansare în
produc ț ie avantaj Lansări mai dese datorită ciclurilor de dezvoltare ș i testare
mai mici.
Lansări controlate prin sisteme de monitorizare.
Feedback imediat după lansare.
dezavantaj Lansarea manuală este aproape imposibilă dacă numărul de
microservicii este mare.
Procesul de lansarea automată este greu de configurat ș i
implică tool-uri pentru care este nevoie de o perioadă de
învă ț are ș i acomodare.
Disponibilitate avantaj După lansarea în produc ț ie noua versiune a
microserviciului este disponibilă imediat, în timp ce o nouă
versiune a unui monolit are nevoie de timp pentru
repornire.
dezavantaj Totu ș i perioada de indisponibilitate a unui microserviciu
poate să afecteze interac ț iunea dintre client ș i
microserviciu.
Management avantaj La dezvoltarea de microservicii poate să lucreze echipe
diferite în mod independent, astfel efortul este împăr ț it.
dezavantaj Implică o monitorizare mai atentă ș i un sistem de alertare
mai complex.
Deschidere la
schimbări
majore avantaj Microserviciile au o flexibilitate mult mai mare datorită
faptului că se pot folosii diferite tehnologii după caz, nu
este nevoie să se păstreze la toate aceea ș i tehnologie.
dezavantaj Dacă se schimbă interfa ț a prin care microserviciile î ș i
expun datele atunci posibil să apară probleme la
consumatorii care folosesc acele date.
Izolarea
erorilor avantaj Este destul de clar că erorile apărute la un microserviciu
afectează doar acel microserviciu ș i cel mult clien ț ii care

17

depind de el. În cazul unui monolit o erore poate să afecteze
tot sistemul.
dezavantaj Erorile apărute la microservicii sunt greu de depistat fără un
sistem central de monitorizare al erorilor.
Scalabilitatea avantaj Este unul dintre cele mai mari avantaje ale microserviciilor
ceea ce le face potrivite pentru găzduirea în cloud.
dezavantaj Nu există dezavantaje la scalabilitate.
Performan ț ă dezavantaj Datorită comunicării între microserviciilor prin protocolul
HTTP sau AMPQ, le face pe acestea să aibe o laten ț ă mai
mare decât comunicarea serviciilor dintr-un monolit.

Testare avantaj Testarea individuală a serviciilor
dezavantaj Testele de func ț ionalitate ș i de integritate sunt mai dificil de
implementat în cazul microserviciilor deoarece pot fi
implicate mai multe microservicii care rulează în medii
diferite..
Consumul de
resurse dezavantaj Consumul de memorie RAM poate sa fie mai mare pentru
că microservicii diferite pot să încarce separat librarii
comune. Consumul de spa ț iu de stocare poate ș i el să
crească în cazul replicării datelor în diferite baze de date
folosite de microservicii.

După cum am văzut modelul arhitecturii microserviciilor rezolvă multe din problemele
comune găsite în arhitecturii monolitice sau al arhitecturii orientate pe servicii[8]. Totu ș i implică
o mai bună cunoa ș tere a t ehnologiilor nou apărute ș i o agilitate mai mare în ceea ce înseamnă
adaptarea la schimbări. În subcapitolul următor voi vorbi despre lucrurile care trebuiesc pregătite
înainte să se implementeze o arhitectură bazată pe microservicii.
II.2 Cerin ț ele pentru implementarea unei arhitecturi bazată pe microservicii

Atunci când ne vom decide că trecerea la o arhitectură bazată pe microservicii este utilă
pentru proiectul pe care îl dezvoltăm, trebuie să luăm în calcul în prealabil stabilirea unor
proceduri noi de lucru atât pentru echipa de management cât ș i pentru echipa de dezvoltare.
Cerin ț ele noi pentru echipele de management ș i dezvoltare vor acoperi următoarele
aspecte:

18

● Procesele de testare a solu ț iei
● Procesele de automatizare
● Modul de lansare a implementarilor noi
● Modificarea organiza ț iei

II.2.1. Testarea

În figura II.2.1.1. se poate vedea cum arată o piramidă tipică a testelor, în func ț ie de
costul de implementare respectiv timpul de implementare. În partea de jos a piramidei se găsesc
unit testele, cele care testează o func ț ie din program. Apoi urmează testele de integrare în
aplica ț ie ș i în sistem. Pe ultimul nivel se găsesc testele func ț ionale. Costurile de creare ș i de
men ț inere a testelor este mai mare pentru cele din vârful piramidei, iar viteza de implementare
este mai mare pentru testele de la baza piramidei. Testele func ț ionale sunt cele mai greu de
implementat/între ț inut ș i cu costuri mari.

Fig. II.2.1.1. Piramida testelor în func ț ie de costul ș i timpul de implementare[7]

Între ț inerea testel or constă în actualizarea lor la modificările care urmează să fie
implementate în proiect, astfel încât la rularea lor în procesul automatizat de testare să ne
asigurăm că nu introducem erori odată cu lansarea noilor versiuni ale microserviciilor.

19

Din acest motiv testele sunt foarte importante chiar dacă costurile lor nu sunt de neglijat
ne pot salva de la pierderi ș i mai mari dacă solu ț ia nu este protejată la introducerea erorilor de
programare.
Este important de men ț ionat un tip de teste în cazul microserviciilor, situate undeva între
unit teste ș i testele de integrare în aplica ț ie. Acestea se numesc teste de contract (contract tests).
Ele sunt foarte foarte importante în cazul microserviciilor, iar ele sunt necesare pentru testarea
comunicării dintre microservicii[7].

II.2.2. Automatizarea ș i livrarea continua (CD)

CD în general ș i automatizarea în particular sunt aspecte cheie pentru arhitectura bazată
pe microservicii. În diferite căr ț i de specialitate, CD este definită ca ș i abilitatea de a crea
modificări de toate tipurile, care pot să includă func ț ionalită ț i noi, modificări ale setărilor, sau
rezolvări ale erorilor, care apoi să fie introduse în produc ț ie într-un mod sustenabil sigur ș i rapid.
Scopul este ca procedura de livrare, numită în cazul nostru deploy, să fie un proces
predictibil care poate fi executat la cerere.
De regula acest deploy trebuie sa se facă în mod automat de fiecare dată când se aplică
modificările pe codul sursă aflat în depozitarul corespunzător mediului de produc ț ie. Pentru
aceasta sunt câteva tool-uri cum ar fi Go CD sau Jenkins care oferă o interfa ț ă grafică de
vizualizare a căilor prin care codul modificat de către dezvoltatori ajunge în produc ț ie.

Fig. II.2.2.1. Interfata de la Jetkins pentru vizulaizarea schemei de deploy. sursa:
https://jenkins.io/doc/book/resources/pipeline/realworld-pipeline-flow.png

20

Automatizarea este de asemenea importantă pentru a crea cu succes o arhitectură
distribuită. Va fi nevoie să se automatizeze cat mai multe din procese, nu doar pornirea
microserviciilor, testarea lor sau migrarea datelor, dar ș i automatizarea infrastructurii ș i felul
cum ea este făcută disponibilă pentru rularea sistemului informatic. Scopul este de a evita să
avem infrastructuri nesigure sau care să răspundă greu la modificări, fiind necesară interven ț ia
manuală. Acest aspect poate fi unul critic în cazul în care intervine un număr mare de ma ș ini
virtuale ș i setări comple xe de drepturi de acces între containere chiar dacă ne aflăm pe o
platformă cloud unde de regulă chiar ș i setările manuale sunt mai u ș or de făcut. Pentru aceasta
există de asemenea tool-uri cum sunt orchestratoarele de containere care aplică conceptul de
infrastructură ca ș i cod (in frastructure as code).
Adaptarea la CD cât ș i la automatizarea tuturor proceselor precum sau automatizarea
infrastructurii necesită o perioadă mai lungă timp în care va trebui să dezvoltăm solu ț ia. Pentru a
putea face această adaptare posibilă există din fericire două modele de maturitate care ne ajută să
urmărim o anumită cale de punere în aplicare. Aceste două modele se numesc ​ CD MATURITY
MODEL ș i INFRASTR UCTURE AS CODE MATURITY MODEL ș i sunt prezentate în
figurile următoare.

Fig. II.2.2.2. Model de maturitate pentru CD, sursa:
https://www.devopsguys.com/2013/02/06/maturing-the-continuous-delivery-pipeline/

21

Fig. II.2.2.3. Model de maturitate pentru Infrastructure as service[7]

II.2.3. Modificarea organiza ț iei

Unul din beneficiile arhitecturii bazate pe microservicii este acela că permite
organiza ț iilor să aibe echipe mici ș i independente. Aceste echipe dezvoltă ș i între ț in serviciile ș i
aplica ț iile care combinate crează produsul ca un tot unitar.[7]
Într-o organiza ț ie care dezvoltă solu ț ii IT se pot găsii 3 gru pe de speciali ș ti:
1. Speciali ș ti pe part ea de prezentare (UI specialists)
2. Speciali ș ti pe part ea de logică (middleware specialists)
3. Speciali ș ti pe baza de date (DBAs)
Aceste echipe de obicei lucrează independent, uneori în birouri sau clădiri diferite ș i de
obicei au priorită ț i diferit e. Să ne imaginăm că apar cerin ț e noi care au implica ț ii la toate nivelele
de implementare. Va trebui să coordonam munca în trei sau mai multe echipe care necesită mult
efort ș i costuri mari. Echipele organizate în acest mod cu siguran ț ă vor avea perioade destul de
diferite de livrare, ceea ce va face ca cerin ț ele să fie implementate cu întârzieri destul de mari. Iar
acest lucru nu se întâmplă pentru că echipele nu sunt destul de pregătite tehnic, ci pentru că
echipele ș i proiectul nu su nt aliniate.

22

Ca să putem îmbunătă ț i acest aspect va trebui să reorganizăm echipele pentru a avea
echipe mai mici independente, care să fie construite în jurul produsului ș i nu în func ț ie de roluri.
Echipele trebuie să lucreze pe produse ș i nu pe proiect.
Fiecare nouă echipă va trebui să aibe în componen ț ă membri cu diferite roluri pentru a
acoperii nevoile de implementare a produsului/microserviciului respectiv.
Arhitec ț ii nu vor trebui să seteze recomandările ș i a ș teptările pentru dezvoltarea fiecărui
produs sau microserviciu înainte de începerea dezvoltării. În schimb rela ț ia dintre arhitect ș i
echipa de dezvoltare va trebui să fie una bazată pe conversa ț ie, unde deciziile sunt luate pe baza
experien ț ei echipei de dez voltare ș i a viziunii pe care o are arhitec tul asupra produsului.
În special la arhitecturile bazate pe microservicii, noii arhitec ț i vor seta limitele ș i
orientările legate de comunicarea între microservicii, dar nu vor seta tehnologiile care să fie
folosite la implementarea acestora. Va fi nevoie deci de o integrare ș i comunicare standard între
servicii, dar de o flexibilitate mare legată de ce se întâmplă în interiorul microserviciilor.
Pe scurt, un arhitect va seta recomadarile pentru ca echipele să lucreze eficient, în timp ce
dezvoltatorii va trebui să cunoască cele mai bune practici pentru a le pune în aplicare[7].
II.3 Migrarea de la o arhitectura monolitică la o arhitectura bazata pe microservicii

O aplica ț ie mono lit are deja modelele stabilite ș i implementate, iar microserviciile au
nevoie de un model curat fără dependin ț e de alte servicii. Problema apare atunci când în monolit
este modelată entitatea sub forma unui singur concept care este folosit în diferite contexte de
domeniu. De exemplu putem considera conceptul de produs, unde de multe ori este construit un
model care acoperă toate aspectele unui produs real: de la stoc, un concept ce apar ț ine de
gestiune, la pre ț care este parte din contextul de vânzări ș i până la ordine de achizi ț ii care ț in de
departamentul de achizi ț ii[5].
Rezultatul unui astfel de supermodel utilizat în contexte multiple este că oricare context
pe care dorim să-l transformăm (complet sau par ț ial) într-un microserviciu va fi constrâns de
restul de contexte care folosesc acela ș i model[5].

23

Fig. II.3.1. Modelul produs utilizat în contexte multiple[5]

O posibilitate de decuplare ar fi să încercăm implementarea a unui model pentru fiecare
context, iar noua reprezentare să satisfacă doar cerin ț ele necesare pentru acel context. Astfel
fiecare model din cadrul unui context ar avea proprietă ț i distincte de ș i toate apar ț in produsului în
realitate.

Fig. II.3.2. Modele specifice pentru fiecare produs[5]

24

Modelele astfel rezultate vor fi decuplate ș i mai u ș or de între ț inut.
Un alt exemplu ar fi acela în care modele identice au semnifica ț ie diferită în contexte
diferite, cum ar fi conceptul de pre ț care în contextul de vânzări are cu totul altă semnifica ț ie
decât în contextul de achizi ț ii[5].
Astfel fiecare context delimitat poate să devină la un moment dat un microserviciu.

Fig. II.3.3. Fiecare context delimitat devine un microserviciu[5]
Odată ce avem aceste contexte delimitate ne va fi mult mai u ș or să le extragem din
aplica ț ia monolitică ca apoi să implementăm microservicii cu aceea ș i func ț ionalitate. Nu trebuie
să pierdem din vedere implementarea testelor de integrare ș i a testelor de func ț ionalitate pentru
fiecare microserviciu nou creat. De asemenea trebuie să implementăm fluxul de date dinspre
microserviciu către sistemele centrale de monitorizare ș i logare a erorilor.
Uneori lucrurile pot fi foarte complicate ș i extragerea unui context delimitat dintr-o
aplica ț ie monolitică este o adevărată provocare ș i o opera ț ie cu riscuri mari. De aceea DDD nu
recomandă o rescriere totală a codului sursă ci una graduală în pa ș i mici. Pentru aceasta ne
putem folosi de contextele balon pe care le extindem treptat. Contextele balon spre deosebire de
contextele delimitate vor folosi baza de date din aplica ț ia monolit. Ultima fază din procesul de
migrare ar fi transformarea contextului balon într-un context delimitat independent cu propria
solu ț ie de stocare a datelo r.

25

III. De la monolit la microservicii – exemplu practic

Cele mai multe persoane din afara domeniului IT nu în ț eleg cat de dificil este să între ț ii ș i
să extinzi o aplica ț ie complexă bazata pe arhitectura monolitică. Dezvoltatorii sunt nevoi ț i să
petreacă câteva luni pentru a învă ț a codul sursă al aplica ț iei înainte de a lucra pe el. Când ceva
ajunge să meargă prost operatorii dau vina pe dezvoltatori, dezvoltatorii dau vina pe QA,
managerii de proiect dau vina pe buget ș i toată lumea devine frustrată. Toate acestea pot fi
rezolvate prin adoptarea unei arhitecturi bazate pe microservicii.
O abordare comună pentru echipele care adoptă microservicii este aceea de a identifica
func ț ionalitatea existentă în sistemul monolitic, care este mai pu ț in critică, cât ș i destul de pu ț in
cuplată cu restul aplica ț iei. Alternativ, echipele mai sofisticate pot pur ș i simplu mandata ca toate
noile func ț ionalită ț i să fie dezvoltate ca un microserviciu.
În fiecare dintre aceste scenarii, provocarea principală este de a proiecta ș i de a dezvolta
integrarea între sistemul existent ș i noile microservicii. Atunci când o parte a sistemului este
reproiectată cu ajutorul microserviciilor, o practică obi ș nuită este introducerea codului care ajută
la comunicarea cu noile microservicii.
În subcapitolele care urmează voi arata un exemplu practic de migrare a unor
func ț ionalită ț i dintr-o aplica ț ie monolitică spre microservicii proprii.

III.1 Detaliile proiectului

Proiectul este o aplica ț ie web publică, dedicată anun ț urilor de mică publicitate, în care se
regăsesc două grupe de utilizatori. Din prima grupă fac parte utilizatorii înregistra ț i care publică
anun ț urile de mica publi citate, iar din a doua grupă fac parte utilizatorii care ajung pe site în
urma căutărilor în motoarele de căutare (ex. Google) sau direct, pentru a vizualiza anun ț urile.
Aplica ț ia web este accesib ilă atât de pe desktop cât ș i de pe mobile.
Activită ț ile utiliza torilor pe site sunt împăr ț ite după cum urmează:
● Activită ț i ale utilizatorilor care publică anun ț uri
○ Posibilitatea de a adauga un anun ț
○ Posibilitatea de înregistrare ș i autentificare pe site
○ Posibilitatea de a administra anu ț urile proprii
ș Editare, inactivare, activare sau ș tergere
○ Posibilitatea de a vedea numărul de accesări ale unui anun ț

26

○ Posibilitatea de a citi mesaje primite de la posibili cumpărători relativ la
un anun ț activ
○ Posibilitatea de a raspunde la mesajele primite
○ Posibilitatea de a vedea ofertele de pre ț făcute de către posibili
cumpărători relativ la un anun ț
○ Posibilitatea de a face o contra ofertă
○ Posibilitatea de a accepta/refuza o ofertă
○ Posibilitatea de a livra bunul vândut printr-un serviciu de curierat direct de
pe site
● Activită ț i ale utilizatorilor care caută anun ț uri
○ Posibilitatea de filtrare a anun ț urilor pe site
○ Posibilitatea de a vizualiza un anunt
○ Posibilitatea de înregistrare ș i autentificare pe site
○ Posibilitatea de a salva filtrele utilizate la căutări pe site în vederea
reutilizării ulterioare sau a primirii pe email a alertelor cu anun ț uri noi
○ Posibilitatea de a contacta vănzătorul direct din pagina anun ț ului
ș Prin afi ș area numărului de telefon al vânzătorului
ș Prin scrierea unui mesaj direct de pe site
○ Posibilitatea de a oferta vanătorul direct din pagina anun ț ului
○ Posibilitatea de a accepta/refuza o contra oferta

Fig. III.1.1 Reprezentarea grafică a aplica ț iei monolit

27

Toate func ț ionalit ă ț ile enumerate mai sus sunt dezvolta te în aplica ț ia monolit. Pentru
implementarea interfe ț ei utilizator ș i a business logic-ului aplica ț iei s-a folosit framework-ul
ASP.Net MVC de la Microsoft împreună cu limbajul pe parte de server C#, iar pe parte de client
s-au folosit limbajele HTML, CSS ș i JavaScript. La stocarea ș i căutarea datelor s-a folosit o bază
de date MS SQL.
Aplica ț ia este găzduită într-un data-center propriu. Din configura ț ia infrastructurii pe care
rulează aplica ț ia fac parte un server pentru baza de date pe care este instalat SQL Server 2008, un
cluster web cu trei instan ț e de ma ș ini virtuale pe care rulează IIS, un load balancer ș i un server
media pentru stocarea imaginilor de la anun ț uri.
III.2 Identificarea problemelor ș i a contextelor

Pentru început arhitectura de tip monolit ș i infrastructura pe care rulează aplica ț ia au fost
suficiente pentru a satisface nevoile de performan ț ă ș i dezvoltare a aplica ț iei. Odată cu cre ș terea
numărului de utilizatori pe site ș i cu nevoia de a ț ine pasul cu alte site-uri concurente prin
dezvoltarea de noi func ț ionalită ț i au apărut ș i primele obstacole în administrarea acestui proiect.
O primă problemă a fost legată de performan ț ă, aplica ț ia nemaiputând să facă fa ț ă
numărului mare de căutări ș i afi ș ări care se executau pe site. A doua problemă a fost legată de
dezvoltarea aplica ț iei deoarece noile func ț ionalită ț i se implementau cu întârzieri mari datorită
implica ț iilor pe care orice modificare o avea asupra proiectului.
Problema de performan ț ă se datora în primul rând folosirii unei singure baze de date
pentru toate func ț ionalită ț i-le din aplica ț ie, ceea ce făcea ca baza de date să răspundă foarte greu.
Problema de productivitate se datora arhitecturii de tip monolit ș i a contextelor
nedecuplate, care limita dezvoltarea aplica ț iei.
Un prin pas care se impunea a fost să identificăm func ț ionalită ț i-le aplica ț iei care puteau
fi izolate, cu alte cuvinte identificarea contextelor din aplica ț ie. O modalitate de a realiza acesta
este folosirea ​ event storming ​ . ​ Event storming ​ -ul este un exerci ț iu din ​ domain modeling făcut
cu scopul de a realiza o în ț elegere comună a domeniului în care aplica ț ia trebuie să opereze. La
această activitate trebuie să participe atât managerul de proiect cât ș i dezvoltatorii proiectului.
Rezultatul acestei activită ț i va fi o hartă a contextelor din aplica ț ie.
Func ț ionalită ț i-le pe care le-am izolat au fost următoarele:
● Căutarea de anun ț uri ș i afi ș area lor pe site

28

● Stocarea numărului de vizualizari a anun ț urilor pe site
● Trimiterea ș i citirea mesajelor între vânzători ș i cumpărători
● Aplicarea ofertelor de pre ț pe anun ț uri

Fig. III.2.1 Separarea contextului de căutare de cel de mesagerie

Fig. III.2.2 Separarea contextului de căutare de cel de ofertare

29

Fig. III.2.1 Separarea contextului de căutare de cel de vizualizări

Pentru a reduce numărul de accesări la baza de date MS SQL s-au luat următoarele decizii:
● Modulul de căutare se va baza pe search engine-ul Solr
● Modulele de mesagerie ș i oferte de pre ț vor folosi o bază d e date No SQL
● Modulul de stocare a numărului de vizualizări pe anun ț uri va folosi o bază de date
proprie MS SQL
Pentru fiecare din module se va implementa un microserviciu separat.
III.3 Decuplarea contextelor

În solu ț ie exista un singur model pentru anun ț uri, iar acest super model era folosit în toate
contextele din aplica ț ie. Acest lucru făcea imposibilă implementarea de microservicii care să
deservească anumite func ț ionalită ț i din site.
Pentru început a fost nevoie de o refactorizare a modelului pentru anun ț uri a ș a cum se
poate vedea în figura III.3.1. Prin această refactorizare se dore ș te ca numărul de afi ș ări pentru un
anun ț (ViewHits), care este o proprietate a anun ț ului, să devină complet independent pentru ca
mai târziu să îl putem integra într-un microserviciu.

30

Fig. III.3.1 Refactorizarea modelului pentru anun ț uri
După refactorizarea modelului s-a trecut la separarea contextelor pentru a permite
salvarea datelor în baze de date diferite, după cum se vede în figura III.3.2.

Fig. III.3.2 Separarea contextelor

31

După separarea celor două contexte s-a implementat un serviciu intern care să preia
informa ț ia din baza de date separată pentru a o transmite mai departe la modelul folosit pentru
afi ș area datelor în pagina web.

Fig. III.3.3 Folosirea serviciului intern dedicat pentru citirea numărului de vizualizări ale anun ț ului
III.4 Implementarea microserviciilor

Odată ce contextele au fost separate se poate la transformarea serviciului intern într-un
microserviciu. Se porne ș te de la o aplica ț ie nouă pe baza unui template de web api din Visual
Studio. Se implementează contextul pe care l-am separat în aplica ț ia monolit. Se implementează
un REST api cu metodele de GET ș i POST pentru modelul AdView.

Fig. III.4.1 Implementarea microserviciului

32

După ce microserviciul a fost implementat se trece la înlocuirea în aplica ț ia monolit a
serviciului intern cu microserviciul nou creat. Se renun ț ă implementarea serviciului intern ș i se
ș terg toate referin ț ele la acel contextul vechi. În fi ș ierul web.config al aplica ț iei web se va
adăuga o cheie nouă unde se va stoca url-ul către microserviciu:
< ​ add ​ ​ key ​ =" ​ AdViewServiceUrl ​ " ​ value ​ =" ​ http://localhost:8090/ ​ " />
Se va seta o variabilă care va citi acea cheie în controller-ul aplica ț iei web:
private ​ ​ readonly ​ ​ string ​ _adViewServiceUrl ​ = ​ ​ ConfigurationManager ​ . ​ AppSettings[ ​ "AdViewServiceUrl" ​ ];
În figura III.4.2 se poate observa diferen ț a dintre implementarea pe bază de serviciu
intern ș i implementarea p e bază de microserviciu.
Fig. III.421 Implementarea pe bază de serviciu intern vs implementare pe bază de microserviciu

33

CONCLUZII

34

BIBLIOGRAFIE

[1] Wikipedia, Microservices, ​ https://en.wikipedia.org/wiki/Microservices ​ , Accesat 22.05.2017
[2] James Lewis, Martin Fowler, "Microservices – a definition of this new architectural term",
Martie 2014, ​ https://martinfowler.com/articles/microservices.html ​ , Accesat 22.05.2017
[3] Matthew Renze, “Clean Architecture: Patterns, Practices, and Principles”, Ianuarie 2017,
https://www.pluralsight.com/courses/clean-architecture-patterns-practices-principles ​ , Accesat
25.05.2017
[4] Martin Fowler, “Microservices”, Mai 2015,
https://martinfowler.com/bliki/MicroservicePremium.html ​ , Accesat 30.05.2017
[5] Remus Pereni, “De la monolit la microservicii folosind DDD ș i metoda Mikado”,
https://www.todaysoftmag.ro/article/2177/de-la-monolit-la-microservicii-folosind-ddd-si-metoda
-mikado ​ , Accesat 30.05.2017
[6] Bill Wagner, Mike Rousos, ".NET Microservices: Architecture for Containerized .Net
Applications", Microsoft Corporation, ​ ​ https://aka.ms/microservicesebook ​ , Accesat 30.05.2017
[7] Maria Gomez, “Moving to Microservices: Using Domain-Driven
https://aka.ms/microservicesebook ​ Design to Break Down the Monolith”, Mai 2017,
https://www.safaribooksonline.com/library/view/moving-to-microservices/9780134779270/ ​ ,
Accesat 10.06.2017
[8] Mark Richards, "Software Architecture Patterns", O’Reilly Media, Feb. 2015
[9] Irakli Nadareishvili, Ronnie Mitra, Matt McLarty, Mike Amundsen, "Microservice
Architecture", O'Reilly Media, Aug. 2016
[10] Eberhard Wolff, "Microservices: Flexible Software Architecture", Pearson Education, Oct.
2016
[11] Wikipedia, Continuous integration, ​ https://en.wikipedia.org/wiki/Continuous_integration ​ ,
Accesat 15.06.2017
[12] Wikipedia, Continuous delivery, ​ https://en.wikipedia.org/wiki/Continuous_delivery ​ ,
Accesat 15.06.2017
[13] Microservicii Cloud bazate pe containere,
https://www.todaysoftmag.ro/article/2335/microservicii-cloud-bazate-pe-containere ​ , Accesat
15.06.2017

35

Anexa

36