Quería escribir un artigo sobre o tema da arquitectura de microservizos durante moito tempo, pero dous puntos seguíanme parando: canto máis me mergullaba no tema, máis parecíame que o que sei é obvio e o que sei. t sei que hai que estudar e estudar. Por outra banda, penso que xa hai algo que discutir entre un público amplo. Así que as opinións alternativas son benvidas.
A Lei de Conway e a relación entre empresa, organización e sistema de información
Unha vez máis permitireime citar:
"Calquera organización que deseña un sistema (no sentido amplo) recibirá un deseño cuxa estrutura replique a estrutura dos equipos desa organización".
- Melvyn Conway, 1967
Na miña opinión, é máis probable que esta lei se relacione coa viabilidade de organizar un negocio, que directamente co sistema de información. Déixame explicar cun exemplo. Digamos que temos unha oportunidade de negocio bastante estable cun ciclo de vida tan longo que ten sentido organizar unha empresa (isto non é un erro, pero gústame moito este termo que roubei). Por suposto, o sistema de apoio deste negocio corresponderá organizativamente e procesalmente a este negocio.
Orientación empresarial dos sistemas de información
Déixame explicar cun exemplo. Digamos que hai unha oportunidade de negocio para organizar un negocio de venda de pizza. Na versión V1 (chamémoslle información previa), a empresa era unha pizzería, unha caixa rexistradora e un servizo de entrega. Esta versión foi longa en condicións de baixa variabilidade ambiental. Despois veu a versión 2 para substituílo, máis avanzado e capaz de utilizar un sistema de información no seu núcleo para empresas cunha arquitectura monolítica. E aquí, na miña opinión, hai simplemente unha terrible inxustiza en relación aos monolitos - a arquitectura supostamente monolítica non se corresponde co modelo de negocio do dominio. Si, se isto fose así, o sistema non podería funcionar en absoluto, en contradición coa mesma lei de Conway e o sentido común. Non, a arquitectura monolítica é totalmente coherente co modelo de negocio nesta fase de desenvolvemento empresarial: refírome, por suposto, á etapa na que o sistema xa foi creado e posto en funcionamento. É un feito absolutamente marabilloso que, independentemente do enfoque arquitectónico, tanto a versión 3 de arquitectura orientada a servizos como a versión N de arquitectura de microservizos funcionarán igual de ben. Cal é a trampa?
Todo flúe, todo cambia ou os microservizos son un medio para combater a complexidade?
Antes de continuar, vexamos algúns conceptos erróneos sobre a arquitectura de microservizos.
Os defensores do uso dun enfoque de microservizos adoitan argumentar que dividir un monólito en microservizos simplifica o enfoque de desenvolvemento ao reducir a base de código dos servizos individuais. Na miña opinión, esta afirmación é unha tontería total. En serio, a interacción obvia dentro dun código monolítico e homoxéneo parece complicada? Se este fose realmente o caso, todos os proxectos construiríanse inicialmente como microservizos, mentres que a práctica mostra que a migración dun monólito a microservizos é moito máis común. A complexidade non desaparece; simplemente pasa de módulos individuais a interfaces (xa sexan buses de datos, RPC, API e outros protocolos) e sistemas de orquestración. E isto é difícil!
A vantaxe de usar unha pila heteroxénea tamén é cuestionable. Non vou argumentar que isto tamén sexa posible, pero en realidade raramente ocorre (Mirando cara adiante -isto debería suceder- senón máis ben como consecuencia que como vantaxe).
Ciclo de vida do produto e ciclo de vida do servizo
Bótalle unha nova ollada ao diagrama anterior. Non é casualidade que observei o ciclo de vida decrecente dunha versión separada dunha empresa: en condicións modernas, a aceleración da transición dunha empresa entre versións é decisiva para o seu éxito. O éxito dun produto está determinado pola velocidade de proba das hipóteses comerciais nel. E aquí, na miña opinión, reside a vantaxe fundamental da arquitectura de microservizos. Pero imos en orde.
Pasemos á seguinte etapa na evolución dos sistemas de información: á arquitectura orientada a servizos de SOA. Entón, nalgún momento destacamos no noso produto servizos de longa duración - de longa duración no sentido de que ao moverse entre versións dun produto, existe a posibilidade de que o ciclo de vida do servizo sexa máis longo que o ciclo de vida da seguinte versión do produto. Sería lóxico non cambialos en absoluto, nós O que importa é a velocidade de transición á seguinte versión. Pero, por desgraza, vémonos obrigados a facer cambios constantes nos servizos, e aquí todo funciona para nós, as prácticas de DevOps, a contenerización, etc., todo o que se nos ocorre. Pero estes aínda non son microservizos!
Os microservizos como medio para combater a complexidade... xestión da configuración
E aquí finalmente podemos pasar ao papel definitorio dos microservizos: este é un enfoque que simplifica a xestión da configuración do produto. Con máis detalle, a función de cada microservizo describe exactamente a función comercial dentro do produto segundo o modelo de dominio, e estas son cousas que non viven nunha versión de curta duración, senón nunha oportunidade de negocio de longa duración. E a transición á seguinte versión do produto pasa literalmente desapercibida: cambias/engádese un microservizo e quizais só o esquema da súa interacción e, de súpeto, atópase no futuro, deixando atrás a choros competidores que seguen saltando entre versións de os seus monolitos. Agora imaxina que hai un volume bastante grande de microservizos con interfaces e capacidades empresariais predefinidas. E ven e constrúe a estrutura do seu produto a partir de microservizos preparados, simplemente debuxando un diagrama, por exemplo. Parabéns - tes unha plataforma - e agora podes atraer negocios por ti mesmo. Soños Soños.
Descubrimentos
- A arquitectura do sistema debe estar determinada polo ciclo de vida dos seus compoñentes. Se un compoñente vive dentro dunha versión do produto, non ten sentido aumentar a complexidade do sistema mediante un enfoque de microservizos.
- A arquitectura de microservizos debe basearse no modelo de dominio, porque a oportunidade de negocio é o dominio máis longevo
- As prácticas de entrega (prácticas de DevOps) e a orquestración son unha das máis importantes para a arquitectura de microservizos, xa que o aumento da taxa de cambio dos compoñentes aumenta as demandas sobre a velocidade e a calidade da entrega.
Fonte: www.habr.com