Migrare de la o arhitectură monolit la o arhitectură bazată pe 

microservicii 
 
Predescu Eduard-Florin 
Grupa 1101 
 

Introducere 
Nevoile utilizatorilor sunt într-o continuă creștere, iar furnizorii de servicii software și aplicații 
trebuie să se adapteze rapid la această creștere. Astfel se poate observa o adoptare masivă a 
conceptelor de livrare continuă (continuous delivery - CD) și DevOps, acestea urmărind 
dezvoltarea unui mediu în care software-ul să fie construit și livrat rapid. 
 
Conceptul de continuous delivery este o abordare în dezvoltarea software ce urmărește 
construirea și livrarea de aplicații în cicluri de dezvoltare scurte, iar DevOps reprezintă un set de 
practici ce urmăresc reducerea timpului efectiv între realizarea unei modificări în cadrul unui 
sistem și livrarea acesteia în producție, menținându-se un standard înalt de calitate. 
 

Concepte teoretice 
Înainte de a aborda subiectul migrării de la un monolit la microservicii vom defini, în continuare, 
cele două arhitecturi și caracteristicile acestora. 
 
O arhitectură monolitică reprezintă de multe ori un punct de plecare pentru multe afaceri și 
firme. O astfel de arhitectură urmărește înglobarea logicii necesare realizării proceselor de 
afaceri într-o singură aplicație. 
 
Această arhitectură prezintă o serie de avantaje cum ar fi:  
● Dezvoltarea unei aplicații de acest tip este facilă, tot codul aflându-se în același loc; 
● Lansarea aplicației se realizează ușor, totul fiind împachetat într-un singur loc (ex. în 
Java, aplicația este un singur WAR); 
 ● Scalarea aplicației se realizează prin lansarea mai multor copii ale acesteia în spatele unui 
load balancer pentru gestionarea unui volum crescut de tranzacții și cereri. 
 
Principalele dezavantaje ce însoțesc această arhitectură sunt: 
● Factorul de intimidare semnificativ ce apare la o aplicație complexă și de dimensiuni 
mari ce îngreunează procesul de dezvoltare; 
● Inexistența unor “granițe” între module, modularitatea componentelor aplicației scade cu 
timpul, declanșând o spirală negativă asupra calității codului; 
● Mediul de dezvoltare poate deveni supraîncărcat de dimensiunile mari ale aplicației, 
încetinind ciclul de dezvoltare; 
● Server-ul ce găzduiește aplicația poate fi supraîncărcat din cauza dimensiunii acesteia, 
fapt ce atrage o scădere a productivității și o creștere a timpului de lansare a unei noi 
instanțe a unei aplicații; 
● Faptul că această arhitectură permite scalarea într-o singură direcție, poate procesa un 
volum crescut de tranzacții prin rularea mai multor instanțe, dar aceasta arhitectură nu 
poate scala cu un volum crescut de date deoarece fiecare copie a aplicației va avea acces 
la toate datele ceea ce reduce eficiența caching-ului și crește consumul de memorie și a 
traficului I/O; 
● Este necesară folosirea adoptarea unei singure tehnologii alese la începutul dezvoltării și 
nu permite explorarea altor opțiuni din cauza posibilelor incompatibilități. 
 
 
O arhitectură bazată pe microservicii este o variantă a arhitecturii bazate pe servicii (SOA - 
service oriented architecture) prin care se structurează o aplicație sub forma unor servicii slab 
cuplate. Paralelizează ciclul de dezvoltare prin permiterea unor echipe mici și autonome de 
dezvoltatori să creeze, lanseze și scaleze serviciile acestora independent. 
 
Avantajele oferite de această arhitectură sunt: 
● Mentenabilitate crescută deoarece fiecare serviciu este de dimensiuni relativ reduse, 
astfel este ușor de înțeles și modificat; 
● Facilitate la testare deoarece serviciile sunt de dimensiuni mici; 
● Serviciile pot fi lansate independent; 
● Erorile pot fi izolate eficient la nivel de serviciu fără a influența buna funcționare a 
sistemului. 
 
 
Dezavantajele ce pot apărea prin adoptarea acestei arhitecturi sunt: 
● Complexitatea crescută ce apare la crearea unui sistem distribuit; 
 ● Necesitatea implementării unui sistem de comunicare între servicii și dezvoltarea unui 
mecanism de abordare a erorilor parțiale; 
● Testarea interacțiunilor între servicii este dificilă; 
● Dificultate crescută la asigurarea consistenței datelor; 
 

Migrarea de la un monolit la microservicii 

