UNIVERSITATEA BUCURE Ș TI FACULTATEA DE MATEMATICĂ Ș I INFORMATICĂ Specializarea Informatică LUCRARE DE LICEN Ț Ă [631586]

Licență

UNIVERSITATEA BUCURE Ș TI FACULTATEA DE MATEMATICĂ Ș I INFORMATICĂ Specializarea Informatică LUCRARE DE LICEN Ț Ă [631586]

Byadmin ianuarie 1, 2024

UNIVERSITATEA BUCURE
Ș
TI

FACULTATEA DE MATEMATICĂ
Ș
I INFORMATICĂ

Specializarea Informatică

LUCRARE DE LICEN
Ț
Ă

Coordonator
ș
tiin
ț
ific:

Lect. Dr. Dobrovă
ț
Anc a-Mădălina

Absolvent: [anonimizat]

2019

UNIVERSITATEA DIN BUCURE
Ș
TI

FACULTATEA DE MATEMATICĂ
Ș
I INFORMATICĂ

Specializarea Informatică

LUCRARE DE LICEN
Ț
Ă

Distributed Cloud Computing with applications on

Blockchain

Coordonator
ș
tiin
ț
ific:

Lect. Dr. Dobrovă
ț
Anc a-Mădălina

Absolvent: [anonimizat]

2019

Introducere

Tehnologia
ș
i
aplica
ț
iile
IT
încep
să
se
dezvolte
din
ce
în
ce
mai
mult,
prin
urmare

având
nevoie
constantă
de
un
mediu
prielnic,
u
ș
or
accesibil
ș
i
sigur
prin
care
să
î
ș
i
accelereze

cre
ș
terea.
Astfel,
din
nevoia
de
evolu
ț
ie
în
domeniul
puterii
de
calcul
ș
i
a
spa
ț
iului
de
stocare

a
apărut
no
ț
iunea
de
cloud
computing,
spre
care
se
îndreaptă
marile
companii
din
domeniu.

Cele
mai
mari
puteri
din
IT
deja
de
ț
in
un
cloud
propriu
ș
i
continuă
dezvoltarea
în
direc
ț
ia

aleasă, fiind o tehnologie sigură
ș
i de viitor.

Tema
aleasă
este
un
exemplu
potrivit
de
aplica
ț
ie
ce
demonstrează
avansul

tehnologiei
din
ultimii
ani,
observând
puterea
de
calcul
ș
i
rapiditatea
serviciilor.
Am
ales

această
temă
deoarece
mereu
am
fost
fascinat
de
ideea
unui
“calculator
portabil”,
ș
i
pentru
că

a
reprezentat
un
prilej
în
care
pot
înva
ț
a
tehnologii
ș
i
concepte
noi,
pe
care
sper
sa
le
folosesc

în viitor în cadrul dezvoltării aplica
ț
iilor.

Capitolele
înglobează
conceptele,
tehnologiile
ș
i
func
ț
ionalitatea
din
spatele
aplica
ț
iei.

În
prima
parte
am
descris
componentele
teoretice
din
spatele
aplica
ț
iei,
ș
i
anume
paradigma

publisher/subscriber,
ideologia
blockchain,
cozile
de
mesaje
ș
i
nu
în
ultimul
rând
conceptele

de
cloud
computing
ș
i
distributed
computing.
Mai
departe,
capitolul
doi
pune
în
lumină

tehnologiile
folosite
de
aplica
ț
ie,
tehnologii
ce
au
la
baza
conceptele
descrise
anterior:

RabbitMQ
pentru
paradigma
pub/sub
ș
i
coada
de
mesaje,
AWS
ș
i
Kubernetes
pentru
calculul

ș
i
distribuirea
calcululu i
în
cloud
ș
i
PM2
pentru
manageme ntul
proceselor
NodeJS,
în

vederea
prelucrării
unei
tranzac
ț
ii
de
pe
blockchain.
În
ultimul
capitol
am
pus
în
evidenta

utilitatea
aplica
ț
iei,
făcân d
un
tur
prin
întregul
proces
de
comunicare
din
cloud,
respectiv

managementul proceselor
ș
i a calculatoarelor din cloud.

CONCEPTE TEORETICE ALE APLICATIEI

Distributed cloud computing

Distribuirea
cloud
computerizată
permite
mutarea
execu
ț
iei
aplica
ț
iilor
distribuite

către
client.
Solu
ț
iile
actuale
de
gestionare
a
datelor
pentru
infrastructurile
cloud
replică

datele
prin
mai
multe
centre
de
date
distribuite
geografic,
dar
nu
au
suport
pentru
gestionarea

datelor
între
ț
inute
de
clien
ț
i.
Replicile
clientului
sunt
actualiza te
prin
notificări,
permi
ț
ând

clientului sa execute tranzac
ț
ii local pentru queries
ș
i actualizări.

Distributed
Cloud
este
aplica
ț
ia
tehnologiilor
de
Cloud
Computing
pentru
a

interconecta datele
ș
i apli ca
ț
iile difuzate din mai multe loca
ț
ii geografice.[1]

Distribuit,
într-un
context
al
tehnologiei
informa
ț
iei
(IT),
înseamnă
că
ceva
este
împăr
ț
it

între mai multe sisteme care pot fi, de asemenea, în loca
ț
ii diferite.

Furnizorii
de
cloud
folosesc
modelul
distribuit
pentru
a
permite
o
laten
ț
ă
mai
mică
ș
i

pentru
a
oferi
o
performan
ț
ă
mai
bună
pentru
serviciile
cloud.
Dincolo
de
contextul
furnizorului

de
cloud,
alte
două
exemple
de
cloud
distribuite
sunt
calculul
resurselor
publice
ș
i
cloud-ul

voluntarilor.

Resursele
computerizate
publice
reprezintă
o
cruce
între
cloud
computing
ș
i
computerele

distribuite,
care
implică
computere
în
loca
ț
ii
dispersate
geografic,
conectate
să
colaboreze
la

sarcini
intensive
ș
i
/
sau
computerizate.
Unele
exemple
sunt
Folding@home,
BOINC
ș
i

SETI@home.

Într-un
cloud
voluntar,
resursele
computerelor
membre
sunt
conectate
printr-un
singur

serviciu sau un hub pentru a construi
ș
i a configura în colaborare infrastructura cloud-ului.

Introducere în distributed computing
ș
i computing în cloud

Calculatoarele
ș
i
tehnologiile
re
ț
elelor
de
calculatoarele

au
înregistrat
îmbunătă
ț
iri

drastice
în
ultimele
decenii.
Odată
cu
apari
ț
ia
Internetului,
computerele
ș
i
re
ț
elele
s-au

dovedit
a
arăta
progrese
minunate,
la
fel
ca
subiectul
Distributed
Computing
ș
i
Cloud

Computing.
Expresiile
Distributed
Systems
ș
i
Cloud
Computing
Systems
se
referă
la
lucruri

u
ș
or
diferite,
dar
concep tul
care
stă
la
baza
lor
este
acela
ș
i.
Pentru
o
mai
bună
în
ț
elegere
a

conceptelor,
pentru
ambele
este
foarte
necesar
să
existe
cuno
ș
tin
ț
e
bune
despre
sistemele

distribuite
ș
i,
de
asemen ea,
cuno
ș
tin
ț
ele
despre
cum
diferă
acestea
de
sistemele
centralizate

de calcul.

Este
posibil
să
vede
ț
i
utilizarea
serviciului
Cloud
Computing
direct
sau
indirect
în

majoritatea
organiza
ț
iilor
de
astăzi.
De
exemplu,
atunci
când
folosim
oricare
dintre
serviciile

oferite
de
Google
sau
Amazon,
accesăm
direct
resursele
care
sunt
stocate
în
mediile
cloud
ale

Google
sau
Amazon.
Twitter
este
un
alt
exemplu,
în
care
tweeturile
noastre
sunt
stocate
pe
un

cloud
Twitter.
Procesarea
mai
rapidă
a
datelor
ș
i
re
ț
eaua
Calculatoarelor
poate
fi
în
ț
eleasă
ca

fiind necesitatea apari
ț
iei acestor noi tehnologii de calcul.[2]

Distributed Computing

Calculul
distribuit
este
un
domeniu
de
informatică
care
studiază
sistemele
distribuite.

Un
sistem
distribuit
este
un
sistem
ale
cărui
componente
sunt
amplasate
pe
computere

diferite,
care
comunică
ș
i
coordonează
ac
ț
iunile
prin
transmiterea
de
mesaje
unii
altora.

Componentele
interac
ț
ionează
una
cu
cealalta
pentru
a
atinge
un
obiectiv
comun.
Trei

caracteristici
semnificative
ale
sistemelor
distribuite
sunt:

concuren
ț
a
componentelor,
lipsa

unui
ceas
global
ș
i
e
ș
ecul
independent
al
componentelor.
Exemple
de
sisteme
distribuite

variază
de
la
sisteme
bazate
pe
SOA
(Service-Oriented
Architecture),
jocuri
online

multiplayer masive
ș
i la a plica
ț
ii peer-to-peer.

Un
program
care
rulează
într-un
sistem
distribuit
se
nume
ș
te
un
program
distribuit
(iar

programarea
distribuită
este
procesul
de
scriere
a
unor
astfel
de
programe).
Există
multe

tipuri
diferite
de
implementări
pentru
mecanismul
de
transmitere
a
mesajelor,
inclusiv
HTTP

pur, conectori RPC
ș
i
ș
iruri de mesaje.

Calculul
distribuit
se
referă
de
asemenea
la
utilizarea
sistemelor
distribuite
pentru
a

rezolva
problemele
de
calcul.
În
calculul
distribuit,
o
problemă
este
împăr
ț
ită
în
mai
multe

sarcini,
fiecare
dintre
acestea
fiind
rezolvată
de
unul
sau
mai
multe
computere,
care
comunică

între ele prin transmiterea mesajelor.[3]

Introducere

Cuvântul
distribuit
în
termeni
precum
"sistem
distribuit",
"programare
distribuită"
ș
i

"algoritm
distribuit"
se
referă
ini
ț
ial
la
re
ț
elele
de
calculatoare
în
care
computerele

individuale au fost distribuite fizic într-o anumită zonă geografică.

Termenii
sunt
utiliza
ț
i
în
prezent
într-un
sens
mult
mai
larg,
chiar
referindu-se
la

procese
autonome
care
rulează
pe
acela
ș
i
computer
fizic
ș
i
interac
ț
ionează
unul
cu
celălalt

prin transmiterea mesajului.

De
ș
i
nu
există
o
singură
defini
ț
ie
a
unui
sistem
distrib uit,
următoarele
proprietă
ț
i

definitorii sunt utilizate în mod obi
ș
nuit ca:

–
Există
mai
multe
entită
ț
i
computa
ț
ionale
autono me
(computere
sau
noduri),

fiecare având memoria locală proprie.

–
Entită
ț
ile comunică între ele prin transmiterea mesajelor.

Ce este Distributed Computing

Conform
căr
ț
ii
"Principii
ș
i
paradigme
a
calculului
distribuit",
expresia
Distributed

Computing
poate
fi
definită
ca
o
colec
ț
ie
de
computere
independente
care
apar
utilizatorilor

săi
ca
sistem
unic
coerent.
Ș
i
prin
această
defini
ț
ie,
Distributed
Computing
poate
fi
definită
ca

utilizarea
sistemelor
distribuite
pentru
a
rezolva
o
problemă
în
mai
multe
bucă
ț
i,
în
care

fiecare
bucată
dintr-o
sarcină
este
calculată
de
un
calculator
individual
al
unui
sistem

distribuit.

Un
sistem
de
calcul
distribuit
con
ț
ine
mai
mult
de
un
computer
care
comunică
cu

altele
printr-o
re
ț
ea
interconectată.
Toate
computerele
care
sunt
interconectate
prin
re
ț
ea,

lucrează
pentru
atingerea
scopului
comun
folosind
toate
resursele
proprii.
Sistemele

distribuite
abordează
rezolvarea
unei
probleme
prin
coordonarea
resurselor
partajate,
ajutând

la
comunicarea
cu
alte
noduri.
Prin
urmare,
sarcinile
individuale
ale
acestora
sunt
atinse
într-o

asemenea manieră.

În
cazul
defec
ț
iunilor
individuale
ale
computerului,
există
mecanisme
de
toleran
ț
ă

pentru
a
face
fa
ț
ă
acest or
scenarii.
Cu
toate
acestea,
cardinalitatea,
topologia
ș
i
structura

sistemului
sunt
factori
necunoscu
ț
i
în
prealabil,
deci
totul
tinde
să
devină
dinamic.

Următoarele
sunt
exemplele
cele
mai
cunoscute
ce
folosesc
această
tehnologie
(Distributed

Computing):

–
World Wide Web (WWW)

–
Social media gigantii cum ar fi Facebook

–
Sistemul distribuit de fi
ș
iere Hadoop (HDFS)

–
ATM-uri

–
Cloud
Network
Systems
(care
sunt
forma
specializată
a
sistemelor
de
calcul

distribuite)

–
Google Bots, Google Web Server, Google Indexing Server

Să
luăm
în
considerare
Serverul
Web
al
Google
ca
exemplu
în
în
ț
elegerea
sistemelor

distribuite,
atunci
când
un
utilizator
transmite
o
interogare
de
căutare
către
Google,
apoi

Google
Web
Server
ca
un
sistem
unic
se
ocupă
de
această
solicitare.
Ce
se
întâmplă
în
fundal

este
o
implementare
a
tehnologiei
Distributed
Computing
de
către
Google,
unde
mai
multe

servere
se
reunesc
pentru
a
răspunde
la
distribuirea
datelor
în
diferite
loca
ț
ii
geografice
pentru

a furniza rezultatele căutării în secunde secundare.

Alte proprietă
ț
i tipice ale sistemelor distribuite includ următoarele:

–
Sistemul trebuie să tolereze defec
ț
iuni în calculatoarele individuale.

–
Structura
sistemului
(topologia
re
ț
elei,
laten
ț
a
re
ț
elei,
numărul
de
computere)

nu
este
cunoscută
în
prealabil,
sistemul
poate
consta
în
diferite
tipuri
de

computere
ș
i
legături
de
re
ț
ea,
iar
sistemul
se
poate
modifica
în
timpul

executării unui program distribuit.

–
Fiecare
computer
are
doar
o
vedere
limitată,
incompletă
a
sistemului.
Fiecare

computer poate cunoa
ș
te doar o parte din intrare.[4]

Sisteme paralele vs sisteme distribuite

Sistemele
distribuite
sunt
grupuri
de
calculatoare
conectate
în
re
ț
ea,
care
au
acela
ș
i

scop
pentru
munca
lor.
Termenii
"calcul
computerizat",
"calcul
paralel"
ș
i
"computere

distribuite"
au
o
mul
ț
ime
de
suprapuneri
ș
i
nu
există
o
distinc
ț
ie
clară
între
ele.
Acela
ș
i
sistem

poate
fi
caracterizat
atât
ca
"paralel",
cât
ș
i
ca
"distribuit";
procesoarele
dintr-un
sistem
tipic

distribuit
rulează
simultan
în
paralel.
Calculul
paralel
poate
fi
văzut
ca
o
formă
particulară
de

cuplare
strânsă
a
computerelor
distribuite,
iar
calculul
distribuit
poate
fi
văzut
ca
o
formă

cuplată
în
mod
liber
de
calcul
paralel.
Cu
toate
acestea,
este
posibil
să
se
clasifice

aproximativ
sistemele
concurente
drept
"paralele"
sau
"distribuite"
utilizând
următoarele

criterii:

