Sunteți pe pagina 1din 13

Referat Integrarea Sistemelor ERP

Migrare de la arhitectura monolit la arhitectura


bazata pe microservicii

Cuturela Sabina

Master IE anul II
Cuprins
Introducere..................................................................................................................................................3
Concepte teoretice......................................................................................................................................3
Arhitectura monolit.................................................................................................................................3
Avantaje...............................................................................................................................................3
Dezavantaje.........................................................................................................................................3
Arhitectura bazata pe microservicii.........................................................................................................4
Avantaje...............................................................................................................................................4
Dezavantaje.........................................................................................................................................4
Migrarea de la monolit la microservicii.......................................................................................................5
Exemplu...................................................................................................................................................5
Concluzie...................................................................................................................................................12
Bibliografie................................................................................................................................................13
Introducere
Cerintele utilizatorilor in continua crestere, obliga dezvolatatorii si furnizorii de aplicatii si servicii
software sa se adapteze rapid la nevoile clientilor. O piedica mare in dezvoltarea si implementarea
rapida o reprezinta arhitectura software(respective cea monolitica). Pentru a trece peste acest obstacol
se implementeaza stilul architectural tip microservicii.

Concepte teoretice
Pentru a intelege utilitatea migrarii de la arhitectura monolitica la cea bazata pe micro servicii trebuie
mai intai sa intelegem caracteristicile, avantajele si dezavantajele celor doua stiluri structurale.

Arhitectura monolit
Arhitectura monolit inseamna compus totul dintr-o singura bucata. Aplicatia Monolitica descrie o
aplicatie software cu un singur nivel in care diferite componente combinate intr-un singur program
formeaza o singura platforma.

Avantaje
Arhitectura monolitica reprezinta adesea punctul de plecare, fiind o solutie simpla si rapida.

- Usor de dezvoltat
- Usor de lansat, este necessary doar un fiser WAR
- Usor de scalat, scalarea fiind facuta prin rularea mai mulor copii ale aplicatie simultan
- Usor de testat, este necesara doar rularea aplicatiei intr-un context QC/QA si testarea
interfetei

Dezavantaje
Dar acest stil de arhitectura vine si cu dezavantaje ce devin mai evidente odata cu cresterea aplicatiei si
a complexitatii acesteia.

- aplicatia devine greu de inteles si modificat, in special pentru nou venitii in proiect.
-nu exista granite clare intre module, modularitatea se degradeaza in timp
-calitatea codului se degradeaza cu noi instante, fiind greu de inteles implementarea
initial/precedenta
-Supraincarcarea IDE-ului, marimea codului si viteaza IDE-ului fiind invers proprotionale duce la
scaderea productivitatii
-supraincarcarea volumelor, dimensiunea aplicatie este direct proprotionala cu timpul de
lansare ingreunand rularea
-actualizare dificila, pentru modificarea unei component este necesra relansarea intregii aplicatii
-relansarea poate cauza erori in componente fie ca au fost modificate sau nu
-scalarea pe un singur plan, desi este usor de scalat pentru volum de tranzactii, nu poate fii
scalat pentru volumul de date
-nu este modular, componente diferite ale aplicatiei necesita resurse diferite, pot solicita mai
mult memoria sau procesorul, iar scalarea nu poate fii facuta independent per component
-rigiditatea, este greu de migrat de la stack-ul tehnologic ales intial catre unul mai recent

Arhitectura bazata pe microservicii


Microserviciile reprezinta abordarea dezvoltarii unei aplicatii compusa dintr-o serie de servicii modulare
independente, fiecare avand un scop specific si o interfata de comunicare intermodulara bine definite.

Avantaje
Aceasta abordare vine cu mai multe avantaje.
-independenta modulelor, fiecare modul foloseste propria baza de date, de tipul cel mai potrivit
pentru functionalitatea sa fara a fii influentata de celelalte
-usor de actualizat, inclusiv aplicatiile complexe
-mai usor de testat, se testeaza doar un serviciu/modul nu intreaga aplicatie
-usor de lansat, serviciile pot fii lansate independent fara a afecta functionalitatea
-usor de organizat si distribuit sarcinile in cadrul echipelor de dezvolatare
-usor de inteles, inclusive pentru nou veniti
-rulare rapida, microserviciile fiind relativ mici nu incarca IDE-ul sau volumele
- problemele sunt usor de remediat prin izolarea microserviciului cu pricina, fara a afecta
aplicatia ca intreg
- nu este dependent de stack-ul tehnologic, putand fii actualizat oricand.

