Ola, Habr. Hoxe sigo cunha serie de publicacións que escribín expresamente para o inicio dunha nova corrente do curso. .
Introdución
A elección do estilo arquitectónico é unha das decisións técnicas fundamentais á hora de construír un sistema de información. Nesta serie de artigos propoño analizar os estilos arquitectónicos máis populares para aplicacións de construción e responder á pregunta de cando é o estilo arquitectónico máis preferible. No proceso de presentación, tentarei debuxar unha cadea lóxica que explique o desenvolvemento dos estilos arquitectónicos desde os monólitos ata os microservizos.
A última vez falamos dos diferentes tipos de monólitos e do uso de compoñentes para construílos, tanto de compoñentes de construción como de compoñentes de despregue. Entendemos a arquitectura orientada a servizos.
Agora definiremos finalmente as principais características dunha arquitectura de microservizos.
Relación de arquitecturas
É necesario entender que, en función das definicións dadas en artigos anteriores, calquera servizo é un compoñente, pero non todos os servizos son un microservizo.
Características da arquitectura de microservizos
As principais características da arquitectura de microservizos son:
- Organizado en torno ás capacidades empresariais
- Produtos non Proxectos
- Puntos finais intelixentes e tubos mudos
- Gobernanza Descentralizada
- Xestión descentralizada de datos
- Automatización de infraestruturas
- Deseño para o fracaso
- Arquitectura con desenvolvemento evolutivo (Evolutionary Design)
O primeiro punto provén da arquitectura orientada a servizos porque os microservizos son un caso especial de servizos. Outros puntos merecen unha consideración aparte.
Organizado en torno ás capacidades empresariais
Agora cómpre lembrar a lei de Conway: as organizacións que crean sistemas organizan a súa arquitectura, copiando a estrutura de interacción dentro destas organizacións. Como exemplo, podemos lembrar o caso da creación dun compilador: un equipo de sete persoas desenvolveu un compilador de sete pasos e un equipo de cinco desenvolveu un compilador de cinco pasos.
Se falamos de monólitos e microservizos, entón se o desenvolvemento está organizado por departamentos funcionais (backend, frontend, administradores de bases de datos), entón obtemos un monólito clásico.
Para obter microservizos, os equipos deben estar organizados por capacidades empresariais (pedidos, envíos, equipo de catálogo). Esta organización permitirá aos equipos centrarse na construción de partes específicas da aplicación.
Produtos non Proxectos
Un enfoque de proxecto no que un equipo transfire a funcionalidade desenvolvida a outros equipos é completamente inadecuado no caso dunha arquitectura de microservizos. O equipo debe apoiar o sistema durante todo o seu ciclo de vida. Amazon, un dos líderes na implementación de microservizos, afirmou: "ti constrúes, execútalo". O enfoque do produto permite ao equipo sentir as necesidades da empresa.
Puntos finais intelixentes e tubos mudos
A arquitectura SOA prestou moita atención ás canles de comunicación, en particular ao Bus de servizo empresarial. O que adoita levar a Erroneous Spaghetti Box, é dicir, a complexidade do monólito convértese na complexidade das conexións entre servizos. A arquitectura de microservizos só usa métodos de comunicación sinxelos.
Gobernanza Descentralizada
As decisións clave sobre os microservizos deben ser tomadas polas persoas que realmente desenvolven os microservizos. Aquí, as decisións clave significan opcións
linguaxes de programación, metodoloxía de implantación, contratos de interfaces públicas, etc.
Xestión descentralizada de datos
O enfoque estándar, no que a aplicación se basea nunha única base de datos, non pode ter en conta as particularidades de cada servizo específico. MSA implica unha xestión descentralizada de datos, incluíndo o uso de varias tecnoloxías.
Automatización de infraestruturas
MSA admite procesos continuos de implantación e entrega. Isto só se pode conseguir automatizando procesos. Ao mesmo tempo, despregar un gran número de servizos xa non parece algo asustado. O proceso de implantación debería volverse aburrido. O segundo aspecto está relacionado coa xestión do servizo nun contorno de produto. Sen automatización, a xestión de procesos que se executan en diferentes contornos operativos faise imposible.
Deseño para o fracaso
Numerosos servizos MSA son propensos a fallar. Ao mesmo tempo, o manexo de erros nun sistema distribuído non é unha tarefa trivial. A arquitectura da aplicación debe ser resistente a estes fallos. Rebecca Parsons pensa que é moi importante que xa non usemos a comunicación en proceso entre servizos, senón que recorremos ao HTTP para a comunicación, que non é tan fiable.
Arquitectura con desenvolvemento evolutivo (Evolutionary Design)
A arquitectura do sistema MSA debería desenvolverse de forma evolutiva. É recomendable limitar os cambios necesarios aos límites dun único servizo. Tamén hai que ter en conta o impacto noutros servizos. O enfoque tradicional é tentar resolver este problema co control de versións, pero MSA suxire usar o control de versións
como último recurso.
Conclusión
Despois de todo o anterior, podemos formular que son os microservizos. A arquitectura de microservizos é un enfoque para desenvolver unha única aplicación como unha colección de pequenos servizos, cada un funcionando no seu propio proceso e interactuando a través de mecanismos lixeiros, moitas veces unha API de recursos HTTP. Estes servizos baséanse en capacidades empresariais e pódense implementar de forma independente usando completamente
mecanismo de implantación automatizado. Existe un nivel mínimo de xestión centralizada destes servizos, que se poden escribir en diferentes linguaxes de programación e empregar diferentes tecnoloxías de almacenamento de datos.
Fonte: www.habr.com