–
În
calculul
paralel,
to
ț
i
procesoarele
pot
avea
acces
la
o
memorie
partajată

pentru a face schimb de informa
ț
ii între procesoare.

–
În
calculul
distribuit,
fiecare
procesor
are
propria
sa
memorie
privată

(memorie
distribuită).
Informa
ț
iile
se
schimbă
prin
transmiterea
mesajelor

între procesoare.

Imaginea
ilustrează
diferen
ț
a
dintre
sistemele
distribuite
ș
i
cele
paralele.
Figura
(a)

este
o
vedere
schematică
a
unui
sistem
distribuit
tipic;
sistemul
este
reprezentat
ca
o
topologie

de
re
ț
ea
în
care
fiecare
nod
este
un
computer
ș
i
fiecare
linie
care
leagă
nodurile
este
o

legătură
de
comunicare.
Figura
(b)
prezintă
acela
ș
i
sistem
distribuit
în
detaliu:
fiecare

calculator
are
propria
memorie
locală,
iar
informa
ț
iile
pot
fi
schimbate
numai
prin
trecerea

mesajelor
de
la
un
nod
la
altul
prin
utilizarea
legăturilor
de
comunicare
disponibile.
Figura
(c)

prezintă un sistem paralel în care fiecare procesor are acces direct la o memorie partajată.

Situa
ț
ia
este
în
continuare
complicată
de
utilizările
tradi
ț
ionale
ale
termenilor
paralel

ș
i
algoritmul
distribuit
care
nu
se
potrivesc
exact
defini
ț
iilor
de
mai
sus
ale
sistemelor

paralele
ș
i
distribuite.
Cu
toate
acestea,
ca
regulă
generală,
calculul
paralel
de
înaltă

performan
ț
ă
într-un
multiprocesor
de
memorie
partajată
utilizează
algoritmi
paraleli,
în
timp

ce coordonarea unui sistem distribuit pe scară largă utilizează algoritmi distribui
ț
i.

Avantajele calculului distribuit

Există
multe
avantaje
ș
i
beneficii
ale
Distributed
Computing,
dar
vom
numi
pe
cele

mai importante aici:

–
Acestea
oferă
o
ra
ț
ie
de
performan
ț
ă
mai
bună
în
compara
ț
ie
cu
un
calculator

centralizat,
deoarece
adăugarea
unui
microprocesor
suplimentar
este
mult
mai

economică decât adăugarea de mainframe-uri suplimentare.

–
Ele
au
mai
multă
putere
computa
ț
ională
decât
un
sistem
centralizat.
Acestea

furnizează
o
cre
ș
tere
incrementală,
astfel
încât
organiza
ț
iile
puterea
de
calcul

să poată fi mărită atunci când afacerea are nevoie de cerere.

Cloud computing

Astăzi
este
vorba
despre
performan
ț
ă
ș
i,
dacă
nu
te
descurci
bine,
atunci
nu
mai
e
ș
ti
în

competi
ț
ie.
Aminti
ț
i-vă
de
zilele
în
care
Google
a
folosit
servici ile
sale
de
social
media
prin

numele
Orkut,
Facebook
a
preluat
acel
spa
ț
iu,
deoarece
Google
nu
a
reu
ș
it
să
se
extindă
în

competi
ț
ie
cu
Facebook.
Aplica
ț
iile
care
rulează
ar
trebui
să
aibă
un
timp
de
întrerupere

aproape
de
zero
ș
i
indife rent
de
loca
ț
iile
geografice
ale
utilizator ilor,
serviciul
ar
trebui
să
fie

disponibil
timp
de
24
de
ore
pe
zi,
365
de
zile
pe
an.
Mainframe-urile
situate
într-o
astfel
de

situa
ț
ie,
nu
pot
într-adevă r
să
scadă
la
atingerea
unei
limite.
Această
problemă
a
deschis
apoi

calea
pentru
apari
ț
ia
tehnologiei
cloud
computing,
care
permite
proceselor
să
efectueze

func
ț
ionalită
ț
i critice pe seturi de date relativ mai mari, cu u
ș
urin
ț
ă.[5][6]

Cloud-urile
pot
fi
limitate
la
o
singură
organiza
ț
ie
(cloud-uri
de
întreprindere),
poate

fi
disponibilă
pentru
multe
organiza
ț
ii
(cloud
public)
sau
pentru
o
combina
ț
ie
a
celor
două

(cloud hibrid).

Cloud
computing
se
bazează
pe
partajarea
resurselor
pentru
a
atinge
coeren
ț
a
ș
i

economiile de scară.

Adep
ț
ii
cloud-ur ilor
publice
ș
i
hibride
sus
ț
in
că
cloud
computing-ul
le
permite

companiilor
să
evite
sau
să
reducă
la
minimum
costurile
de
infrastructură
IT.
Sus
ț
inătorii

sus
ț
in,
de
asemenea,
că
tehnologia
cloud
permite
întreprinderilor
să
î
ș
i
dezvolte
aplica
ț
iile

mai
repede,
cu
o
mai
bună
administrare
ș
i
o
men
ț
inere
a
între
ț
inerii
ș
i
permite
echipelor
IT
să

ajusteze mai rapid resursele pentru a răspunde cererii fluctuante
ș
i imprevizibile.

Ce este cloud computing

Cloud
Computing
poate
fi
cel
mai
bine
în
ț
eles
ca
un
stil
de
calcul
în
care
capabilită
ț
ile

IT
scalabile
ș
i
flexibil e
pentru
servicii
sunt
furnizate
ș
i
livrate
utilizând
tehnologia

Internetului.
Serviciile
pe
care
le
discutăm
aici
pot
fi
oricare
dintre
următoarele:

infrastructură,
platformă,
aplica
ț
ii,
spa
ț
iu
de
stocare
etc.
Utilizato rii
vor
plăti
pentru
utilizarea

acestor
servicii
pe
baza
utilizării
efectuate,
ceea
ce
le
va
refuza
să-
ș
i
construiască
propria

infrastructură pentru oricare dintre serviciile pe care le solicită.

Cloud
Computing
permite
utilizatorilor
să
consume
serviciile
/
resursele
ca
utilitate

(la
fel
ca
ș
i
electricitatea ),
în
loc
să
construiască
ș
i
să
men
ț
ină
infrastructura
de
calcul
internă.

Se
referă
de
obicei
la
furnizarea
de
servicii
care
utilizează
Internetul
ca
mediu.
Serviciile
pot

varia
de
la
software-ul
de
afaceri
accesibil
prin
internet
sau
resurse
de
calcul.
Următoarele

sunt exemplele de Cloud computing pe care ne putem gândi:

–
YouTube, gazda a milioane de videoclipuri

–
Picasa sau Flickr, care găzduie
ș
te milioane
ș
i milioane de imagini

–
Google
Drive
sau
Dropbox
care
găzduiesc
milioane
de
documente,
foi
de

calcul
ș
i altele

Tipuri de modele cloud

Private Cloud

Cloudul
privat
este
o
infrastructură
cloud
care
func
ț
ionează
exclusiv
pentru
o
singură

organiza
ț
ie,
fie
administ rată
intern
sau
de
către
un
ter
ț
,
ș
i
găzduită
fie
intern,
fie
extern.

Efectuarea
unui
proiect
cloud
privat
necesită
un
angajament
semnificativ
de
a
virtualiza

mediul
de
afaceri
ș
i
cere
organiza
ț
iei
să
reevalueze
deciziile
cu
privire
la
resursele
existente.

Se
poate
îmbunătă
ț
i
afacerea,
dar
fiecare
pas
în
proiect
ridică
probleme
de
securitate
care

trebuie
abordate
pentru
a
preveni
vulnerabilită
ț
i
serioase.
Centrele
de
date
de
tip
self-run
sunt

în
general
mari.
Ele
au
o
amprentă
fizică
semnificativă,
care
necesită
alocări
de
spa
ț
iu,

hardware
ș
i
controale
de
mediu.
Aceste
active
trebuie
să
fie
actualizate
periodic,
ducând
la

cheltuieli
de
capital
suplimentare.
Acestea
au
atras
critici,
deoarece
utilizatorii
"trebuie
să
le

cumpere,
să
le
construiască
ș
i
să
le
gestioneze"
ș
i
astfel
nu
beneficiază
de
mai
pu
ț
ină

gestionare
directă,
în
esen
ț
ă
"[lipsită]
de
modelul
economic
care
face
conceptul
de
cloud

computing atât de interesant".

Public Cloud

Un
cloud
este
numit
"cloud
public"
atunci
când
serviciile
sunt
redate
printr-o
re
ț
ea

deschisă
pentru
uz
public.
Serviciile
de
cloud
publice
pot
fi
gratuite.
Din
punct
de
vedere

tehnic,
ar
putea
exista
o
diferen
ț
ă
mică
sau
chiar
infima
între
arhitectura
cloud-ului
public
ș
i

privat,
dar
totu
ș
i
consid era
ț
iile
privind
securitatea
pot
diferi
substan
ț
ial
pentru
serviciile

(aplica
ț
ii,
stocare
ș
i
alte
resurse)
care
sunt
puse
la
dispozi
ț
ie
de
un
furnizor
de
servicii
pentru

publicul larg
ș
i când com unicarea efectuată printr-o re
ț
ea neîncredin
ț
ată.

În
general,
furnizorii
de
servicii
publice
de
cloud,
cum
ar
fi
Amazon
Web
Services

(AWS),
Oracle,
Microsoft
ș
i
Google,
de
ț
in
ș
i
exploatează
infrastructura
la
centrul
de
date
ș
i

accesul
este,
în
general,
prin
Internet.
AWS,
Oracle,
Microsoft
ș
i
Google
oferă
de
asemenea

servicii
directe
de
conectare
numite
"AWS
Direct
Connect",
"Oracle
FastConnect",
"Azure

ExpressRoute"
ș
i
"Cloud
Interconnect"
respectiv,
astfel
de
conexiuni
solicită
clien
ț
ilor
să

achizi
ț
ioneze sau să închi rieze o conexiune privată peer point oferit de furnizorul de cloud.

Hybrid cloud

Cloud-ul
hibrid
este
o
compozi
ț
ie
a
două
sau
mai
multor
cloud-uri
(private,

comunitare
sau
publice)
care
rămân
entită
ț
i
distincte,
dar
sunt
legate
împreună,
oferind

avantajele
mai
multor
modele
de
implementare.
Cloud-ul
hibrid
poate
însemna
ș
i
abilitatea
de

a
conecta
serviciile
de
colocare,
gestionate
ș
i
/
sau
dedicate
cu
resursele
cloud.
Gartner

define
ș
te
un
serviciu
de
cloud
hibrid
ca
un
serviciu
de
cloud
computing
care
este
compus

dintr-o
combina
ț
ie
de
servicii
cloud
private,
publice
ș
i
comunitare,
de
la
diferi
ț
i
furnizori
de

servicii.
Un
serviciu
cloud
hibrid
traversează
limitele
de
izolare
ș
i
ale
furnizorului,
astfel
încât

acesta
să
nu
poată
fi
pur
ș
i
simplu
pus
într-o
singură
categorie
de
servicii
cloud
private,

publice
sau
comunitare.
Aceasta
permite
extinderea
capacită
ț
ii
sau
a
capacită
ț
ii
unui
serviciu

cloud, prin agregare, integrare sau personalizare cu un alt serviciu cloud.

Există
cazuri
variate
de
utilizare
pentru
compozi
ț
ia
norilor
hibride.
De
exemplu,
o

organiza
ț
ie
poate
stoca
date
despre
clien
ț
i
sensibili
în
casă
într-o
aplica
ț
ie
privată
cloud,
dar

interconectează
aplica
ț
ia
respectivă
cu
o
aplica
ț
ie
de
business
intelligence
furnizată
într-un

cloud
public
ca
serviciu
software.
Acest
exemplu
de
cloud
hibrid
extinde
capacită
ț
ile

întreprinderii
de
a
furniza
un
anumit
serviciu
de
afaceri
prin
adăugarea
de
servicii
public

cloud
disponibile
extern.
Adoptarea
norilor
hibrizi
depinde
de
o
serie
de
factori,
cum
ar
fi

cerin
ț
ele
de
securitate
a
datelor
ș
i
de
conformitate,
nivelul
de
control
necesar
asupra
datelor
ș
i

aplica
ț
iile pe care le utiliz ează o organiza
ț
ie.

Un
alt
exemplu
de
cloud
hibrid
este
unul
în
care
organiza
ț
iile
IT
folosesc
resurse

publice
de
cloud
computing
pentru
a
satisface
nevoile
temporare
de
capacitate
care
nu
pot
fi

îndeplinite
de
cloud-ul
privat.
Această
capacitate
permite
cloud-urilor
hibridei
să
utilizeze

spargerea
cloudului
pentru
scalarea
pe
alte
cloud-uri.
Cloud
bursting
este
un
model
de

implementare
a
aplica
ț
iilor
în
care
o
aplica
ț
ie
rulează
într-un
cloud
privat
sau
centru
de
date
ș
i

"explodează"
într-un
nor
public
atunci
când
cererea
de
capacitate
de
calcul
cre
ș
te.
Un
avantaj

principal
al
spargerii
cloud
ș
i
a
unui
model
de
cloud
hibrid
este
că
o
organiza
ț
ie
plăte
ș
te

pentru
resurse
suplimentare
de
calcul
numai
atunci
când
sunt
necesare.
Spargerea
cloud-ului

permite
centrelor
de
date
să
creeze
o
infrastructură
IT
internă
care
să
suporte
încărcările

medii
ș
i
să
utilizeze
resursele
de
cloud
de
la
cloud-uri
publice
sau
private,
în
timpul

cre
ș
terilor
în
cererile
de
procesare.
Modelul
specializat
de
cloud
hibrid,
care
este
construit
pe

un
hardware
heterogen,
se
nume
ș
te
"Cloud
Hybrid
Cross-platform".
Un
cloud
hibrid

cross-platform
este
de
obicei
alimentat
de
arhitecturi
diferite
ale
procesorului,
de
exemplu,

x86-64
ș
i
ARM,
dedesub t(underneath
processing).
Utilizatorii
pot
implementa
ș
i
scindează
în

mod transparent aplica
ț
ii fără cuno
ș
tin
ț
e despre diversitatea hardware a cloudului.

HPC Cloud

HPC
Cloud
se
referă
la
utilizarea
serviciilor
de
cloud
computing
ș
i
a
infrastructurii

pentru
a
executa
aplica
ț
ii
de
înaltă
performan
ț
ă
(HPC).
Aceste
aplica
ț
ii
consumă
o
cantitate

considerabilă
de
putere
ș
i
memorie
de
calcul
ș
i
sunt
executate
în
mod
tradi
ț
ional
pe
grupuri

de
computere.
În
2016,
o
mână
de
companii,
printre
care
R-HPC,
Amazon
Web
Services,

Univa,
Silicon
Graphics
International,
Sabalcore,
Gomput
ș
i
Penguin
Computing,
au
oferit
un

cloud computing performant.

Noul
Penguin
On
Demand
(POD)
a
fost
unul
dintre
primele
servicii
HPC
de
la
distan
ț
ă
care

nu
au
fost
virtualizate,
oferite
pe
bază
de
plată
în
avans.
Penguin
Computing
a
lansat
cloud-ul

HPC
în
2016
ca
alternativă
la
Cloud
Computing
E2
al
Amazon,
care
utilizează
noduri
de

calcul virtualizate.

Avantaje ale Cloud Computing

Există
numeroase
avantaje
ș
i
beneficii
ale
Cloud
Computing,
dar
le
vom
men
ț
iona
pe

cele mai importante aici:

–
Cloud
computingul
globalizează
for
ț
a
de
muncă
la
un
cost
care
este
economic

