Îmi doream de mult să scriu un articol pe tema arhitecturii microserviciilor, dar două lucruri m-au tot oprit - cu cât mă afundam mai mult în subiect, cu atât mi se părea că ceea ce știu este evident și ceea ce știu. nu știu că trebuie studiat și studiat. Pe de altă parte, cred că există deja ceva de discutat în rândul unui public larg. Deci, opiniile alternative sunt binevenite.
Legea lui Conway și relația dintre afaceri, organizație și sistemul informațional
Încă o dată îmi voi permite să citez:
„Orice organizație care proiectează un sistem (în sens larg) va primi un design a cărui structură reproduce structura echipelor din acea organizație.”
— Melvyn Conway, 1967
În opinia mea, această lege este mai probabil să se refere la fezabilitatea organizării unei afaceri, decât direct la sistemul informațional. Să explic cu un exemplu. Să presupunem că avem o oportunitate de afaceri destul de stabilă, cu un ciclu de viață atât de lung încât are sens să organizezi o întreprindere (aceasta nu este o greșeală de tipar, dar îmi place foarte mult acest termen pe care l-am furat). Desigur, sistemul de sprijin al acestei afaceri va corespunde din punct de vedere organizatoric și procesual acestei afaceri.
Orientarea spre afaceri a sistemelor informatice
Să explic cu un exemplu. Să presupunem că există o oportunitate de afaceri pentru a organiza o afacere de vânzare de pizza. În versiunea V1 (să-i spunem preinformare), compania era o pizzerie, o casă de marcat și un serviciu de livrare. Această versiune a fost de lungă durată în condiții de variabilitate scăzută a mediului. Apoi a venit versiunea 2 să-l înlocuiască - mai avansată și capabilă să folosească un sistem informațional în centrul său pentru afaceri cu o arhitectură monolitică. Și aici, în opinia mea, există pur și simplu o nedreptate teribilă în raport cu monoliții - presupusa arhitectură monolitică nu corespunde modelului de afaceri al domeniului. Da, dacă ar fi așa, sistemul nu ar putea funcționa deloc - în contradicție cu aceeași lege și bunul simț a lui Conway. Nu, arhitectura monolitică este pe deplin în concordanță cu modelul de afaceri în această etapă de dezvoltare a afacerii - mă refer, desigur, la etapa în care sistemul a fost deja creat și pus în funcțiune. Este un fapt absolut minunat că, indiferent de abordarea arhitecturală, atât versiunea 3 a arhitecturii orientate către servicii, cât și versiunea N de arhitectură de microservicii vor funcționa la fel de bine. Care e siretlicul?
Totul curge, totul se schimbă sau sunt microserviciile un mijloc de a combate complexitatea?
Înainte de a continua, să ne uităm la câteva concepții greșite despre arhitectura de microservicii.
Susținătorii utilizării unei abordări cu microservicii susțin adesea că împărțirea unui monolit în microservicii simplifică abordarea de dezvoltare prin reducerea bazei de cod a serviciilor individuale. După părerea mea, această afirmație este o prostie totală. Serios, interacțiunea evidentă în cadrul unui cod monolit și omogen pare complicată? Dacă acesta ar fi într-adevăr cazul, toate proiectele ar fi inițial construite ca microservicii, în timp ce practica arată că migrarea de la un monolit la microservicii este mult mai comună. Complexitatea nu dispare; pur și simplu trece de la module individuale la interfețe (fie că este vorba de magistrale de date, RPC, API-uri și alte protocoale) și sisteme de orchestrare. Și asta este greu!
Avantajul utilizării unei stive eterogene este, de asemenea, discutabil. Nu voi argumenta că și acest lucru este posibil, dar în realitate se întâmplă rar (Privind în viitor - acest lucru ar trebui să se întâmple - ci mai degrabă ca o consecință decât ca un avantaj).
Ciclul de viață al produsului și ciclul de viață al serviciului
Aruncă o altă privire la diagrama de mai sus. Nu întâmplător am observat scăderea ciclului de viață al unei versiuni separate a unei afaceri - în condiții moderne, accelerarea tranziției unei afaceri între versiuni este decisivă pentru succesul acesteia. Succesul unui produs este determinat de viteza de testare a ipotezelor de afaceri din acesta. Și aici, în opinia mea, constă avantajul cheie al arhitecturii microservicii. Dar să mergem în ordine.
Să trecem la următoarea etapă în evoluția sistemelor informaționale - la arhitectura SOA orientată spre servicii. Deci, la un anumit moment, am evidențiat în produsul nostru servicii de lungă durată - de lungă durată, în sensul că atunci când se deplasează între versiunile unui produs, există șansa ca ciclul de viață al serviciului să fie mai lung decât ciclul de viață al următoarei versiuni a produsului. Ar fi logic să nu le schimbăm deloc – noi Ceea ce contează este viteza de tranziție la următoarea versiune. Dar, din păcate, suntem forțați să facem schimbări constante la servicii - și aici totul funcționează pentru noi, practicile DevOps, containerizarea și așa mai departe - tot ce ne vine în minte. Dar acestea încă nu sunt microservicii!
Microservicii ca mijloc de combatere a complexității... managementul configurației
Și aici putem trece în sfârșit la rolul definitoriu al microserviciilor - aceasta este o abordare care simplifică gestionarea configurației produselor. Mai detaliat, funcția fiecărui microserviciu descrie exact funcția de business din interiorul produsului conform modelului de domeniu - și acestea sunt lucruri care trăiesc nu într-o versiune de scurtă durată, ci într-o oportunitate de afaceri de lungă durată. Iar tranziția la următoarea versiune a produsului se întâmplă literalmente neobservată - schimbi/adaugi un microserviciu și poate doar schema interacțiunii lor și, brusc, te trezești în viitor, lăsând în urmă concurenți plângători care continuă să sară între versiuni de monoliții lor. Acum imaginați-vă că există un volum destul de mare de microservicii cu interfețe predefinite și capabilități de afaceri. Și vii și construiești structura produsului tău din microservicii gata făcute - pur și simplu desenând o diagramă, de exemplu. Felicitări - ai o platformă - și acum poți atrage afaceri pentru tine. Visuri Visuri.
Constatări
- Arhitectura sistemului ar trebui să fie determinată de ciclul de viață al componentelor sale. Dacă o componentă se află într-o versiune de produs, nu are rost să creștem complexitatea sistemului prin utilizarea unei abordări cu microservicii.
- Arhitectura de microservicii ar trebui să se bazeze pe modelul domeniului - deoarece oportunitatea de afaceri este domeniul cu cea mai lungă viață
- Practicile de livrare (practicile DevOps) și orchestrarea sunt una dintre cele mai importante pentru arhitectura de microservicii - pentru că creșterea ratei de schimbare a componentelor impune cerințe sporite asupra vitezei și calității livrării.
Sursa: www.habr.com