Dezavantaje
Aceasta abordare nu vine fara dezavantaje
-crearea unui sistem distribuit este complexa
-IDE-urile sunt concepute pentru arhitecturi monolitice si nu ofera suport pentru dezvoltarea
aplicatiilor distribuite
-testarea integrala este dificila, desi testarea modulara este facila
-necesita dezvoltarea protocoalelor de comunicare inter-service
-implementarea cazurilor de utilizare ce folosesc mai multe servicii simultan necesita
coordonare precisa intre echipele dezvoltatoare
-lansarea initiala este dificila datorita complexitatii sistemului compus din servicii diferite ca tip
si functionalitate
Migrarea de la monolit la microservicii
Pentru a face migrarea trebuie urmati urmatorii pasi:

1. Crearea de noi linii de livrare pentru a testa si lansa noile servicii


2. Crearea de servicii noi independente de monolit
3. Construirea infrastructurii noi, bazata pe primele doua puncte
4. Impartirea monolitului in servicii incepand cu cele simple, marginale, mergand spre cele
complexe din centrul monolitului, aceasta abordarea poate ajuta la consolidarea noii structuri
5. Limitarea dependentei serviciilor fata de monolit
6. Deconstructia capabilitatilor cu dependenta mare fata de monolit in concepte bine definite ale
domeniului
7. Concretizarea conceptelor de la pasul anterior in servicii spearate
8. Deculparea si fragmentarea datelor din data store pentru a realiza Decentralized Data
Management, data management descentralizat
9. Incorporarea unei strategi de migrare a datelor potrivita mediului
10. Izolarea elementelor susceptibile la modificari repetate

Exemplu
Migrarea de la monolit la microservicii se face prin extragerea modulelor, si transformarea lor in
microservicii. Pentru a exemplifica aceasta migrare vom folosi o aplicatie de livrare alimente, numita aici
FTGO.

Pentru a scoate delivery service din arhitectura monolit trebuie sa:

- impartim si sa transformam delivery service intr-un modul separat cu dependenta scazuta fata de
monolit.

- impartim baza de date si definim schema separata pentru delivery management.


-definim si folosim delivery service ca serviciu indepent

-eliminam functia delivery management acum nefolosita din monolit

Pornind de la structura logica

Putem observa ca order management si delivery management sunt strans legate.

Vom imparti codul, obtinand o structura de forma


Bazat pe urmatoare schema logica

In continuare vom imparti baza de date si vom defini o noua schema pentru modulul delivery service
Folosind structura

Vom defini delivery service independent


Modulele vor avea urmatoarea structura

Dupa ce am creat serviciul independent delivery service, il vom folosi astfel:


Structura revizuita este de forma

Ca ultim pas eliminam module invechite


Si vom obtine schema functionala
Concluzie
Migrarea unei arhitecturi monolitice existente la microservicii este o sarcina care necesita mult timp
pentru a fi executata, dar poate fi simplificata daca este facuta in mod sistematic. Aceasta arhitectura
are propriile sale beneficii asupra arhitecturii monolit, dar efectuarea tranzitiei de la monolit la
microservicii trebuie sa aiba anumite motive valide. Se recomanda intotdeauna refactorizarea in
microservicii daca sistemul a devenit prea complex pentru a opera si gestiona.

Avand in vedere ca ambele abordari vin cu avantajele și dezavantajele lor, in functie de scenariul și
cerintele produsului, nu exista o abordare unica. Totuși, se recomanda intai abordarea monolitica,
potrivindu-se mai bine pentru aplicații in stadiu incipient, si apoi trecerea la microservicii atunci cand
complexitatea aplicației creste. Abordarea arhitecturii bazate pe microservicii de la inceput desi vine cu
avantaje fata de structura clasica, poate incetini ritmul de dezvoltare, fiind o abordare complexa, nu se
pretează unei situații simple.
Bibliografie

https://microservices.io/patterns/monolithic.html
https://medium.com/koderlabs/introduction-to-monolithic-architecture-and-microservices-
architecture-b211a5955c63
https://microservices.io/patterns/microservices.html
https://martinfowler.com/articles/break-monolith-into-microservices.html
https://microservices.io/refactoring/

S-ar putea să vă placă și