Feia temps que volia escriure un article sobre el tema de l'arquitectura de microserveis, però dues coses m'aturaven: com més m'endinsava en el tema, més em semblava que el que sé és obvi i el que sé. no sé s'ha d'estudiar i estudiar. D'altra banda, crec que ja hi ha alguna cosa a parlar entre un públic ampli. Per tant, les opinions alternatives són benvingudes.
La Llei de Conway i la relació entre negoci, organització i sistema d'informació
Permeteu-me citar una vegada més:
"Qualsevol organització que dissenyi un sistema (en sentit ampli) rebrà un disseny l'estructura del qual replica l'estructura dels equips d'aquesta organització".
— Melvyn Conway, 1967
Al meu entendre, és més probable que aquesta llei es relacioni amb la viabilitat d'organitzar un negoci, que no pas directament amb el sistema d'informació. Deixa'm explicar-ho amb un exemple. Diguem que tenim una oportunitat de negoci bastant estable amb un cicle de vida tan llarg que té sentit organitzar una empresa (no és una errada d'ortografia, però m'agrada molt aquest terme que he robat, naturalment, el sistema de suport d'aquest negoci). correspondrà organitzativament i processalment a aquest negoci.
Orientació empresarial dels sistemes d'informació
Deixa'm explicar-ho amb un exemple. Diguem que hi ha una oportunitat de negoci per organitzar un negoci de venda de pizza. A la versió V1 (diguem-ne preinformació), l'empresa era una pizzeria, una caixa registradora i un servei de lliurament. Aquesta versió va tenir una llarga vida en condicions de baixa variabilitat ambiental. Llavors va venir la versió 2 per substituir-lo, més avançat i capaç d'utilitzar un sistema d'informació en el seu nucli per a negocis amb una arquitectura monolítica. I aquí, al meu entendre, simplement hi ha una terrible injustícia en relació als monòlits: l'arquitectura presumptament monolítica no es correspon amb el model de negoci del domini. Sí, si això fos així, el sistema no podria funcionar en absolut, en contradicció amb la mateixa llei i el sentit comú de Conway. No, l'arquitectura monolítica és totalment coherent amb el model de negoci en aquesta etapa de desenvolupament empresarial; per descomptat, em refereixo a l'etapa en què el sistema ja s'ha creat i posat en funcionament. És un fet absolutament meravellós que, independentment de l'enfocament arquitectònic, tant la versió 3 de l'arquitectura orientada a serveis com la versió N de l'arquitectura de microserveis funcionaran igual de bé. Quina és la trampa?
Tot flueix, tot canvia o els microserveis són un mitjà per combatre la complexitat?
Abans de continuar, mirem algunes idees errònies sobre l'arquitectura de microserveis.
Els defensors de l'ús d'un enfocament de microserveis sovint argumenten que trencar un monòlit en microserveis simplifica l'enfocament de desenvolupament reduint la base de codi dels serveis individuals. En la meva opinió, aquesta afirmació és un disbarat total. De debò, la interacció òbvia dins d'un codi monòlit i homogeni sembla complicada? Si aquest fos realment el cas, tots els projectes es construirien inicialment com a microserveis, mentre que la pràctica demostra que la migració d'un monòlit a microserveis és molt més habitual. La complexitat no desapareix; simplement passa de mòduls individuals a interfícies (ja siguin busos de dades, RPC, API o altres protocols) i sistemes d'orquestració. I això és difícil!
L'avantatge d'utilitzar una pila heterogènia també és qüestionable. No argumentaré que això també sigui possible, però en realitat es produeix rarament (Mirant endavant -això hauria de passar-, sinó més aviat com a conseqüència que no pas un avantatge).
Cicle de vida del producte i cicle de vida del servei
Fes una altra ullada al diagrama anterior. No és casualitat que hagi observat el cicle de vida decreixent d'una versió separada d'un negoci; en condicions modernes, és l'acceleració de la transició d'un negoci entre versions la que és decisiva per al seu èxit. L'èxit d'un producte està determinat per la velocitat de prova de les hipòtesis empresarials en ell. I aquí, al meu entendre, rau l'avantatge clau de l'arquitectura de microserveis. Però anem en ordre.
Passem a la següent etapa en l'evolució dels sistemes d'informació: a l'arquitectura SOA orientada a serveis. Per tant, en un moment determinat hem destacat en el nostre producte serveis de llarga durada - de llarga durada en el sentit que quan es mou entre versions d'un producte, hi ha la possibilitat que el cicle de vida del servei sigui més llarg que el cicle de vida de la següent versió del producte. Seria lògic no canviar-los gens: nosaltres El que importa és la velocitat de transició a la següent versió. Però, per desgràcia, ens veiem obligats a fer canvis constants en els serveis, i aquí tot funciona per a nosaltres, pràctiques DevOps, contenidorització, etc., tot el que ens ve al cap. Però aquests encara no són microserveis!
Els microserveis com a mitjà per combatre la complexitat... gestió de la configuració
I aquí finalment podem passar al paper definitori dels microserveis: aquest és un enfocament que simplifica la gestió de la configuració del producte. Amb més detall, la funció de cada microservei descriu exactament la funció empresarial dins del producte segons el model de domini, i aquestes són coses que no viuen en una versió de curta durada, sinó en una oportunitat de negoci de llarga durada. I la transició a la següent versió del producte passa literalment desapercebuda: canvies/afegeixes un microservei, i potser només l'esquema de la seva interacció, i de sobte et trobes en el futur, deixant enrere competidors plorants que continuen saltant entre versions de els seus monòlits. Ara imagineu que hi ha un volum bastant gran de microserveis amb interfícies predefinides i capacitats empresarials. I vingueu a construir l'estructura del vostre producte a partir de microserveis preparats, simplement dibuixant un diagrama, per exemple. Enhorabona, tens una plataforma, i ara pots atraure negocis per tu mateix. Somnis Somnis.
Troballes
- L'arquitectura del sistema ha d'estar determinada pel cicle de vida dels seus components. Si un component viu dins d'una versió de producte, no té sentit augmentar la complexitat del sistema utilitzant un enfocament de microservei.
- L'arquitectura de microservei s'ha de basar en el model de domini, perquè l'oportunitat de negoci és el domini més longeu
- Les pràctiques de lliurament (pràctiques DevOps) i l'orquestració són una de les més importants per a l'arquitectura de microserveis, ja que l'augment de la taxa de canvi dels components imposa una exigència més gran sobre la velocitat i la qualitat del lliurament.
Font: www.habr.com