pentru
organiza
ț
ii,
făcând
conectivitatea
la
Internet
cea
mai
bună
resursă

pentru a se conecta prin ofertele Organiza
ț
iei Cloud

–
Organiza
ț
iile
î
ș
i
pot
valorifica
ofertele
Cloud
pentru
a
împărtă
ș
i
cuno
ș
tin
ț
ele

între
angaja
ț
i
în
loc
de
utilizarea
tradi
ț
ională
sau
ortodoxă
a
e-mailurilor
ș
i
a

partajării de fi
ș
iere[5]

Distributed
Cloud
Computing
a
devenit
expresia
cheie
în
IT
cu
vânzătorii
ș
i
anali
ș
tii

care
sunt
de
acord
cu
faptul
că
tehnologia
distribuită
de
cloud
câ
ș
tigă
trac
ț
iune
în
mintea

clien
ț
ilor
ș
i
furnizorilor
de
servicii.
Serviciile
distribuite
Cloud
Computing
sunt
pe
punctul
de

a
ajuta
companiile
să
reac
ț
ioneze
mai
bine
la
condi
ț
iile
pie
ț
ei,
restrângând
în
acela
ș
i
timp

costurile IT.[6]

Cozi de mesaje

În
IT,
cozile
de
mesaje
ș
i
cutiile
po
ș
tale
sunt
compo nente
de
inginerie
software

utilizate
pentru
comunicarea
inter-proces
(IPC)
sau
pentru
comunicarea
între
fire
în
cadrul

aceluia
ș
i
proces.
Ei
folosesc
o
coadă
pentru
mesagerie
–
trecerea
controlului
sau
a

con
ț
inutului. Grupurile de sisteme de comunica
ț
ii furnizează tipuri similare de func
ț
ionalitate.

Paradigma
coadă
de
mesaje
este
un
frate
al
modelului
editor
/
abonat
ș
i
este
de
obicei

o
parte
a
unui
sistem
middleware
orientat
spre
mesaj.
Cele
mai
multe
sisteme
de
mesagerie

suportă
atât
modelele
editor
/
abonat,
cât
ș
i
cele
de
coadă
de
mesaje
în
API-ul
lor,
de
ex.

Serviciul de mesaje Java (JMS).

Cozile
de
mesaje
furnizează
un
protocol
de
comunica
ț
ii
asincron,
ceea
ce
înseamnă
că

expeditorul
ș
i
receptorul
mesajului
nu
trebuie
să
interac
ț
ioneze
simultan
cu
coada
de
mesaje.

Mesajele
plasate
pe
coada
sunt
stocate
până
când
destinatarul
le
recuperează.
Cozile
de

mesaje
au
limite
implicite
sau
explicite
privind
dimensiunea
datelor
care
pot
fi
transmise

într-un singur mesaj
ș
i numărul de mesaje care pot rămâne nesolu
ț
ionate în coadă.

Multe
implementări
ale
cozilor
de
mesaje
func
ț
ionează
intern:
într-un
sistem
de

operare sau într-o aplica
ț
ie. Astfel de cozi există doar în scopul acestui sistem.

Alte
implementări
permit
transmiterea
de
mesaje
între
diferite
sisteme
de
calculatoare,

care
pot
conecta
mai
multe
aplica
ț
ii
ș
i
mai
multe
sisteme
de
operare.
Aceste
sisteme
de

a
ș
teptare
a
mesajelor
oferă
în
mod
tipic
o
func
ț
ionalitate
de
rezisten
ț
ă
îmbunătă
ț
ită
pentru
a

se
asigura
că
mesajele
nu
se
"pierd"
în
cazul
unei
defec
ț
iuni
a
sistemului.
Exemple
de

implementări
comerciale
ale
acestui
tip
de
software
de
a
ș
teptare
a
mesajelor
(cunoscut
ș
i
sub

numele
de
middleware
orientat
spre
mesaje)
includ
IBM
MQ
(fosta
serie
MQ)
ș
i
Oracle

Advanced
Queuing
(AQ).
Există
un
standard
Java
denumit
Java
Message
Service,
care
are

câteva implementări de software propriu
ș
i liber.

Implementările
există
ca
software
proprietar,
furnizat
ca
un
serviciu,
software
open

source sau o solu
ț
ie bazat ă pe hardware.

Op
ț
iunile
proprie tare
au
cea
mai
lungă
istorie
ș
i
includ
produse
de
la
începutul

a
ș
teptărilor
mesajelor,
cum
ar
fi
IBM
MQ,
ș
i
cele
legate
de
sisteme
de
operare
specifice,
cum

ar fi Microsoft Message Queuing.

Există,
de
asemenea,
op
ț
iuni
de
servicii
de
a
ș
teptare
a
mesajelor
bazate
pe
cloud,
cum

ar
fi
Amazon
Simple
Queue
Service
(SQS),
StormMQ,
IronMQ
ș
i
IBM
MQ
are
un
serviciu

de gestionare în a
ș
teptare a cloud-ului.

Există
o
serie
de
op
ț
iuni
de
tip
open
source
pentru
sistemele
middleware
de

mesagerie,
inclusiv
Apache
ActiveMQ,
Apache
Kafka,
Apache
Qpid,
Apache
RocketMQ,

Beanstalkd,
Enduro
/
X,
HTTPSQS,
JBoss
Messaging,
JORAM,
RabbitMQ,
Sun
Open

Message Queue
ș
i Tarant ool.

În
plus
fa
ț
ă
de
sistemele
open-source,
middleware-ul
de
mesagerie
bazat
pe
hardware

există
cu
furnizori
precum
Solace,
Apigee
ș
i
Tervela
care
oferă
a
ș
teptări
prin
căi
de
date

siliciu sau siliciu / software. IBM oferă de asemenea software-ul MQ pe un aparat.

Majoritatea
sistemelor
de
operare
în
timp
real
(RTOS),
cum
ar
fi
VxWorks
ș
i
QNX,

încurajează
utilizarea
căutării
mesajelor
ca
mecanism
de
comunicare
inter-proces
sau
inter-fir

primar.
Integrarea
strânsă
care
rezultă
între
trecerea
mesajului
ș
i
planificarea
procesorului

este
atribuită
ca
un
motiv
principal
pentru
utilizarea
RTOS
pentru
aplica
ț
iile
în
timp
real.

Exemplele
timpurii
ale
RTOS-urilor
comerciale
care
au
încurajat
o
bază
de
coadă
de
mesaje

pentru
comunicarea
între
fire
includ,
de
asemenea,
VRTX
ș
i
pSOS
+,
ambele
datează
până
la

începutul
anilor
1980.
Limbajul
de
programare
Erlang
utilizează
procese
pentru
a
asigura

concuren
ț
a; aceste proces e comunică în mod asincron utilizând căutarea mesajelor.[7]

Utilizare

Într-o
implementare
obi
ș
nuită
de
a
ș
teptare
a
mesajelor,
un
administrator
de
sistem

instalează
ș
i
configurează
software-ul
de
a
ș
teptare
a
mesajelor
(un
manager
de
coadă
sau
un

broker)
ș
i
define
ș
te
o
coadă
de
mesaje
sau
se
înregistrează
cu
un
serviciu
de
a
ș
teptare
a

mesajelor.

O
aplica
ț
ie
înregistrează
apoi
o
rutină
software
care
"ascultă"
mesajele
plasate
pe

coadă.

Aplica
ț
iile
secund are
ș
i
ulterioare
se
pot
conecta
la
coadă
ș
i
pot
transfera
un
mesaj
pe

acesta.
Software-ul
managerului
de
coadă
gestionează
mesajele
până
când
o
aplica
ț
ie
de

primire
conectează
ș
i
apoi
apelează
rutina
software
înregistrată.
Aplica
ț
ia
de
primire
apoi

procesează mesajul într-un mod adecvat.

Există
adesea
numeroase
op
ț
iuni
în
ceea
ce
prive
ș
te
semantica
exactă
a
trecerii

mesajului, inclusiv:

–
Durabilitate
–
mesajele
pot
fi
păstrate
în
memorie,
scrise
pe
disc
sau
chiar

implicate
într-un
DBMS
dacă
nevoia
de
fiabilitate
indică
o
solu
ț
ie
cu
resurse

mai mari.

–
Politici de securitate – ce aplica
ț
ii ar trebui să aibă acces la aceste mesaje

–
Politica
de
purjare
a
mesajelor
–
cozile
sau
mesajele
pot
avea
un
"timp
pentru
a

trăi"

–
Filtrarea
mesajelor
–
unele
sisteme
acceptă
filtrarea
datelor
astfel
încât

abonatul
să
poată
vedea
numai
mesaje
care
corespund
anumitor
criterii
de

interes pre-specificate

–
Politici
de
livrare
–
trebuie
să
garantăm
că
un
mesaj
este
transmis
cel
pu
ț
in
o
dată

sau nu mai mult de o dată

–
Politicile
de
rutare
–
într-un
sistem
cu
multe
servere
de
coadă,
ce
servere
ar
trebui

să primească mesaje sau mesaje de coadă

–
Politicile
de
dozare
–
ar
trebui
ca
mesajele
să
fie
livrate
imediat?
Sau
ar
trebui

sistemul să a
ș
tepte un pic
ș
i să încerce să livreze m ai multe mesaje simultan

–
Notificarea
primirii
–
Un
editor
poate
avea
nevoie
să
ș
tie
când
unii
sau
to
ț
i

abona
ț
ii au primit un mesaj.

Acestea
sunt
considera
ț
iile
care
pot
avea
efecte
substan
ț
iale
asupra
semanticii

tranzac
ț
iilor, a fiabilită
ț
ii sistemului
ș
i a eficien
ț
ei sistemului.

Standarde
ș
i pro tocoale

Din
punct
de
vedere
istoric,
a
ș
teptarea
mesajelor
a
utilizat
protocoale
proprii,
închise,

limitând
capacitatea
diferitelor
sisteme
de
operare
sau
limbi
de
programare
de
a
interac
ț
iona

într-un set eterogen de medii.

O
încercare
timpurie
de
a
face
ca
coresponden
ț
a
mesajelor
să
fie
mai
omniprezentă
a

fost
specifica
ț
ia
JMS
de
la
Sun
Microsystems,
care
a
furnizat
o
abstractizare
Java
a
unui
API

client.
Acest
lucru
ia
permis
dezvoltatorilor
Java
să
comute
între
furnizorii
de
a
ș
teptare
a

mesajelor
într-un
mod
similar
cu
cel
al
dezvoltatorilor
care
utilizează
baze
de
date
SQL.
În

practică,
având
în
vedere
diversitatea
tehnicilor
ș
i
scenariilor
de
a
ș
teptare
a
mesajelor,
aceasta

nu a fost întotdeauna la fel de practică pe cât ar putea fi.

Au
apărut
trei
standarde
care
sunt
utilizate
în
implementările
de
coadă
de
mesaje
open

source:

1.
Advanced
Message
Queuing
Protocol
(AMQP)
–
protocol
de
coadă
bogat
în

func
ț
ii, ap robat ca ISO / IEC 19464 din aprilie 2014

2.
Streaming
Text
Oriented
Messaging
Protocol
(STOMP)
–
protocol
simplu,

orientat spre text

3.
MQTT
(fostul
MQ
Telemetry
Transport)
–
protocol
de
coadă
de
mesaje
u
ș
oare,

în special pentru dispozitivele încorporate

Aceste
protocoale
se
află
în
diferite
etape
ale
standardizării
ș
i
adoptării.
Primele
două

func
ț
ionează la acela
ș
i nivel ca HTTP,iar MQTT la nivelul TCP / IP.

Unele
implementări
proprietare
utilizează,
de
asemenea,
HTTP
pentru
a
furniza

a
ș
teptarea
mesajelor
de
către
unele
implementări,
cum
ar
fi
SQS
de
la
Amazon.
Acest
lucru
se

datorează
faptului
că
este
întotdeauna
posibil
ca
stratul
de
comportament
asincron
(care
este

ceea
ce
este
necesar
pentru
a
ș
teptarea
mesajelor)
să
fie
supus
unui
protocol
sincron
folosind

semantica
răspuns-cerere.
Cu
toate
acestea,
astfel
de
implementări
sunt
constrânse
de
protocolul

de
bază
în
acest
caz
ș
i
este
posibil
să
nu
poată
oferi
fidelitatea
completă
sau
setul
de
op
ț
iuni

necesare în transmiterea mesajelor de mai sus.[7]

Publish-subscribe pattern

În
arhitectura
software,
publish-subscribe
este
un
model
de
mesagerie
în
care
expeditorii

de
mesaje,
numi
ț
i
editor i,
nu
programează
mesajele
care
trebuie
trimise
direct
către
anumi
ț
i

receptori,
numi
ț
i
abona
ț
i,
ci
clasifică
mesajele
publicate
în
clase
fără
cuno
ș
tin
ț
ă
asupra

existen
ț
ei
abona
ț
ilor
sau
a
numărului
de
abona
ț
i.
În
mod
similar,
abona
ț
ii
î
ș
i
exprimă
interesul

pentru
una
sau
mai
multe
clase
ș
i
primesc
numai
mesaje
care
prezintă
interes
fără
să
ș
tie
de
ce

editori există, dacă există.

Publish-Subscribe
este
un
frate
al
paradigmei
de
coadă
de
mesaje
ș
i
este
de
obicei
o

parte
a
unui
sistem
middleware
orientat
spre
mesaj.
Majoritatea
sistemelor
de
mesagerie
suportă

atât
modelele
de
coresponden
ț
ă
pub
/
sub
ș
i
mesajele
de
coadă
de
mesaje
din
API-ul
lor,
de
ex.

Serviciul de mesaje Java (JMS).

Acest
model
oferă
o
scalabilitate
sporită
a
re
ț
elei
ș
i
o
topologie
mai
dinamică
a
re
ț
elei,

cu o flexibilitate redusă pentru modificarea editorului
ș
i structura datelor publicate.

Context
ș
i proble mă

În
aplica
ț
iile
bazate
pe
cloud
ș
i
distribuite,
componentel e
sistemului
trebuie
adesea
să

furnizeze informa
ț
ii altor componente, pe măsură ce evenimentele se întâmplă.

Mesageria
asincronă
reprezintă
o
modalitate
eficientă
de
a
decupla
expeditorii
de
la

consumatori
ș
i
de
a
evita
blocarea
expeditorului
să
a
ș
tepte
un
răspuns.
Cu
toate
acestea,

utilizarea
unei
coadă
dedicată
de
mesaje
pentru
fiecare
consumator
nu
scade
în
mod
eficient

pentru
mul
ț
i
consumatori .
De
asemenea,
unii
dintre
consumatori
ar
putea
fi
interesa
ț
i
doar
de
un

subset
de
informa
ț
ii.
Cum
poate
expeditorul
să
anun
ț
e
evenimente
pentru
to
ț
i
consumatorii

interesa
ț
i fără să
ș
tie identitatea lor?

Solu
ț
ia

Introducem un subsistem de mesagerie asincron care include următoarele:

–
Un
canal
de
mesaje
de
intrare
folosit
de
expeditor.
Pachetele
expeditorului
sunt

introduse
în
mesaje,
utilizând
un
format
de
mesaj
cunoscut
ș
i
trimit
aceste

mesaje
prin
intermediul
canalului
de
intrare.
Expeditorul
în
acest
model
este,
de

asemenea, numit editor.

Nota:

Un
mesaj
este
un
pachet
de
date.
Un
eveniment
este
un
mesaj
care

notifică alte componente despre o schimbare sau o ac
ț
iune care a avut loc.

