{"id":79498,"date":"2020-04-27T19:42:07","date_gmt":"2020-04-27T17:42:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat"},"modified":"2020-04-27T19:42:07","modified_gmt":"2020-04-27T17:42:07","slug":"mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","title":{"rendered":"Microservicii: ce sunt, de ce sunt necesare \u0219i c\u00e2nd ar trebui implementate","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Am dorit s\u0103 scriu de mult\u0103 vreme un articol despre arhitectura microserviciilor, \u00eens\u0103 de fiecare dat\u0103 m-au oprit dou\u0103 lucruri: cu c\u00e2t m\u0103 ad\u00e2nceam mai mult \u00een subiect, cu at\u00e2t mai mult mi se p\u0103rea c\u0103 ceea ce \u0219tiu este evident, iar ceea ce nu \u0219tiu necesita \u00eenc\u0103 mult\u0103 studiere. Pe de alt\u0103 parte, consider c\u0103 deja exist\u0103 suficiente lucruri de discutat pentru o audien\u021b\u0103 mai larg\u0103. A\u0219adar, sunt binevenite opiniile alternative.
\n<\/a><\/noindex><\/p>\n

Legea lui Conway \u0219i leg\u0103tura dintre afacere, organiza\u021bie \u0219i sistemul informa\u021bional<\/h2>\n

\n\u00cemi permit din nou s\u0103 citez:<\/p>\n

\u201eOrice organiza\u021bie care proiecteaz\u0103 un sistem (\u00een sens larg) va ob\u021bine un design al c\u0103rei structur\u0103 copiaz\u0103 structura echipelor din acea organiza\u021bie\u201d
\n\u2014 Melvyn Conway, 1967\n<\/p><\/blockquote>\n

\u00cen opinia mea, aceast\u0103 lege este mai degrab\u0103 legat\u0103 de viabilitatea unei organiza\u021bii de afaceri, dec\u00e2t direct de sistemul informa\u021bional. O s\u0103 explic printr-un exemplu. S\u0103 presupunem c\u0103 avem o oportunitate de afaceri destul de stabil\u0103, cu un ciclu de via\u021b\u0103 suficient de lung \u00eenc\u00e2t s\u0103 aib\u0103 sens s\u0103 organiz\u0103m o \u00eentreprindere (nu este o gre\u0219eal\u0103 de tipar, dar \u00eemi place foarte mult acest termen pe care l-am preluat). Desigur, sistemul care sus\u021bine aceast\u0103 afacere va corespunde organiza\u021bional \u0219i procesual acestui tip de afacere.<\/p>\n

Orientarea \u00een afaceri a sistemelor informa\u021bionale<\/h2>\n

\n\"Microservicii:
\n
\nO s\u0103 explic printr-un exemplu. S\u0103 consider\u0103m o oportunitate de afaceri pentru organizarea unei afaceri de v\u00e2nzare de pizza. \u00cen versiunea V1 (s\u0103 o numim pre-informa\u021bional\u0103), compania reprezenta o pizzerie, o cas\u0103 de marcat, un serviciu de livrare. Aceast\u0103 versiune a fost de lung\u0103 durat\u0103 \u00een condi\u021bii de mic\u0103 volatilitate a mediului \u00eenconjur\u0103tor. Apoi a venit versiunea 2 \u2014 mai avansat\u0103 \u0219i capabil\u0103 s\u0103 utilizeze un sistem informa\u021bional ca baz\u0103 pentru afacere cu o arhitectur\u0103 monolitic\u0103. \u0218i aici, \u00een opinia mea, apare o nejustificat\u0103 nedreptate fa\u021b\u0103 de monolite \u2014 se spune c\u0103 arhitectura monolitic\u0103 nu corespunde modelului domenial al afacerii<\/b>. Dac\u0103 ar fi a\u0219a, sistemul nu ar putea func\u021biona deloc - contrar acelea\u0219i legi a lui Conway \u0219i bunului sim\u021b. Nu, arhitectura monolitic\u0103 se aliniaz\u0103 pe deplin modelului de afaceri \u00een aceast\u0103 etap\u0103 de dezvoltare a afacerii - m\u0103 refer, desigur, la etapa \u00een care sistemul a fost deja creat \u0219i pus \u00een func\u021biune. Un fapt absolut remarcabil este c\u0103, indiferent de abordarea arhitectural\u0103, at\u00e2t arhitectura orientat\u0103 pe servicii versiunea 3, c\u00e2t \u0219i arhitectura pe microservicii versiunea N vor func\u021biona la fel de bine. Care este capcana?<\/p>\n

Totul curge, totul se schimb\u0103 sau microserviciile sunt un instrument de combatere a complexit\u0103\u021bii?<\/h2>\n

\n \u00cenainte de a continua, s\u0103 analiz\u0103m c\u00e2teva concep\u021bii gre\u0219ite legate de arhitectura microserviciilor.<\/p>\n

Suporterii utiliz\u0103rii abord\u0103rii microserviciilor spun adesea c\u0103 deschiderea monolitului \u00een microservicii simplific\u0103 procesul de dezvoltare prin reducerea bazei de cod a fiec\u0103rui serviciu. Din punctul meu de vedere, aceast\u0103 afirma\u021bie este pur \u0219i simplu absurd\u0103. Serios, interac\u021biunea evident\u0103 \u00een cadrul monolitului \u0219i a codului omogen pare complicat\u0103? Dac\u0103 ar fi fost cu adev\u0103rat a\u0219a, toate proiectele ar fi fost ini\u021bial construite ca microservicii, \u00een timp ce practica arat\u0103 c\u0103 migrarea din monolit \u00een microservicii este cu mult mai frecvent\u0103. Complexitatea nu dispare, ea se transfer\u0103 pur \u0219i simplu din module individuale \u00een interfe\u021be (fie c\u0103 sunt magistrale de date, RPC, API \u0219i alte protocoale) \u0219i sisteme de orchestrare. \u0218i asta este complicat! <\/p>\n

Avantajul utiliz\u0103rii unui stoc heterogen este, de asemenea, discutabil. Nu voi contesta c\u0103 este posibil, dar \u00een realitate este rar \u00eent\u00e2lnit (Ca o anticipare - ar trebui s\u0103 existe - dar mai degrab\u0103 ca un rezultat, dec\u00e2t ca un avantaj).<\/p>\n

Ciclul de via\u021b\u0103 al produsului \u0219i ciclul de via\u021b\u0103 al serviciului<\/h2>\n

\nUita\u021bi-v\u0103 din nou la diagrama de mai sus. Nu am eviden\u021biat \u00eent\u00e2mpl\u0103tor ciclul de via\u021b\u0103 \u00een sc\u0103dere al fiec\u0103rei versiuni a afacerii - \u00een condi\u021biile actuale, accelerarea trecerii afacerii \u00eentre versiuni este determinant\u0103 pentru succesul acesteia. Succesul produsului este definit de viteza de testare a ipotezelor de afaceri \u00een acesta<\/b>. \u0218i aici, din punctul meu de vedere, se afl\u0103 cheia avantajului principal al arhitecturii microserviciilor. Dar s\u0103 o lu\u0103m pe r\u00e2nd. <\/p>\n

S\u0103 trecem la urm\u0103torul nivel de evolu\u021bie a sistemelor informa\u021bionale \u2014 arhitectura orientat\u0103 pe servicii SOA. A\u0219adar, la un moment dat, am diferen\u021biat \u00een produsul nostru servicii durabile<\/b> \u2014 durabile \u00een sensul c\u0103, atunci c\u00e2nd trecem \u00eentre versiunile produsului, exist\u0103 \u0219anse ca ciclul de via\u021b\u0103 al serviciului s\u0103 fie mai lung dec\u00e2t ciclul de via\u021b\u0103 al unei noi versiuni a produsului. Ar fi logic s\u0103 nu le schimb\u0103m deloc \u2014 pentru noi este important\u0103 rapiditatea cu care trecem la urm\u0103toarea versiune<\/b>. Dar din p\u0103cate, suntem nevoi\u021bi s\u0103 facem modific\u0103ri constante \u00een servicii \u2014 \u0219i aici se potrivesc toate, de la practici DevOps, la containerizare, \u0219i altele \u2014 tot ce \u00ee\u021bi vine \u00een minte. Dar asta nu sunt \u00eenc\u0103 microservicii! <\/p>\n

Microserviciile ca mijloc de a combate complexitatea\u2026 gestionarea configura\u021biei<\/h2>\n

\n \u0218i aici putem, \u00een sf\u00e2r\u0219it, s\u0103 ajungem la rolul definitoriu al microserviciilor \u2014 acesta este un mod de a simplifica gestionarea configura\u021biei produsului. Mai exact, func\u021bia fiec\u0103rui microserviciu descrie o func\u021bie de afaceri \u00een cadrul produsului conform modelului de domeniu \u2014 iar acestea sunt lucruri care nu exist\u0103 \u00een versiuni de scurt\u0103 durat\u0103, ci \u00een oportunit\u0103\u021bi de afaceri de lung\u0103 durat\u0103. \u0218i trecerea la urm\u0103toarea versiune a produsului se \u00eent\u00e2mpl\u0103, \u00een mod literal, f\u0103r\u0103 a fi observat\u0103 \u2014 schimbi\/adaugi un microserviciu, iar poate doar schema interac\u021biunii lor \u0219i, dintr-o dat\u0103, te reg\u0103se\u0219ti \u00een viitor, l\u0103s\u00e2nd \u00een urm\u0103 concuren\u021bii pl\u00e2ng\u00e2nd care continu\u0103 s\u0103 sar\u0103 \u00eentre versiunile monolitilor lor. Acum imagineaz\u0103-\u021bi c\u0103 ai un volum suficient de mare de microservicii cu interfete \u0219i oportunit\u0103\u021bi de afaceri clar definite. \u0218i vii \u0219i construie\u0219ti structura produsului t\u0103u din microservicii gata f\u0103cute \u2014 doar desen\u00e2nd un diagram\u0103, de exemplu. Felicit\u0103ri \u2014 ai o platform\u0103 \u2014 \u0219i acum po\u021bi s\u0103 \u00ee\u021bi implementezi afacerea. Visuri, visuri. <\/p>\n

Conclusions<\/h2>\n

<\/p>\n