În continuare, va fi ilustrat procesul și pașii ce trebuiesc atinși pentru a migra o aplicație monolit 
la o aplicație bazată pe microservicii folosind ca exemplu o aplicație de ecommerce. 
 

 
Figura 1. Schema bazei de date a aplicației de ecommerce 
 
La nivelul datelor, putem observa faptul că aplicația va permite gestiunea mai multor roluri de 
utilizatori: clienți și administratori. Clienții dețin mai multe adrese ce pot fi folosite pentru 
livrarea și facturarea comenzilor, de asemenea ei pot lăsa recenzii produselor și de asemenea le 
pot comanda. Produsele aparțin mai multor categorii. 
 
  
Figura 2. Arhitectura monolit a aplicației de ecommerce 
 
După cum putem observa în figura 2, ambele interfețe comunică direct cu back end-ul, acesta din 
urmă realizând toate operațiile necesare pentru a întreprinde procesele de afaceri. În cazul în care 
apar erori la nivelul aplicației, tot sistemul este sistat, acest lucru diminuând satisfacția 
utilizatorilor, iar acest lucru se va reflecta în profitul firmei ce implementează aplicația. 
 
Pentru a realiza migrarea la microservicii vom respecta pașii următori: 
1. Întreruperea dezvoltării de noi funcționalități pe aplicație 
2. Identificarea contextelor în care monolitul poate fi “spart” 
3. Realizarea unui proces de DevOps pentru lansarea serviciilor 
4. Crearea unui nou repository pentru implementarea unui serviciu 
5. Copierea claselor și modelelor relevante pentru serviciu în noul repository 
6. Crearea unui API ce va permite interacțiunea cu alte servicii 
7. Testarea noului serviciu 
8. Migrarea datelor din monolit în noul serviciu 
9. Alterarea aplicației monolit pentru a folosi noul serviciu 
10. Asigurarea funcționării sistemului 
11. Ștergerea codului nefolosit din aplicația monolit 
12. Se repetă pașii 4-12 până la acoperirea tuturor contextelor din cadrul aplicației monolit 
 
Astfel, pentru aplicația exemplu de ecommerce vom presupune că am realizat deja pasul 1. 
Pentru pasul 2, identificăm următoarele contexte ce vor putea fi separate: 
 ● Utilizatori 
● Comenzi 
● Produse 
● Notificări 
 
În plus, vom introduce conceptul de API Gateway pentru interfețele aferente celor două roluri 
din cadrul aplicației. Un API Gateway reprezintă punctul de intrare pentru interfețele 
utilizatorilor și are rolul de a invoca multiplele servicii din sistem, de a agrega datele primite și 
de a le returna în interfață. Acesta trebuie actualizat atunci când se adaugă sau se șterge un 
microserviciu.  
 
Alte funcționalități ale unui API Gateway pot fi: autentificarea, impunerea politicilor de 
securitate în cadrul aplicației, load balancing, gestiunea cache-ului, gestiunea SLA (service level 
agreement). 
 
Contextele fiind stabilite, putem avansa la pasul 3 din migrare: procesul DevOps. Pe piață există 
o multitudine de unelte și produse ce facilitează procesul de DevOps cum ar fi: Gitlab CI, Travis 
CI pentru gestiunea lansării pe server-ul de producție, Docker pentru separarea serviciilor în 
containere și gestiunea dependințelor, Kubernetes sau Docker Swarm pentru orchestrarea 
serviciilor. 
 
Pașii 5-12 vor fi incluși în ciclul de dezvoltare a aplicației, datele fiind migrate în bazele de date 
specifice fiecărui serviciu în parte, la final rezultând arhitectura ilustrată în Figura 3. 

 
Figura 3. Arhitectura bazată pe microservicii a aplicației de ecommerce 
 

Concluzii 
Arhitectura bazată pe microservicii aduce o serie de avantaje față de arhitectura clasică 
monolitică, dar nu reprezintă o soluție pentru orice tip de sistem și orice echipă de dezvoltare. O 
aplicație simplă dezvoltată de la început cu microservicii ar putea încetini prea mult ciclul de 
dezvoltare. Astfel, se recomandă folosirea unei arhitecturi monolit pentru proiecte aflate la 
început, realizându-se migrarea atunci când complexitatea aplicației crește semnificativ. 
 
 
​Bibliografie 
https://martinfowler.com/articles/microservices.html 
https://www.martinfowler.com/articles/microservice-trade-offs.html#ops 
https://docs.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends 
https://www.researchgate.net/publication/323944215_Microservices_Architecting_for_Continuo
us_Delivery_and_DevOps 
https://medium.freecodecamp.org/monolith-vs-microservices-which-architecture-is-right-for-you
r-team-bb840319d531 
https://www.infoq.com/news/2014/08/failing-microservices 
https://microservices.io/