–
Un
canal
de
mesaje
de
ie
ș
ire
pentru
fiecare
consumator.
Consumatorii
sunt

cunoscu
ț
i ca abona
ț
i.

–
Un
mecanism
pentru
copierea
fiecărui
mesaj
de
la
canalul
de
intrare
la
canalele

de
ie
ș
ire
pentru
to
ț
i
abona
ț
ii
interesa
ț
i
de
acel
mesaj.
Această
opera
ț
iune
este
de

obicei
gestionată
de
un
intermediar,
cum
ar
fi
un
broker
de
mesaje
sau
o

magistrală de evenimente.[8][9]

Următoarea diagramă prezintă componentele logice ale acestui model:

Filtrarea mesajelor

În
modelul
de
publicare-abonare,
abona
ț
ii
primesc
de
obicei
numai
un
subset
din
totalul

mesajelor
publicate.
Procesul
de
selectare
a
mesajelor
pentru
recep
ț
ie
ș
i
prelucrare
se
nume
ș
te

filtrare. Există două forme comune de filtrare: bazate pe subiect
ș
i bazate pe con
ț
inut.

Într-un
sistem
bazat
pe
subiecte
(topic-based),
mesajele
sunt
publicate
pe
"subiecte"
sau

pe
canale
logice.
Abona
ț
ii
dintr-un
sistem
bazat
pe
subiecte
vor
primi
toate
mesajele
publicate

pe
subiectele
la
care
se
abonează
ș
i
to
ț
i
abona
ț
ii
la
un
subiect
vor
primi
acelea
ș
i
mesaje.
Editorul

este responsabil pentru definirea claselor de mesaje la care abona
ț
ii se pot abona.

Într-un
sistem
bazat
pe
con
ț
inut,
mesajele
sunt
difuzate
numai
unui
abonat
dacă

atributele
sau
con
ț
inutul
acestor
mesaje
corespund
constrângerilor
definite
de
abonat.
Abonatul

este responsabil pentru clasificarea mesajelor.

Unele
sisteme
sus
ț
in
un
hibrid
dintre
cele
două;
editorii
trimit
mesaje
la
un
subiect
în

timp ce abona
ț
ii înregistr ează abonamentele bazate pe con
ț
inut la unul sau mai multe subiecte.

Topologii

În
multe
sisteme
pub
/
sub,
editorii
trimit
mesaje
către
un
broker
intermediar
de
mesaje

sau
o
magistrală
de
evenimente
(event
bus),
iar
abona
ț
ii
înregistrează
abonamentele
la

respectivul
broker,
permi
ț
ând
brokerului
să
efectueze
filtrarea.
Brokerul
efectuează
în
mod

normal
o
func
ț
ie
de
stoca re
ș
i
transmitere
pentru
a
direc
ț
iona
mesajele
de
la
editori
la
abona
ț
i.
În

plus, brokerul poate prioritiza mesajele într-o coadă înainte de rutare.

Abona
ț
ii
se
pot
înregistra
pentru
anumite
mesaje
la
momentul
construirii,
la
timpul
de

ini
ț
ializare
sau
la
timpu l
de
execu
ț
ie.
În
sistemele
GUI,
abon a
ț
ii
pot
fi
codifica
ț
i
pentru
a

manipula
comenzile
utilizatorilor
(de
exemplu,
clic
pe
un
buton),
ceea
ce
corespunde

înregistrării
timpului
de
construire.
Unele
cadre
ș
i
produse
software
utilizează
fi
ș
iere
de

configurare
XML
pentru
a
înregistra
abona
ț
ii.
Aceste
fi
ș
iere
de
configurare
sunt
citite
la

momentul
ini
ț
ializării.
Cea
mai
sofisticată
alternativă
este
atunci
când
abona
ț
ii
pot
fi
adăuga
ț
i

sau
elimina
ț
i
în
timpul
rulării.
Această
din
urmă
abordare
este
utilizată,
de
exemplu,
în

declan
ș
atoare de baze de date, liste de discu
ț
ii
ș
i RSS.

Serviciul
intermediar
de
servicii
de
distribu
ț
ie
a
datelor
(DDS)
nu
folose
ș
te
un

intermediar
în
mijloc.
În
schimb,
fiecare
editor
ș
i
abonat
din
sistemul
pub
/
sub
partajează

meta-date
reciproc
prin
IP
multicast.
Editorul
ș
i
abona
ț
ii
cachează
aceste
informa
ț
ii
la
nivel

local
ș
i direc
ț
ionează mesaje pe baza descoperirii reciproce în cun oa
ș
terea comună.

Avantaje

–
Loose coupling (cuplaj slab)

Editorii
sunt
cupla
ț
i
liber
cu
abona
ț
ii
ș
i
nu
trebuie
să
ș
tie
nici
măcar
despre

existen
ț
a
lor.
Cu
tema
pe
care
se
concentrează,
editorii
ș
i
abona
ț
ii
au
voie
să

rămână
ignoran
ț
i
în
ceea
ce
prive
ș
te
topologia
sistemului.
Fiecare
poate
continua

să func
ț
ioneze în mod normal, independent de celălalt.

În
paradigma
client-server
tradi
ț
ional
cuplată
strâns,
clientul
nu
poate
posta

mesaje
către
server
în
timp
ce
serverul
nu
se
execută
ș
i
serverul
nu
poate
primi

mesaje
decât
în
cazul
în
care
clientul
rulează.
Multe
sisteme
pub
/
sub
decuplează

nu
numai
loca
ț
iile
editorilor
ș
i
abona
ț
ilor,
ci
ș
i
deconectarea
acestora
temporar.

O
strategie
comună
folosită
de
anali
ș
tii
middleware
cu
astfel
de
sisteme
pub
/
sub

este
de
a
scoate
un
editor
pentru
a
permite
abonatului
să
lucreze
prin
restante
(o

formă de limitare a lă
ț
imii de bandă).

–
Scalability (scalabilitate)

Pub
/
sub
oferă
posibilitatea
unei
scalabilită
ț
i
mai
bune
decât
clientul-server

tradi
ț
ional ,
prin
operarea
paralelă,
caching-ul
mesajelor,
rutarea
pe
bază
de

copaci
sau
prin
re
ț
ea
etc.
Cu
toate
acestea,
în
anumite
tipuri
de
medii
de

întreprinderi
cu
cuplu
strâns,
pentru
a
deveni
centre
de
date
cu
mii
de
servere

care
partajează
infrastructura
pub
/
sub,
sistemele
curente
de
furnizori
pierd

adesea
acest
beneficiu;
scalabilitatea
pentru
pub
/
sub-produse
cu
încărcătură

ridicată în aceste contexte este o provocare pentru cercetare.

În
afara
mediului
de
afaceri,
pe
de
altă
parte,
pub
/
sub
paradigma
ș
i-a
dovedit

scalabilitatea
pentru
volume
mult
mai
mari
decât
cele
ale
unui
singur
centru
de

date,
oferind
mesaje
distribuite
pe
internet
prin
intermediul
protocoalelor
de

sindicare
web
cum
ar
fi
RSS
ș
i
Atom.
Aceste
protocoale
de
indicare
acceptă
o

laten
ț
ă
mai
mare
ș
i
lipsa
garan
ț
iilor
de
livrare,
în
schimbul
capacită
ț
ii
unui
server

Web
de
nivel
inferior
de
a
sindica
mesajele
către
(poten
ț
ial)
milioane
de
noduri

separate ale abona
ț
ilor.

Dezavantaje

Cea
mai
grava
problema
cu
sistemele
pub
/
sub
este
un
efect
secundar
al
avantajului
lor

principal: decuplarea editorului de la abonat.[9]

Probleme de livrare a mesajelor

Un
sistem
pub
/
sub
trebuie
să
fie
proiectat
cu
aten
ț
ie
pentru
a
putea
oferi
proprietă
ț
i
mai

puternice ale sistemului care ar putea necesita o anumită aplica
ț
ie, cum ar fi livrarea asigurată.

Brokerul
dintr-un
sistem
pub
/
sub
poate
fi
proiectat
să
transmită
mesaje
pentru
o

anumită
perioadă
de
timp,
dar
apoi
să
nu
mai
încerce
să
livreze,
indiferent
dacă
a
primit
sau
nu

confirmarea
primirii
mesajului
de
către
to
ț
i
abona
ț
ii.
Un
pub
/
sub-sistem
conceput
în
acest
mod

nu
poate
garanta
livrarea
mesajelor
către
orice
aplica
ț
ie
care
ar
putea
necesita
o
astfel
de
livrare

asigurată.
Pentru
a
realiza
o
astfel
de
livrare
asigurată
(de
exemplu,
solicitând
abonatului
să

publice
mesaje
de
primire),
trebuie
să
se
impună
o
cuplare
mai
strânsă
a
modelelor
unei
astfel

de perechi de editori
ș
i abona
ț
i în afara arhitecturii pub / sub.

Un
editor
dintr-un
sistem
pub
/
sub
poate
presupune
că
un
abonat
ascultă,
de
fapt,
când

acesta
nu
recep
ț
ionează
mesaje.
O
fabrică
poate
utiliza
un
sistem
pub
/
sub
în
care

echipamentele
pot
publica
probleme
sau
defec
ț
iuni
unui
abonat
care
afi
ș
ează
ș
i
înregistrează

aceste
probleme.
Dacă
loggerul
nu
reu
ș
e
ș
te
(blochează),
editorii
de
probleme
de
echipament
nu

vor
primi
neapărat
o
notificare
privind
eroarea
loggerului
ș
i
mesajele
de
eroare
nu
vor
fi
afi
ș
ate

sau
înregistrate
de
nici
un
echipament
din
sistemul
pub
/
sub.
Aceasta
este,
de
asemenea,
o

provocare
de
proiectare
pentru
arhitecturile
de
mesagerie
alternativă,
cum
ar
fi
un
sistem
client
/

server.
Într-un
sistem
client
/
server,
atunci
când
un
logger
de
eroare
e
ș
uează,
sistemul
va
primi

o
indica
ț
ie
a
erorii
logge rului
de
eroare
(server).
Cu
toate
acestea,
sistemul
client
/
server
va

trebui
să
se
ocupe
de
acel
e
ș
ec
prin
faptul
că
are
servere
redundante
de
logare
online
sau
prin

servere
de
înregistrare
dinamică
de
repornire.
Aceasta
adaugă
complexitatea
design-ului

clientului
ș
i
serverului,
precum
ș
i
arhitecturii
client
/
server
în
ansamblu.
Cu
toate
acestea,

într-un
sistem
pub
/
sub,
abona
ț
ii
redundan
ț
i
de
înregistrare,
care
sunt
duplicate
exacte
ale

loggerului
existent,
pot
fi
adăuga
ț
i
la
sistem
pentru
a
spori
fiabilitatea
înregistrării
fără
a
avea

vreun
impact
asupra
altor
echipamente
din
sistem.
Într-un
sistem
pub
/
sub,
caracteristica

înregistrării
mesajelor
de
eroare
asigurate
poate
fi
adăugată
treptat,
după
implementarea

func
ț
ionalită
ț
ii de bază a înregistrării mesajelor cu probleme de e chipament.

Modelul
pub
/
sub
scalează
bine
pentru
re
ț
elele
mici,
cu
un
număr
mic
de
noduri
de

editor
ș
i
abonat
ș
i
volum
redus
de
mesaje.
Cu
toate
acestea,
pe
măsură
ce
cre
ș
te
numărul
de

noduri
ș
i
mesaje,
probab ilitatea
de
instabilitate
cre
ș
te,
limitând
scalabilitatea
maximă
a
unei

re
ț
ele pub / sub. Exemple de instabilită
ț
i de transfer la scale mari includ:

–
Perioadele
de
supratensiuni
–
atunci
când
solicitările
abona
ț
ilor
saturează

transferul
de
re
ț
ea,
urmate
de
perioade
de
volum
redus
de
mesaje
(lă
ț
ime

de bandă de re
ț
ea sub-utilizată)

–
Slowdowns
–
cu
cât
mai
multe
aplica
ț
ii
utilizează
sistemul
(chiar
dacă

comunică
pe
canale
separate
/
sub-canale
separate)
debitul
volumului

mesajului către un abonat individual va încetini

Pentru
sistemele
pub
/
sub
care
utilizează
brokeri
(servere),
argumentul
pentru
un
broker

de
a
trimite
mesaje
unui
abonat
este
în
bandă
ș
i
poate
fi
supus
unor
probleme
de
securitate.

Brokerii
ar
putea
fi
păcăli
ț
i
în
a
trimite
notificări
unui
client
gre
ș
it,
amplificând
cererile
de
refuz

al
serviciului
împotriva
clientului.
Brokerii
în
ș
i
ș
i
ar
putea
fi
supraîncărca
ț
i
deoarece
alocă

resurse pentru a urmări abonamentele create.

Chiar
ș
i
în
cazul
sistemelor
care
nu
se
bazează
pe
brokeri,
un
abonat
ar
putea
primi
date

pe
care
nu
este
autorizat
să
le
primească.
Un
editor
neautorizat
poate
fi
capabil
să
introducă

mesaje
incorecte
sau
vătămătoare
în
sistemul
pub
/
sub.
Acest
lucru
este
valabil
mai
ales
pentru

sistemele
care
difuzează
mesajele.
Criptarea
(de
exemplu,
Transport
Layer
Security
(SSL
/

TLS))
poate
împiedica
accesul
neautorizat,
dar
nu
poate
împiedica
introducerea
mesajelor

dăunătoare
de
către
editorii
autoriza
ț
i.
Alte
arhitecturi
decât
pub
/
sub,
cum
ar
fi
sistemele
client

/
server,
sunt,
de
asemenea,
vulnerabile
la
expeditorii
autoriza
ț
i
de
mesaje
care
se
comportă
în

mod mali
ț
ios.[9]

Blockchain

Un
blockchain,
ini
ț
ial
block
chain,
este
o
listă
tot
mai
mare
de
înregistrări,
numite

blocuri,
care
sunt
legate
prin
criptografie.
Fiecare
bloc
con
ț
ine
un
hash
criptografic
al
blocului

anterior,
un
marcaj
de
timp
ș
i
date
privind
tranzac
ț
iile
(în
general
reprezentate
ca
un
arbore

Merkle).

Prin
proiectare,
un
blocaj
este
rezistent
la
modificarea
datelor.
Este
"un
registru
deschis,

distribuit
care
poate
înregistra
tranzac
ț
iile
între
două
păr
ț
i
eficient
ș
i
într-un
mod
verificabil
ș
i

permanent".
Pentru
a
fi
utilizat
ca
registru
distribuit,
un
bloc
de
blockchain
este
administrat
în

mod
obi
ș
nuit
de
o
re
ț
ea
peer-to-peer,
aderând
colectiv
la
un
protocol
pentru
comunicarea
între

noduri
ș
i
validarea
blocurilor
noi.
Odată
înregistrate,
datele
dintr-un
bloc
dat
nu
pot
fi

modificate
retroactiv
fără
modificarea
tuturor
blocurilor
ulterioare,
ceea
ce
necesită
consensul

majorită
ț
ii
re
ț
elei.
De
ș
i
înregistrările
de
blocuri
nu
sunt
inalterabile,
blocurile
pot
fi
considerate

sigure
prin
proiectare
ș
i
exemplifică
un
sistem
computerizat
distribuit
cu
o
toleran
ț
ă
ridicată
la

erori bizantine. De aceea, consensul descentralizat a fost revendicat cu un blocaj.

Blockchain
a
fost
inventat
de
o
persoană
(sau
un
grup
de
oameni),
folosind
numele

Satoshi
Nakamoto,
în
2008,
pentru
a
servi
drept
registru
de
tranzac
ț
ii
publice
al
unui
bitcoin
de

criptocurrency.
Identitatea
lui
Satoshi
Nakamoto
este
necunoscută.
Inven
ț
ia
blockchain-ului

pentru
bitcoin
a
făcut-o
prima
monedă
digitală
pentru
a
rezolva
problema
dublării
cheltuielilor

fără
a
avea
nevoie
de
o
autoritate
de
încredere
sau
de
un
server
central.
Designul
bitcoin
a

inspirat
ș
i
alte
aplica
ț
ii,
iar
blocurile
care
pot
fi
citite
de
către
public
sunt
utilizate
pe
scară
largă

de
către
criptocurrency.
Blockchain-ul
este
considerat
un
tip
de
cale
ferată
de
plă
ț
i.
Au
fost

propuse
blocuri
private
pentru
utilizarea
în
scopuri
comerciale.
Surse
precum
Computerworld

au
numit
comercializarea
unor
astfel
de
blocuri
fără
un
model
de
securitate
adecvat
"ulei
de

ș
arpe".

Structura

Un
blockchain
este
un
registru
digital
descentralizat,
distribuit
ș
i
public
care
este
utilizat

pentru
a
înregistra
tranzac
ț
ii
pe
mai
multe
computere,
astfel
încât
orice
înregistrare
implicată
nu

poate
fi
modificată
retroactiv,
fără
modificarea
tuturor
blocurilor
ulterioare.
Acest
lucru
permite

participan
ț
ilor
să
verifice
ș
i
să
auditeze
tranzac
ț
iile
în
mod
independent
ș
i
relativ
ieftin.
O
bază

de
date
de
tip
blockchain
este
gestionată
autonom
folosind
o
re
ț
ea
peer-to-peer
ș
i
un
server

distribuit
de
timbre.
Acestea
sunt
autentificate
de
o
colaborare
în
masă
alimentată
de
interese

colective.
Un
astfel
de
design
facilitează
un
flux
robust
de
lucru
în
care
incertitudinea

participan
ț
ilor
în
ceea
ce
prive
ș
te
securitatea
datelor
este
margin ală.
Utilizarea
unui
blockchain

elimină
caracteristica
reproductibilită
ț
ii
infinite
dintr-un
material
digital.
Aceasta
confirmă

faptul
că
fiecare
unitate
de
valoare
a
fost
transferată
o
singură
dată,
rezolvând
problema
pe

termen
lung
a
cheltuielilor
duble.
Un
blockchain
fost
descris
ca
un
protocol
de
schimb
de

valoare.
Un
blockchain
poate
să-
ș
i
men
ț
ină
drepturile
de
propri etate
deoarece,
atunci
când
este

configurat
în
mod
corespunzător
pentru
a
detalia
acordul
de
schimb,
acesta
oferă
o
înregistrare

care obligă oferta
ș
i accep tarea.[10]

Blocuri

Blocurile
de
ț
in
loturi
de
tranzac
ț
ii
valide
care
sunt
rulate
ș
i
codificate
într-un
arbore

Merkle.
Fiecare
bloc
include
hash-ul
criptografic
al
blocului
anterior
din
blockchain,
legând

cele
două.
Blocurile
legate
formează
un
lan
ț
.
Acest
proces
iterativ
confirmă
integritatea
blocului

anterior, tot drumul înapoi la blocul original de geneză.

Uneori,
blocurile
separate
pot
fi
produse
simultan,
creând
o
furcă
temporară.
În
plus
fa
ț
ă

de
istoricul
bazat
pe
hash,
orice
bloc
de
blocuri
are
un
algoritm
specificat
pentru
notarea

diferitelor
versiuni
ale
istoricului,
astfel
încât
unul
cu
o
valoare
mai
mare
să
poată
fi
selectat
fa
ț
ă

de
altele.
Blocurile
care
nu
sunt
selectate
pentru
a
fi
incluse
în
lan
ț
se
numesc
blocuri
orfane.

Peerii
care
sus
ț
in
baza
de
date
au
versiuni
diferite
ale
istoriei
din
când
în
când.
Ei
păstrează

numai
versiunea
cu
cea
mai
mare
notă
a
bazei
de
date
cunoscute.
Ori
de
câte
ori
un
coleg

prime
ș
te
o
versiune
mai
mare
(de
obicei
vechea
versiune
cu
un
singur
bloc
nou
adăugat),

acestea
î
ș
i
extind
sau
suprascrie
propria
bază
de
date
ș
i
retransmit
îmbunătă
ț
irea
la
colegii
lor.

Nu
există
niciodată
o
garan
ț
ie
absolută
că
o
anumită
intrare
va
rămâne
în
cea
mai
bună
versiune

a
istoriei
pentru
totdeauna.
Grupurile
de
blocuri
sunt
de
obicei
construite
pentru
a
adăuga
scorul

de
blocuri
noi
pe
blocuri
vechi
ș
i
li
se
oferă
stimulente
pentru
a
se
extinde
cu
blocuri
noi,
în
loc

să
suprascrie
blocurile
vechi.
Prin
urmare,
probabilitatea
ca
o
intrare
să
devină
înlocuită
scade

exponen
ț
ial,
deoarece
mai
multe
blocuri
sunt
construite
deasupra
acesteia,
devenind,
în
cele
din

urmă,
foarte
scăzute.
De
exemplu,
bitcoin
utilizează
un
sistem
de
verificare
a
muncii,
unde

lan
ț
ul
cu
cea
mai
cumula tă
dovadă
a
muncii
este
considerat
unul
valid
de
re
ț
ea.
Există
o
serie
de

metode
care
pot
fi
utilizate
pentru
a
demonstra
un
nivel
suficient
de
calcul.
În
cadrul
unui

blocaj, calculul este efectuat în mod redundant, nu în mod tradi
ț
ional separat
ș
i paralel.

Timpul de blocare

Timpul
de
blocare
este
timpul
mediu
necesar
re
ț
elei
pentru
a
genera
un
bloc
suplimentar

în
blocul
de
blocuri.
Unele
blocuri
de
blocuri
creează
un
nou
bloc
la
fel
de
frecvent
ca
la
fiecare

cinci
secunde.
Până
la
finalizarea
blocului,
datele
incluse
devin
verificabile.
În
criptocurrency,

aceasta
este
practic
când
tranzac
ț
ia
are
loc,
astfel
că
un
timp
de
blocare
mai
scurt
înseamnă

tranzac
ț
ii
mai
rapide.
Timpul
de
blocare
pentru
Ethereum
este
stabilit
între
14
ș
i
15
secunde,
în

timp ce pentru bitcoin este de 10 minute.[10]

TEHNOLOGII FOLOSITE ÎN APLICA
Ț
IE

NodeJS

Node.js
este
un
mediu
open-source,
cross-platform
JavaScript
run-time
care
execută

codul
JavaScript
în
afara
unui
browser.
Node.js
permite
dezvoltatorilor
să
utilizeze
JavaScript

pentru
a
scrie
instrumentele
din
linia
de
comandă,
iar
pentru
server-side-script-running

script-side
pentru
a
produce
con
ț
inutul
paginii
web
dinamice
înainte
ca
pagina
să
fie
trimisă

browser-ului
web
al
utilizatorului.
În
consecin
ț
ă,
Node.js
reprezintă
o
paradigmă
"JavaScript

peste
tot",
unificând
dezvoltarea
aplica
ț
iilor
web
în
jurul
unui
singur
limbaj
de
programare,

mai degrabă decât limbaje diferite pentru scripturile server
ș
i client.[11]

De
ș
i
.js
este
extensia
standard
de
nume
de
fi
ș
ier
pentru
codul
JavaScript,
numele

"Node.js"
nu
se
referă
la
un
anumit
fi
ș
ier
în
acest
context
ș
i
este
doar
numele
produsului.

Node.js
are
o
arhitectură
bazată
pe
evenimente,
capabilă
de
I
/
O
asincron.
Aceste
op
ț
iuni
de

proiectare
urmăresc
să
optimizeze
capacitatea
ș
i
scalabilitatea
în
aplica
ț
iile
web
cu
multe

opera
ț
ii
de
intrare
/
ie
ș
ire,
precum
ș
i
pentru
aplica
ț
ii
web
în
timp
real
(de
exemplu,
programe

de comunicare în timp real
ș
i jocuri de browser).

Proiectul
de
dezvoltare
distribuit
Node.js,
guvernat
de
Funda
ț
ia
Node.js,
este
facilitat

de programul Linux Foundation's Collaborative Projects.

Coporatii
ce
folosesc
software-ul
Node.js
includ
GoDaddy,
Groupon,
IBM,
LinkedIn,

Microsoft, Netflix, Rakuten, SAP, Voxer, Walmart,
ș
i Yahoo!.[11][12]

Privire de ansamblu

Node.js
permite
crearea
de
servere
web
ș
i
instrumente
de
re
ț
ea
folosind
JavaScript
ș
i

o
colec
ț
ie
de
"module"
care
gestionează
diferite
func
ț
ionalită
ț
i
de
bază.
Modulele
sunt

furnizate
pentru
sistemul
de
fi
ș
iere
I
/
O,
în
re
ț
ea
(DNS,
HTTP,
TCP,
TLS
/
SSL
sau
UDP),

date
binare
(buffer-uri),
func
ț
ii
criptografice,
fluxuri
de
date
ș
i
alte
func
ț
ii
de
bază.
Modulele

Node.js
folosesc
un
API
proiectat
pentru
a
reduce
complexitatea
aplica
ț
iilor
de
tipărire
a

serverului.

De
ș
i
ini
ț
ial
sistemul
de
module
a
fost
bazat
pe
modelul
modulului
commonjs,

introducerea
recentă
a
modulelor
în
specifica
ț
ia
ECMAScript
a
schimbat
direc
ț
ia
de
utilizare

a modulelor ECMAScript în Node.js în mod implicit.

Node.js
este
suportat
oficial
pe
Linux,
MacOS
ș
i
Microsoft
Windows
7
ș
i
Server

2008.
Există
ș
i
suportul
de
nivel
2
pentru
SmartOS
ș
i
IBM
AIX.
Suport
experimental
pentru

FreeBSD;
OpenBSD
func
ț
ionează
ș
i,
exemplu
fiind
versiunile
LTS
disponibile
pentru
IBM
i

(AS
/
400).
Codul
sursă
furnizat
poate
fi,
de
asemenea,
construit
pe
sisteme
de
operare

similare
celor
sus
ț
inute
oficial
sau
modificate
de
ter
ț
i
pentru
a
sprijini,
cum
ar
fi
serverele

NonStop
ș
i
Unix.
Alter nativ,
acesta
poate
fi
scris
cu
CoffeeScript
(alternativă
JavaScript),

Dart
sau
TypeScript
(formulare
puternică
de
JavaScript)
sau
orice
alt
limbaj
care
poate
fi

compilat în JavaScript.

Node.js
este
utilizat
în
principal
pentru
a
construi
programe
de
re
ț
ea,
cum
ar
fi
servere

Web.
Cea
mai
importantă
diferen
ț
ă
dintre
Node.js
ș
i
PHP
este
că
majoritatea
func
ț
iilor
în

blocul
PHP
până
la
finalizare
(comenzile
se
execută
numai
după
finalizarea
instructiunilor),

în
timp
ce
func
ț
iile
Node.js
sunt
non-blocante
(comenzile
se
execută
simultan
sau
chiar

paralel,
ș
i folosi
ț
i apelurile de apel pentru a semnala finalizarea sa u e
ș
ecul.)

Arhitectura platformei

Node.js
aduce
programare
bazată
pe
evenimente
pe
servere
web,
permi
ț
ând

dezvoltarea
de
servere
web
rapide
în
JavaScript.
Dezvoltatorii
pot
crea
servere
scalabile
fără

a
folosi
filetarea,
utilizând
un
model
simplificat
de
programare
bazată
pe
evenimente,
care

utilizează
callback-uri
pentru
a
semnala
finalizarea
unei
sarcini.
Node.js
conectează
u
ș
urin
ț
a

unui limbaj de scripting (JavaScript) cu puterea programării de re
ț
ea Unix.

Node.js
a
fost
construit
pe
motorul
Google
V8
JavaScript,
deoarece
a
fost
deschis
cu

licen
ț
ă
BSD.
Acesta
este
expert
cu
fundamentele
internetului,
cum
ar
fi
HTTP,
DNS,
TCP.

JavaScript
a
fost,
de
asemenea,
un
limbaj
binecunoscut,
făcând
Node.js
accesibil
comunită
ț
ii

de dezvoltare web.[12]

Suport pentru industrie

Există
mii
de
biblioteci
open-source
pentru
Node.js,
cele
mai
multe
găzduite
pe
site-ul

web
npm.
Comunitatea
de
dezvoltatori
Node.js
are
două
liste
de
discu
ț
ii
principale
ș
i
canalul

IRC
#
node.js
pe
freenode.
Există
mai
multe
conferin
ț
e
ș
i
evenimente
pentru
dezvoltatori
care

sus
ț
in
comunitatea
Node .js,
inclusiv
NodeConf,
Node
Interactive
ș
i
Node
Summit,
precum
ș
i

o serie de evenimente regionale.

Comunitatea
open-source
a
dezvoltat
cadre
web
pentru
a
accelera
dezvoltarea

aplica
ț
iilor.
Astfel
de
cadre
includ
Connect,
Express.js,
Socket.IO,
Feathers.js,
Koa.js,

Hapi.js,
Sails.js,
Meteor,
Derby
ș
i
multe
altele.
De
asemenea,
s-au
creat
diferite
pachete

pentru interfa
ț
a cu alte lim baje sau medii de rulare, cum ar fi Microsoft .NET.

IDE-urile
moderne
oferă
func
ț
ii
de
editare
ș
i
depanare
special
pentru
aplica
ț
iile

Node.js.
Aceste
IDE
includ
Atom,
Brackets,
JetBrains
WebStorm,
Microsoft
Visual
Studio

(cu
instrumente
Node.js
pentru
Visual
Studio
sau
TypeScript
cu
definirea
nodurilor)

NetBeans,
Nodeclipse
Enide
Studio
(bazat
pe
Eclipse)
ș
i
Visual
Studio
Code.
Anumite
IDE

bazate
pe
web
on-line
suportă,
de
asemenea,
Node.js,
cum
ar
fi
CodeYwhere,
Codenvy,

Cloud9 IDE, Koding
ș
i editorul fluxului vizual în Node-RED.

Guvernanta proiectului

În
2015,
diferite
ramuri
ale
comunită
ț
ii
mai
mari
Node.js
au
început
să
lucreze
în

cadrul
Funda
ț
iei
Node.js,
neutră
din
partea
vânzătorului.
Scopul
declarat
al
organiza
ț
iei
"este

de
a
permite
adoptarea
pe
scară
largă
ș
i
de
a
contribui
la
accelerarea
dezvoltării
Node.js
ș
i
a

altor
module
conexe
printr-un
model
de
guvernare
deschisă
care
încurajează
participarea,

contribu
ț
ia
tehnică
ș
i
un
cadru
pentru
gestionarea
pe
termen
lung
de
către
un
ecosistem

investit în succesul Node-ului."

Comitetul
Tehnic
de
Coordonare
al
Funda
ț
iei
Node.js
(TSC)
este
organismul
tehnic

de
conducere
al
Funda
ț
iei
Node.js.
TSC
este
responsabil
pentru
replica
de
bază
Node.js,

precum
ș
i
proiecte
depe ndente
ș
i
adiacente.
În
general,
TSC
deleagă
administrarea
acestor

proiecte
unor
grupuri
sau
comitete
de
lucru.
Grupul
LTS
care
gestionează
emisiunile

sus
ț
inute
pe
termen
lung
este
un
astfel
de
grup.
Alte
grupuri
actuale
includ:
site-ul
web,

streams,
Build,
Diagnostics,
i18n,
Evangelism,
Docker,
Addon
API,
Benchmarking,

Post-mortem, Intl, Documenta
ț
ie
ș
i Testare.[12]

RabbitMQ

RabbitMQ
este
un
software
open-source
broker
de
mesaje
(uneori
numit
middleware

orientat
spre
mesaje)
care
a
implementat
ini
ț
ial
Advanced
Message
Queuing
Protocol

(AMQP)
ș
i
de
atunci
a
fost
extins
cu
o
arhitectură
plug-in
pentru
a
suporta
Streaming
Text

Oriented
Messaging
Protocol
(STOMP)
,
Message
Queuing
Telemetry
Transport
(MQTT)
ș
i

alte protocoale.

Programul
de
server
RabbitMQ
este
scris
în
limbajul
de
programare
Erlang
ș
i
este

construit
pe
platforma
Open
Telecom
Platform
pentru
clustering
ș
i
failover.
Bibliotecile

clien
ț
ilor
pentru
interfa
ț
a
cu
brokerul
sunt
disponibile
pentru
toate
limbile
de
programare

majore.[13][14]

Arhitectura
de
bază
a
unei
cozi
de
mesaje
este
simplă,
există
aplica
ț
ii
client
numite

producători
care
creează
mesaje
ș
i
le
transmit
brokerului
(coada
de
mesaje).
Alte
aplica
ț
ii,

numite
consumatori,
se
conectează
la
coadă
ș
i
se
abonează
la
mesajele
care
urmează
să
fie

procesate.
Un
software
poate
fi
un
producător
sau
un
consumator
sau
un
consumator
ș
i
un

producător
de
mesaje.
Mesajele
plasate
pe
coadă
se
stochează
până
când
consumatorul
le

încarcă.

Istoric

Rabbit
Technologies
Ltd.
a
dezvoltat
ini
ț
ial
RabbitMQ.
Rabbit
Technologies
a
început

ca
un
joint-venture
între
LShift
ș
i
CohesiveFT
în
2007
ș
i
a
fost
achizi
ț
ionat
în
aprilie
2010
de

către
SpringSource,
divizie
a
VMware.
Proiectul
a
devenit
parte
a
Software-ului
Pivot
în
mai

2013.

Codul sursă este lansat sub licen
ț
a publică Mozilla. Proiectul constă în:

-Serverul de schimb RabbitMQ în sine

-Gateway-uri pentru protocoalele AMQP, HTTP, STOMP
ș
i MQTT

-Bibliotecile
client
AMQP
pentru
Java,
.NET
Framework
ș
i
Erlang.
(Clien
ț
ii

AMQP pentru alte limbi sunt disponibili de la al
ț
i furnizori.)

-O
platformă
plug-in
pentru
adăugări
personalizate,
cu
o
colec
ț
ie
predefinită

de plug-inuri acceptate, inclusiv:

-Un
plug-in
"Shovel"
care
se
ocupă
de
mutarea
sau
copierea
(replicarea)

mesajelor de la un broker la altul.

-Un
plug-in
"Federa
ț
ie"
care
permite
schimbul
eficient
de
mesaje
între
brokeri

(la nivel de schimb).

-Un
plug-in
"Management"
care
permite
monitorizarea
ș
i
controlul
brokerilor

ș
i grupurilor de brokeri.[1 3]

Când
ș
i de ce ar trebui să fie utilizat RabbitMQ?

Cozile
de
mesaje
permit
serverelor
web
să
răspundă
repede
la
solicitări,
în
loc
să
fie

for
ț
ate
să
efectueze
la
fa
ț
a
locului
proceduri
cu
resurse
grele.
Cozile
de
mesaje
sunt,
de

asemenea,
bune
atunci
când
dori
ț
i
să
distribui
ț
i
un
mesaj
mai
multor
destinatari
pentru

consum sau pentru a echilibra încărcăturile dintre lucrători.

Consumatorul
poate
lua
un
mesaj
din
coada
de
a
ș
teptare
ș
i
poate
începe
procesul
de

procesare
a
fi
ș
ierului
PDF
în
acela
ș
i
timp
în
care
producătorul
a
ș
teaptă
mesaje
noi
pe
coadă.

Consumatorul
poate
fi
pe
un
server
complet
diferit
de
cel
al
producătorului
sau
poate
fi

localizat
pe
acela
ș
i
server.
Cererea
poate
fi
creată
într-un
singur
limbaj
de
programare
ș
i

gestionată
într-un
alt
limbaj
de
programare
–
cele
două
aplica
ț
ii
vor
comunica
numai
prin

mesajele
pe
care
le
trimit
reciproc.
Din
acest
motiv,
cele
două
aplica
ț
ii
vor
avea
o
cuplare

joasă între expeditor
ș
i receptor.[14]

1.Utilizatorul trimite o cerere de creare PDF către aplica
ț
ia web.

2.Aplica
ț
ia
web
(producătorul)
trimite
un
mesaj
către
RabbitMQ,
inclusiv
datele
din

cerere, precum numele
ș
i adresa de e-mail.

3.Un
schimb
acceptă
mesajele
dintr-o
aplica
ț
ie
de
producător
ș
i
le
direc
ț
ionează

pentru a corecta cozi de mesaje pentru crearea PDF-ului.

4.Workerul
de
procesare
PDF
(consumatorul)
prime
ș
te
sarcina
ș
i
porne
ș
te
procesarea

PDF-ului.

Schimburi

Mesajele
nu
sunt
publicate
direct
într-o
coadă,
în
schimb,
producătorul
trimite
mesaje

către
un
schimb.
Un
schimb
este
responsabil
pentru
rutarea
mesajelor
la
diferitele
cozi.
Un

schimb
acceptă
mesaje
de
la
aplica
ț
ia
producătorului
ș
i
le
direc
ț
ionează
către
cozi
de
mesaje

cu ajutorul legărilor
ș
i cheilor de rutare. O legare este o legătură între o coadă
ș
i un schimb.

Modul de transmitere al unui mesaj

1.Producătorul
publică
un
mesaj

către
un
schimb.
Când
crea
ț
i
bursa,

trebuie
să
specifica
ț
i
tipul
acesteia.

Diferitele
tipuri
de
schimburi
sunt

explicate în detaliu mai târziu.

2.Schimbul
prime
ș
te
mesajul
ș
i

este
acum
responsabil
pentru
rutarea

mesajului.
Schimbul
ia
în
considerare

diferite
atribute
ale
mesajului,
cum
ar
fi

cheia
de
rutare,
în
func
ț
ie
de
tipul
de

schimb.

3.Legăturile
trebuie
create
de
la

schimb
la
cozi.
În
acest
caz,
vedem
două

legături
la
două
cozi
diferite
de
la
bursă.
Exchange
rută
mesajul
în
cozi
în
func
ț
ie
de

atributele mesajelor.

4.Mesajele rămân în coada de a
ș
teptare până când sunt gestionate de un consumator

5.Consumatorul se ocupă de mesajul respectiv.[14]

Kubernetes

Kubernetes
este
o
solu
ț
ie
open-source
Container
Orchestration
Engine
pentru

automatizarea
implementării,
scalarea,
ș
i
gestionarea
aplica
ț
iilor
containerizate.
Proiectul

open source este găzduit de Cloud Native Computing Foundation (CNCF).

Ce este Kubernetes

Kubernetes
este
o
platformă
open-source
portabilă,
extensibilă,
pentru
gestionarea

încărcărilor
ș
i
serviciil or
containerizate,
care
facilitează
configurarea
declarativă
ș
i

automatizarea.
Are
un
ecosistem
mare,
în
cre
ș
tere
rapidă.
Serviciile,
suportul
ș
i
solu
ț
iile

Kubernetes sunt disponibile pe scară largă.

Google
a
lansat
proiectul
Kubernetes
în
2014.
Kubernetes
se
bazează
pe
un
deceniu
ș
i

jumătate
de
experien
ț
ă
pe
care
Google
o
are
cu
volumele
de
lucru
de
produc
ț
ie
la
scară,

combinate cu cele mai bune idei
ș
i practici din comunitate.[15]

De ce am nevoie de Kubernetes si ce poate face

Kubernetes are o serie de caracteristici. Se poate considera ca:

o platformă pentru containere

o platformă de microservicii

o platformă cloud
ș
i multe altele.

Kubernetes
oferă
un
mediu
de
management
centrat
pe
containere.
Acesta
orchestrează

infrastructura
de
calcul,
re
ț
ea
ș
i
stocare,
în
numele
încărcărilo r
de
lucru
ale
utilizatorilor.

Acest
lucru
oferă
o
mare
parte
din
simplitatea
platformei
ca
serviciu
(PaaS
–
Platform
as
a

Service)
cu
flexibilitatea
infrastructurii
ca
serviciu
(IaaS
–
Infrastructure
as
a
Service)
ș
i

permite portabilitatea între furnizorii de infrastructură.

De ce este Kubernetes o platforma

Chiar
dacă
Kubernetes
oferă
o
mul
ț
ime
de
func
ț
ionalită
ț
i,
există
întotdeauna
noi

scenarii
care
ar
putea
beneficia
de
noi
caracteristici.
Fluxurile
de
lucru
specifice
aplica
ț
iilor

pot
fi
simplificate
pentru
a
accelera
viteza
dezvoltatorului.
Orchestrarea
ad-hoc,
care
este

acceptată
ini
ț
ial,
necesită
adesea
o
automatizare
robustă
la
scară.
Acesta
este
motivul
pentru

care
Kubernetes
a
fost,
de
asemenea,
proiectat
să
servească
drept
platformă
pentru
construirea

unui
ecosistem
de
componente
ș
i
instrumente
pentru
a
facilita
implementarea,
scalarea
ș
i

gestionarea aplica
ț
iilor.

Etichetele
permit
utilizatorilor
să-
ș
i
organizeze
resursele
pe
care
le
doresc.
Adnotările

permit
utilizatorilor
să
decoreze
resursele
cu
informa
ț
ii
personalizate
pentru
a
facilita

fluxurile
lor
de
lucru
ș
i
pentru
a
oferi
o
modalitate
u
ș
oară
ca
instrumentele
de
gestionare
să

fie controlate.

Ce nu este Kubernetes

Kubernetes
nu
este
un
sistem
tradi
ț
ional,
all-inclusive
PaaS
(platformă
ca
serviciu).

Deoarece
Kubernetes
operează
la
nivel
de
container,
nu
la
nivel
de
hardware,
acesta
oferă

câteva
caracteristici
general
aplicabile
pentru
ofertele
PaaS,
cum
ar
fi
implementarea,

scalarea,
echilibrarea
încărcării,
logarea
ș
i
monitorizarea.
Cu
toate
acestea,
Kubernetes
nu

este
monolit,
iar
aceste
solu
ț
ii
implicite
sunt
op
ț
ionale
ș
i
conectabile.
Kubernetes
pune
la

dispozi
ț
ie
platformele
pentru
construirea
platformelor
de
dezvoltatori,
dar
păstrează
alegerea

utilizatorului
ș
i flexibilita tea acolo unde este important.

Acesta:

–
Nu
limitează
tipurile
de
aplica
ț
ii
acceptate.
Kubernetes
î
ș
i
propune
să
sus
ț
ină
o

gama
extrem
de
variată
de
sarcini
de
lucru,
incluzând
sarcinile
fără
stare,

stateful
ș
i
de
prelucrare
a
datelor.
Dacă
o
aplica
ț
ie
poate
rula
într-un
container,

ar trebui să func
ț
ioneze bine pe Kubernetes.

–
Nu
implementează
codul
sursă
ș
i
nu
construie
ș
te
aplica
ț
ia.
Ac
ț
iunile
de

integrare,
livrare
ș
i
desfă
ș
urare
continuă
(CI/CD)
sunt
determinate
de
scopul
ș
i

preferin
ț
ele organiza
ț
iei, precum
ș
i de cerin
ț
ele tehnice.

–
Nu
oferă
servicii
la
nivel
de
aplica
ț
ie,
cum
ar
fi
middleware
(de
exemplu,bus

messaging),
cadre
de
procesare
a
datelor
(de
exemplu,
Spark),
baze
de
date
(de

exemplu
MySQL),
cache-uri
ș
i
sisteme
de
stocare
a
cluster-urilor
în
servicii.

Asemenea
componente
pot
rula
pe
Kubernetes
ș
i
/
sau
pot
fi
accesate
prin

aplica
ț
ii
care
rulează
pe
Kubernetes
prin
intermediul
unor
mecanisme

portabile, cum ar fi Open Service Broker.

–
Nu
operează
solu
ț
ii
de
înregistrare,
monitorizare
sau
alertare.
Oferă
unele

integra
ț
ii
ca
dovadă
a
conceptului
ș
i
mecanisme
pentru
colectarea
ș
i
exportul

de valori.

–
Nu
oferă
ș
i
nu
cere
un
limbaj
/
sistem
de
configurare
(de
exemplu,
jsonnet).

Acesta
oferă
un
API
declarativ
care
poate
fi
vizat
de
forme
arbitrare
de

specifica
ț
ii declarative.

–
Nu
oferă
ș
i
nu
adoptă
nici
o
configura
ț
ie
completă
a
ma
ș
inii,
sisteme
de

între
ț
inere , gestionare sau auto-vindecare.

În
plus,
Kubernetes
nu
este
un
sistem
simplu
de
orchestrare.
De
fapt,
elimină
nevoia

de
orchestrare.
Defini
ț
ia
tehnică
a
orchestra
ț
iei
este
executarea
unui
flux
de
lucru
definit:
mai

întâi
se
face
A,
apoi
B,
apoi
C.
În
schimb,
Kubernetes
este
alcătuit
dintr-un
set
de
procese
de

control
independente,
compozabile,
care
conduc
continuu
starea
actuală
spre
starea
dorită.
Nu

ar
trebui
să
conteze
cum
ajunge
ț
i
de
la
A
la
C.
Controlul
centralizat
nu
este,
de
asemenea,

necesar.
Acest
lucru
are
ca
rezultat
un
sistem
mai
u
ș
or
de
utilizat
ș
i
mai
puternic,
robust,

rezistent
ș
i extensibil.[15 ]

De ce containere

Modul
vechi
de
a
implementa
aplica
ț
ii
a
fost
prin
instalarea
aplica
ț
iilor
pe
o

gazdă(host)
utilizând
managerul
de
pachete
de
sisteme
de
operare.
Acest
lucru
a
avut

dezavantajul
implicării
executabilelor,
configura
ț
iilor,
bibliotecilor
ș
i
ciclurilor
de
via
ț
ă
ale

aplica
ț
iilor
între
ele
ș
i
cu
sistemul
de
operare
gazdă.
S-ar
putea
construi
imagini
imuabile
ale

ma
ș
inilor
virtuale
pentru
a
realiza
implementări
ș
i
revizuiri
previzibile,
dar
VM-urile
sunt

grele
ș
i non-portabile.

Noul
mod
este
de
a
implementa
containere
pe
baza
virtualizării
la
nivel
de
sistem
de

operare,
mai
degrabă
decât
virtualizare
hardware.
Aceste
containere
sunt
izolate
unul
de

celălalt
ș
i
de
gazdă:
au
propriile
sisteme
de
fi
ș
iere,
nu
pot
vedea
procesele
celorlal
ț
i
ș
i

utilizarea
resurselor
computa
ț
ionale
poate
fi
limitată.
Ele
sunt
mai
u
ș
or
de
construit
decât

VM-urile,
ș
i
deoarece
sunt
decuplate
de
infrastructura
de
bază
ș
i
de
sistemul
de
fi
ș
iere
gazdă,

acestea sunt portabile pe cloud
ș
i pe distribu
ț
ii de sisteme de operare.[15]

Deoarece
containerele
sunt
mici
ș
i
rapide,
o
aplica
ț
ie
poate
fi
ambalată
în
fiecare

imagine
a
containerului.
Această
rela
ț
ie
unu-la-unu
aplica
ț
ie-la-imagine
deblochează

beneficiile
pe
deplin
ale
containerelor.
Cu
containere,
imaginile
imuabile
ale
containerului

pot
fi
create
la
timpul
de
build/release
decât
la
timpul
de
lansare,
deoarece
fiecare
aplica
ț
ie
nu

trebuie
să
fie
compusă
împreună
cu
restul
aplica
ț
iilor
din
stiva
de
aplica
ț
ii,
nici
ata
ș
ată
cu

mediul
infrastructurii
de
produc
ț
ie.
Generarea
imaginilor
containerului
la
momentul

build-uirii/release-ului
permite
realizarea
unui
mediu
consistent
de
la
dezvoltare
în
produc
ț
ie.

În
mod
similar,
containerele
sunt
mult
mai
transparente
decât
VM-urile,
ceea
ce
facilitează

monitorizarea
ș
i
gestiona rea.
Acest
lucru
este
valabil
mai
ales
atunci
când
ciclurile
de
via
ț
ă

ale
procesului
de
recipiente
sunt
gestionate
de
infrastructură
decât
atunci
când
ascunse
de

către
un
supervizor
de
proces
în
interiorul
containerului.
În
sfâr
ș
it,
cu
o
singură
aplica
ț
ie
per

container,
gestionarea
containerelor
devine
echivalentă
cu
gestionarea
implementării

aplica
ț
iei.[16]

AWS

Amazon
Web
Services
(AWS)
este
o
filială
a
companiei
Amazon,
care
furnizează

platforme
de
cloud
computing
la
cerere
pentru
persoane
fizice,
companii
ș
i
guverne,
pe
bază

de
plată
măsurată.
În
ansamblu,
aceste
servicii
de
cloud
computing
oferă
un
set
de

infrastructuri
tehnice
primitive,
abstracte,
infrastructura
tehnică
abstractă,
blocuri
ș
i

instrumente
de
calcul
distribuite.
Unul
dintre
aceste
servicii
este
Amazon
Elastic
Compute

Cloud,
care
permite
utilizatorilor
să
aibă
la
dispozi
ț
ie
un
cluster
virtual
de
computere,

disponibil
tot
timpul,
prin
Internet.
Versiunea
AWS
a
computerelor
virtuale
emulează
cele

mai
multe
atribute
ale
unui
calculator
real,
inclusiv
hardware
(CPU
ș
i
GPU-uri
pentru

procesare,
memorie
locală
/
RAM,
hard
disk
/
SSD);
o
gamă
de
sisteme
de
operare;
re
ț
ele;
ș
i

programe de aplica
ț
ii pre -încărcate, cum ar fi servere web, baze de date, CRM etc.

Tehnologia
AWS
este
implementată
la
ferme
de
servere
din
întreaga
lume
ș
i
este

men
ț
inută
de
filiala
Ama zon.
Taxele
se
bazează
pe
o
combina
ț
ie
de
utilizare,
caracteristicile

hardware
/
OS
/
software
/
networking
alese
de
abonat,
op
ț
iunile
de
disponibilitate,

redundan
ț
ă,
securitate
ș
i
servicii
necesare.
Abona
ț
ii
pot
plăti
pentru
un
singur
computer

virtual
AWS,
un
calculator
fizic
dedicat
sau
clustere.
Ca
parte
a
contractului
de
abonament,

Amazon
asigură
securitatea
sistemului
abona
ț
ilor.
AWS
operează
din
mai
multe
regiuni

geografice globale, inclusiv 6 din America de Nord.

În
2017,
AWS
cuprindea
mai
mult
de
90
de
servicii
care
acoperă
o
gamă
largă
de

servicii
de
calcul,
stocare,
re
ț
ele,
baze
de
date,
analize,
servicii
de
aplica
ț
ii,
implementare,

gestionare,
instrumente
mobile,
instrumente
de
dezvoltare
ș
i
instrumente
pentru
Internetul

obiectelor.
Cele
mai
populare
includ
Amazon
Elastic
Compute
Cloud
(EC2)
ș
i
Amazon

Simple
Storage
Service
(Amazon
S3).
Cele
mai
multe
servicii
nu
sunt
expuse
direct

utilizatorilor,
ci
oferă
func
ț
ionalitate
prin
intermediul
API-urilor
pe
care
dezvoltatorii
le
pot

utiliza
în
aplica
ț
iile
lor.
Ofertele
serviciilor
Amazon
Web
Services
sunt
accesate
prin
HTTP,

folosind stilul arhitectural REST
ș
i protocolul SOAP.

Amazon
comercializează
AWS
abona
ț
ilor
ca
o
modalitate
de
a
ob
ț
ine
o
capacitate
de

calcul
pe
scară
largă
mai
rapidă
ș
i
mai
ieftină
decât
construirea
unei
ferme
de
server
fizic
real.

Toate
serviciile
sunt
facturate
în
func
ț
ie
de
utilizare,
dar
fiecare
serviciu
măsoară
utilizarea
în

diferite
moduri.
Începând
din
2017,
AWS
de
ț
ine
34%
din
totalul
cloudurilor(IaaS,
PaaS),
în

timp
ce
următorii
trei
concuren
ț
i
Microsoft,
Google
ș
i
IBM
au
11%,
8%,
respectiv
6%,

potrivit Synergy Group.[16]

De ce AWS

AWS
oferă
servicii
pentru
o
gamă
largă
de
aplica
ț
ii,
inclusiv
calcul,
stocare,
baze
de

date,
re
ț
ele,
analize,
învă
ț
are
automată
ș
i
inteligen
ț
ă
artificială
(AI),
Internet
de
obiecte
(IoT),

securitate, dezvoltarea, implementarea
ș
i gestionarea aplica
ț
iilor.

În
plus
fa
ț
ă
de
cea
mai
mare
varietate
de
servicii,
AWS
are
de
asemenea
cea
mai

profundă
func
ț
ionalitate
în
cadrul
acestor
servicii.
De
exemplu,
Amazon
EC2
oferă
mai
multe

tipuri
ș
i
dimensiuni
de
instan
ț
e
de
calcul
decât
orice
alt
furnizor ,
inclusiv
cele
mai
puternice

instan
ț
e
GPU
pentru
încărcările
de
învă
ț
are
ale
ma
ș
inilor.
AWS
are
de
asemenea
mai
mult

decât
dublul
numărului
de
servicii
de
bază
de
date
decât
oricine
altcineva,
cu
unsprezece

oferte
de
baze
de
date
rela
ț
ionale
ș
i
nerela
ț
ionale.
Ș
i,
AWS
are
cele
mai
multe
moduri
de
a

conduce
containere,
cu
Amazon
Elastic
Container
Service
(ECS),
Amazon
Elastic
Container

Service pentru Kubernetes (EKS)
ș
i AWS Fargate.

Această
gamă
largă
de
servicii
ș
i
func
ț
ionalitate
profund ă
fac
ca
migrarea
aplica
ț
iilor

existente
în
cloud
să
fie
mai
u
ș
oară,
mai
rapidă
ș
i
mai
eficientă
din
punct
de
vedere
al

costurilor
ș
i să construias că aproape orice vă pute
ț
i imagina.

In
plus,
AWS
a
fost
proiectat
pentru
a
fi
cel
mai
flexibil
ș
i
mai
sigur
mediu
pentru

cloud
computing
disponibil
astăzi.
Infrastructura
lui
centrală
fiind
construită
pentru
a

satisface
cerin
ț
ele
de
securitate
pentru
băncile
militare,
globale
ș
i
alte
organiza
ț
ii
cu
o
înaltă

sensibilitate.[16]

Amazon ECS

Amazon
ECS
este
un
serviciu
de
orchestrare
a
containerelor
extrem
de
scalabil,
care

sus
ț
ine
containerele
Docker
ș
i
vă
permite
să
rula
ț
i
ș
i
să
extinde
ț
i
cu
u
ș
urin
ț
ă
aplica
ț
iile

containerizate
pe
AWS.
Amazon
ECS
elimină
necesitatea
de
a
instala
ș
i
de
a
utiliza
propriul

software
de
orchestrare
a
containerelor,
de
a
gestiona
ș
i
de
a
scala
un
grup
de
ma
ș
ini
virtuale

sau de a programa containere pe aceste ma
ș
ini virtuale.

Cu
ajutorul
apelurilor
API
simple,
pute
ț
i
lansa
ș
i
opri
aplica
ț
iile
compatibile
cu

Docker,
interoga
starea
completă
a
aplica
ț
iei
dvs.
ș
i
accesa
multe
caracteristici
familiare,
cum

ar
fi
rolurile
IAM,
grupurile
de
securitate,
balansoarele
de
încărcare,
evenimentele

CloudWatch Events,
ș
abloanele AWS CloudFormation
ș
i logurile AWS CloudTrail.[17]

De ce Amazon ECS

Containere fără servere: oferă func
ț
ia AWS Fargate, astfel încât să pute
ț
i implementa

ș
i gestiona containerele fă ră a trebui să furniza
ț
i sau să administra
ț
i servere. Cu Fargate, nu

mai trebuie să selecta
ț
i tipurile de instan
ț
e Amazon EC2, furnizarea
ș
i scalarea grupurilor de

ma
ș
ini virtuale pentru a r ula containere sau a programa containerele pentru a rula pe grupuri

ș
i pentru a le men
ț
ine disponibilitatea. Fargate vă permite să vă co ncentra
ț
i asupra construirii

ș
i executării de aplica
ț
ii, nu asupra infrastructurii de bază.

Containerizează totul: vă permite să construi
ț
i cu u
ș
urin
ț
ă toate tipurile de aplica
ț
ii

containerizate, de la aplica
ț
ii de lungă durată
ș
i de la microservicii până la lucrări de loturi
ș
i

aplica
ț
ii de machine learn ing. Ave
ț
i posibilitatea să migra
ț
i aplica
ț
iile tradi
ț
ionale Linux sau

Windows din spa
ț
iul loca l către cloud
ș
i să le executa
ț
i ca aplica
ț
ii în containere utilizând

Amazon ECS.

Sigur: lansează containerele în propriul cont VPC Amazon, permi
ț
ându-vă să utiliza
ț
i

grupurile de securitate VPC
ș
i ACL-urile de re
ț
ea. Nici o resursă de calcul nu este distribuită

altor clien
ț
i. De asemenea , pute
ț
i atribui permisiuni de acces gran ular pentru fiecare dintre

containerele dvs. utilizând IAM pentru a restric
ț
iona accesul la fiecare serviciu
ș
i ce resurse

poate avea acces un container. Acest nivel ridicat de izolare vă ajută să utiliza
ț
i Amazon ECS

pentru a construi aplica
ț
ii foarte sigure
ș
i fiabile.

Performan
ț
a la sca ră: Amazon ECS este construit pe o tehnologie dezvoltată de mul
ț
i

ani de experien
ț
ă care rul ează servicii foarte scalabile. Pute
ț
i lansa zeci sau zeci de mii de

containere Docker în câteva secunde, utilizând Amazon ECS fără o complexitate

suplimentară.

AWS Integration: Amazon ECS este profund integrat cu serviciile AWS, incluzând

Elastic Load Balancing, Amazon VPC, AWS IAM, Amazon ECR, AWS Lot, Amazon

CloudWatch, AWS CloudFormation, AWS CodeStar
ș
i AWS CloudTrail. Aceasta vă oferă o

solu
ț
ie completă pentru c onstruirea
ș
i func
ț
ionarea unei game largi de aplica
ț
ii

containerizate.[17]

Prezentarea aplica
ț
iei

Inten
ț
ia

Aplica
ț
ia
dore
ș
te
să
pună
în
practică
puterea
unui
sistem
distribuit
de
calcul
în
cloud,

având
ca
scop
final
procesarea
tranzac
ț
iilor
de
pe
blockchain
cu
scopul
de
a
observa
anumite

caracteristici ale unei tranzac
ț
ii, cum ar fi:

–
De la ce utilizator vine tranzac
ț
ia

–
Către cine se îndreaptă tranzac
ț
ia

–
Dacă tranzac
ț
ia se îndreaptă către unul sau mai multi utilizatori

–
Suma totala care a fost tranzac
ț
ionată

–
Suma pe care o prime
ș
te fiecare utilizator din tranzac
ț
ie

Această
aplica
ț
ie
poate
fi
u
ș
or
modificată
astfel
încât
sa
facă
multe
calcule
mult
mai

puternice,
dar
nu
acesta
este
scopul
ei
final.
Aceasta
dore
ș
te
sa
pună
în
eviden
ț
ă
avansul

tehnologiei
din
zilele
noastre,
arătând
un
caz
particular
prin
procesarea
tranzac
ț
iilor
de
pe

blockchain.

Ob
ț
inerea datelor

Pentru
a
ob
ț
ine
date
de
pe
blockchain,
aplica
ț
ia
s-a
folosit
de
api-ul
pe
care

‘https://chain.api.btc.com/v3/’
îl
pune
la
dispozi
ț
ie.
Acesta
este
un
api
gratuit,
care
oferă

informa
ț
ii
despre
o
tranzac
ț
ie
în
timp
real,
urmând
ca
în
cod
să
putem
executa
anumite

verificări
asupra
tranzac
ț
iei,
cum
ar
fi
numărul
confirmărilor
sau
dacă
aceasta
este
o

tranzac
ț
ie de tip ‘NONST ANDARD’, tranzac
ț
ie invalidă intre doi utilizatori.

Cursul aplica
ț
iei

In
această
itera
ț
ie
a
aplica
ț
iei,
avem
un
singur
publisher
care
poate
pune
pe
coada
un

număr
de
tranzac
ț
ii
ales
aleator.
Pentru
a
demonstra
scopul
aplica
ț
iei,
acest
număr
încearcă
sa

fie
cat
mai
mare,
astfel
încât
Kubernetes-ul
integrat
sa
poată
crea
multiple
instante
ale
unei

ma
ș
ini
pentru
a
calcula
rezultatul
final.
Astfel,
overclockuind
procesorul,
ajungând
la
un

procentaj
dorit
din
CPU,
Kubernetes
va
instantia
o
noua
ma
ș
ină
virtuala,
care,
la
deschidere,

va fi ghidata sa execute task-ul dorit.

Publisherul
pune
un
mesaj
de
tip
JSON
pe
coada
special
construita
pentru
acest
lucru,

urmând
ca
RabbitMQ-ul
să
a
ș
eze
mesajul
pe
coadă.
Explicat
mai
sus,
RabbitMQ
este
doar
un

broker
de
mesaje,
fiind
calea
de
mijloc
către
publisher
ș
i
consumer,
cei
doi
neavând
vreo

conexiune
reciprocă.
Astfel,
fiind
pe
două
servere
diferite,
nimeni
nu
ș
tie
de
existen
ț
a

celuilalt, comunicarea făcându-se prin coada descrisa anterior.

Consumerul
are
rolul
de
a
lua
mesajul
de
pe
coadă
spre
a
fi
procesat
ulterior.
Acesta

nu
doar
că
face
posibila
ob
ț
inerea
datelor
despre
tranzac
ț
iile
finale,
dar
le
ș
i
stochează
într-o

baza
de
date
construită
special
pentru
acest
task.
De
asemenea,
consumerul
are
rolul
de
a

trimite înapoi către coadă un mesaj cu un flag setat true, arătând că mesajul a fost recep
ț
ionat.

Ce
este
interesant
la
aceasta
aplica
ț
ie
este
faptul
că
putem
avea
unul
sau
mai
multi

consumeri,
independen
ț
i
unul
de
celalalt,
genera
ț
i
de
Kubernetes.
Practic,
prin
crearea
în

cloud a multiplilor consumeri punem în evidentă scopul aplica
ț
iei.

Kubernetes

Partea
de
Kubernetes
are
rolul
de
a
distribui
ma
ș
inile
într-un
mod
cat
mai
organic,
cu

un
fi
ș
ier
de
configurare
prestabilit
care
controlează
atât
starea
ma
ș
inilor
cat
ș
i
func
ț
ionalitatea

acestora.
Astfel,
dintr-un
singur
fi
ș
ier
de
configurare,
multiple
ma
ș
ini
au
task-uri
predefinite

ș
i nu au nevoie de un pro gramator pentru func
ț
ionarea fiecăreia.

In
imaginea
de
mai
sus
putem
observa
definirea
unui
ECS
cu
Kubernetes,
care
este

certificat
printr-un

Certificate
authority
auto-generat.
In
prima
parte
putem
observa
tipul

clusterului
(

eks.2,

versiunea
a
2-a
a
ECS-ului
ce
include
Kubernetes
de
la
Amazon)
ș
i

versiunea
de
Kubernetes
folosita.

Cluster
ARN
ș
i

Role
ARN

,
ARN
reprezentând
Amazon

Resource
Name,
numele
resurselor.
Despre
Role
ARN
vom
explica
mai
multe
în
păr
ț
ile

următoare.

Aceasta
imagine
ne
prezintă
ma
ș
inile
virtuale
ce
rulează
sub
supravegherea

Kubernetes.
Aceste
VM-uri
sunt
în
cloud-ul
de
ț
inut
de
către
Amazon
ș
i
sunt
generate
dintr-un

script
de
configurare
pentru
a
armoniza
procesul.
Toate
aceste
ma
ș
ini
sunt
instantiate
de

Kubernetes din fi
ș
ierul de configurare, având fiecare cate un grup de securitate auto-generat.

De
asemenea,
foarte
important,
pentru
buna
folosin
ț
a
a
ma
ș
inilor,
este
necesar
un

Logger
ce
semnalează
eventualele
erori
ale
ma
ș
inilor.
Astfel,
pe
aceasta
cale,
folosim

loggerul
CloudWatch,
de
la
Amazon,
un
logger
gratuit
care
func
ț
ionează
în
paralel
cu

Clusterul ECS,
ț
inând evi denta evenimentelor din fiecare ma
ș
ină.

In
imaginea
de
mai
sus
reamintim
de
Role
ARN
(Amazon
Resource
Name)
ș
i

func
ț
ionalitatea
acestuia.
In
linii
mari,
rolul
descris
este
cel
de
management
al
clusterelor
pe

care
le
vom
crea.
Prin
crearea
rolului
SuperAdmin
(găsit
în
prima
imagine,
ca
fiind

denumirea
Role
ARN),
ii
acordam
Kubernetes-ului
permisiunile
necesare
pentru
a
putea

accesa
ș
i
controla
fiecare
ma
ș
ină
în
parte,
fiind
capabil
chiar
ș
i
de
instan
ț
ierea
acestora
(fapt

ce ne ajuta la demonstrarea cazului final).

Masini virtuale

In
acest
screen
putem
observa
3
ma
ș
ini
de
acela
ș
i
tip
instantiate
de
către
Kubernetes.

Prin
configurarea
Kubernetesului
am
reu
ș
it
sa
instantiem
3
ma
ș
ini,
fiecare
ma
ș
ină
rulând

scriptul
de
consumer.
Astfel,
fiecare
dintre
acestea,
având
o
capacitate
mica,
ajung
rapid
la

overclocking,
iar
Kubernetes
reu
ș
e
ș
te
cu
succes
sa
divizeze
aceasta
problema,
introducând
o

noua instanta de ma
ș
ină (pute vedea ca toate ma
ș
inile sunt de tipul

t2.micro

).

Mai
sus
putem
observa
detaliile
unui
consumer,
un
proces
care
rulează
scriptul
de

care
vom
aminti
ulterior.
In
specifica
ț
iile
ma
ș
inii
putem
observa
fieldurile

Instance
state

,

Owner,
Launch
time,
IPv4
Public
IP

ș
i

Lifecycle,

fielduri
care
ne
descriu
starea
ma
ș
inii
ș
i

anumite
informa
ț
ii
pe
care,
la
o
aplica
ț
ie
de
propor
ț
ii,
le
putem
configura
în
vederea

optimizării.

Producer

Partea de producer poate fi divizata în două păr
ț
i, fiecare executând cate un task.

In această secventă de cod se poate observa următorul curs al lucrurilor:

–
prin
sintaxa

$client->request(‘GET’,$uri)
ob
ț
inem
informa
ț
ii
de
la
api-ul
oferit
de

CoinBase legate de wallet-ul utilizatorului.

–
prin

$explorer->getTx()

ob
ț
inem
prima
tranzac
ț
ie
a
utilizatorului,
necesară
pentru
a

ne oferi detalii despre blocul din care putem lua următoarele tranzac
ț
ii

–
prin

$explorer->getTxReceived()
ob
ț
inem
informa
ț
ii
despre
anumite
tranzac
ț
ii,
func
ț
ie

pe care o vom discuta ulterior.

–
verificam
dacă
fiecare
tranzac
ț
ie
respecta
anumite
reguli
prin

array_walk($transactions, functie anonima)

–
dacă
totul
este
bine,
publicam
mesajul
pe
coadă,
prin
func
ț
ia

$this->getContainer()->get(“$rabbitCfg.$serv”)->publish($serialized)

,
după
ce

serializam
obiectul
primit
in
functia

$this->serializeTx()

,
pentru
a
ajunge
la
formatul

pe care consumerul îl acceptă

Func
ț
iile de lucru cu api-ul CoinBase

Această
func
ț
ie
este
apelată
de
către
publisher
ș
i
are
rolul
de
a
aduce
cate
o
tranzac
ț
ie

de
pe
blockchain
cu
scopul
de
a
fi
pusă
pe
coadă
pentru
procesarea
datelor.
Astfel,
apelăm

api-ul
pus
la
dispozi
ț
ie
de
către
CoinBase
pentru
a
lua
toate
tranzac
ț
iile
dintr-un
bloc
de

tranzac
ț
ii,
prin
func
ț
ia

$client->request(‘GET’,$uri),

după
care
prelucrăm
datele
convenabil,

formând obiecte de tipul

$tx

care au scopul de a retine informa
ț
ii despre o tranzac
ț
ie.

In
această
parte
de
cod
executăm
un
request
către
api-ul
CoinBase
prin

$client->request(‘GET’, $uri)

pentru a ob
ț
ine prima tranzac
ț
ie realizata de care avem nevoie.

Consumer

Partea de consumer o putem diviza în 3 sub-păr
ț
i, fiecare executând cate un task.

Index

Această
parte
reprezintă
indexul
aplica
ț
iei,
punctul
de
plecare
al
acesteia,
ce

ini
ț
ializează
consumerul
ș
i
îl
îndrumă
sa
ruleze.
Aici
sunt
definite
o
serie
de
constante
ce

servesc
ca
ș
i
instruc
ț
iuni
de
configurare.
Astfel,
prin
constan ta

service
ii
este
aten
ț
ionat

codului
asupra
tipului
serviciului
pe
care
îl
vom
folosi
(în
acest
caz
RabbitMQ
rulând
local).

Constanta

queue
ii
sugerează
codului
coada
de
pe
care
acesta
va
lua
mesajul,
iar
a
treia

constanta
este
prioritatea
cu
care
acesta
va
lua
codul
(neimportantă,
deoarece
to
ț
i
consumerii

vor avea aceea
ș
i versiune a codului).

Ini
ț
ializarea legăturii cu coada

In
această
secventă
de
cod
se
poate
observa
conexiunea
cu
serverul
RabbitMQ
ș
i
mai

apoi
conexiunea
la
coada
propriu-zisă.
In
primă
fază,
încercam
conexiunea
la
RabbitMQ
prin

instruc
ț
iunea

amqp.conn ect()

,
a
ș
teptând
stabilirea
conexiunii
la
server.
In
cadrul
func
ț
iei

anonime
apelate
ca
si
parametru
al
func
ț
iei

connect()
se
încearcă
stabilirea
conexiunii
la

coada
propriu-zisă,
de
pe
care
vom
citi
mesajele.
Astfel,
se
crează
un
canal
cu
func
ț
ia

conn.createChannel()

,
iar
în
cadrul
func
ț
iei
anonime
date
ca
ș
i
parametru
încercăm
sa

stabilim
legătura
cu
coada
dorită,
prin
func
ț
ia

ch.assertQueue()

.
Fiind
conecta
ț
i,
această

conexiune se men
ț
ine, ne maiavând nevoie de un apel ulterior al func
ț
iei.

Procesarea mesajului

După
stabilirea
conexiunii
cu
coada
dorită,
nu
ne
mai
rămâne
decât
sa
procesam

mesajul
pe
care
îl
vom
lua
de
pe
coada.
Astfel,
func
ț
ia

Queue.channel.consume()
va
lua
un

mesaj
de
pe
coadă
pentru
a
fi
procesat
de
către
func
ț
ia

processTransaction()

pe
care
o
vom

discuta
ulterior.
Dacă
mesajul
este
procesat
cu
succes,
se
trimite
înapoi
către
coadă
flagul
true

(

Queue.channel.ack()

) men
ț
ionat anterior. Altfel, este trimis un flag false.

Managementul proceselor

Figura de mai sus prezintă pornirea unui singur proces ce are numele de

worker01.

Pentru
ca
mai
multe
ma
ș
ini
să
poată
fi
deschise
simultan,
acestea
ar
trebui
să
aibă
un

script
ce
porne
ș
te
la
instan
ț
ierea
ma
ș
inii,
deoarece
nu
este
viabil
pentru
un
programator
să

pornească
singur
procesele,
chiar
dacă
Kubernetes
a
instantiat
ma
ș
ina
respectivă.
Astfel,

fiecare
instanta
a
ma
ș
inii
are
un
script
în
tagul
@REBOOT,
ce
o
îndrumă
sa
pornească

procesul
consumerului.
Dar
pentru
a
procesul
sa
poată
fi
activ
mereu,
pe
parcursul
vie
ț
ii

ma
ș
inii,
acesta
ar
trebui
să
fie
controlat
de
un
manager
de
pachete.
Aici
intervine
PM2,
care

tine
procesul
sus
pana
la
oprirea
acestuia
sau
pana
la
apari
ț
ia
unei
erori.
Imaginea
anterioară

ne
arată
mai
multe
atribute
ale
unui
proces,
printre
care
ș
i

status
–
ne
indică
faptul
că
procesul

este activ sau nu,

mem

– memoria utilizată de proces
ș
i

user

– userul ce a pornit procesul.

Concluzii

În
această
lucrare
s-au
pus
în
evidenta
numeroase
tehnologii
din
domeniul
IT
care
sunt

în
continua
dezvoltare.
Încât.
în
2019,
companiile
IT
sunt
în
continua
cre
ș
tere,
apare
o

necesitate
în
dezvoltarea
capacită
ț
ilor
de
calcul
ș
i
de
stocare
a
datelor.
In
ajutor
vin
noile

tehnologii
ce
se
bazează
pe
cloud,
un
mediu
separat
de
dezvoltare
ce
nu
cunoa
ș
te
limitări
în

materie de putere computa
ț
ională.

Totodată,
s-au
pus
în
lumină
avantajele
tehnologiilor
care
au
fost
alese
să
se
afle
în

constitu
ț
ia
aplica
ț
iei,
tehnologii
de
ultimă
oră,
care
se
află
la
grani
ț
a
noului
în
industrie.
Prin

aceasta
aplica
ț
ie
am
încercat
sa
îmbin
diverse
tehnologii
ce
prind
deja
teren
în
compara
ț
ie
cu

vechile
obiceiuri,
cum
ar
fi
procesele
de
a
ș
teptare
a
unui
răspuns
sau
folosirea
computa
ț
ională

proprie.

De
asemenea,
în
aceasta
lucrare
am
descris
anumite
concepte
teoretice
folosite,

concepte
care
de
asemenea
sunt
preferate
în
zilele
noastre
în
tehnologii.
Ideile
folosite

reprezinta
viitorul
în
materie
de
dezvoltare
pe
partea
de
software,
întrucât
reu
ș
esc
sa
fie
cat

mai descentralizate
ș
i independente de programator.

În
urma
acestui
proiect,
am
învă
ț
at
despre
importanta
puterii
computa
ț
ionale
ș
i
cat
de

ajutătoare
este
în
situa
ț
iile
unui
proiect
de
propor
ț
ii,
despre
distribuirea
resurselor
unui
întreg,

dar
ș
i
despre
formarea
unui
întreg
din
păr
ț
i,
prin
multiple
ma
ș
inării
interconectate
în
cloud.

Într-un
final,
aplica
ț
ia
prezentata
reprezintă
produsul
îmbinării
mai
multor
tehnologii
de

ultimă
oră
cu
scopul
de
a
demonstra
diferen
ț
ele
dintre
un
singur
sistem,
respectiv
un
sistem

centralizat de computare.

Bibliografie

1.
https://www.univie.ac.at/ct/stefan/dagrep_v005_i002_p064_s15072.pdf

2.
https://mindmajix.com/cloud-computing-vs-distributed-computing

3.
https://searchitoperations.techtarget.com/definition/distributed-cloud

4.
https://en.wikipedia.org/wiki/Distributed_computing

5.
https://en.wikipedia.org/wiki/Cloud_computing

6.
https://azure.microsoft.com/en-us/overview/what-is-cloud-computing/

7.
https://en.wikipedia.org/wiki/Message_queue

8.
https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern

9.
https://docs.microsoft.com/en-us/azure/architecture/patterns/publisher-subscriber

10.
https://en.wikipedia.org/wiki/Blockchain

11.
https://nodejs.org/en/docs/

12.
https://en.wikipedia.org/wiki/Node.js

13.
https://en.wikipedia.org/wiki/RabbitMQ

14.
https://www.rabbitmq.com/documentation.html

15.
https://kubernetes.io/docs/home/

16.
https://aws.amazon.com/what-is-aws/

17.
https://aws.amazon.com/ecs/

Copyright Notice

© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.

Acest articol: UNIVERSITATEA BUCURE Ș TI FACULTATEA DE MATEMATICĂ Ș I INFORMATICĂ Specializarea Informatică LUCRARE DE LICEN Ț Ă [631586] (ID: 631586)

Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.

UNIVERSITATEA BUCURE Ș TI FACULTATEA DE MATEMATICĂ Ș I INFORMATICĂ Specializarea Informatică LUCRARE DE LICEN Ț Ă [631586]

Copyright Notice

Managementul proiect elor tehnice în industria portuară . Studiu de [610781]

Să rezolvăm probleme ilustrate. Etapele metodei: [623054]

Evaluarea factorilor de risc la pacienții cu boală inflamatorie [630304]

LUCRARE METODICO-ȘTIINȚIFICĂ PENTRU OBȚINEREA GRADULUI DIDACTIC I [310356]

CUPRINS ………………………….. ………………………….. ………………………….. …………………………….. [612933]

STUDIU PRIVIND MANAGEMENTUL ECHIPELOR DE MUNCA A [607875]

Copyright Notice

Similar Posts