Hola Habr. Hoy continúo una serie de publicaciones que escribí específicamente para el inicio de una nueva corriente del curso. .
introducción
La elección del estilo arquitectónico es una de las decisiones técnicas fundamentales a la hora de construir un sistema de información. En esta serie de artículos, propongo analizar los estilos arquitectónicos más populares para aplicaciones de construcción y responder a la pregunta de cuándo qué estilo arquitectónico es más preferible. En el proceso de presentación, intentaré dibujar una cadena lógica que explique el desarrollo de estilos arquitectónicos desde monolitos hasta microservicios.
La última vez hablamos sobre los diferentes tipos de monolitos y el uso de componentes para construirlos, tanto componentes de construcción como de implementación. Entendemos la arquitectura orientada a servicios.
Ahora finalmente definiremos las principales características de una arquitectura de microservicio.
Relación de arquitecturas
Es necesario comprender que, según las definiciones dadas en artículos anteriores, cualquier servicio es un componente, pero no todo servicio es un microservicio.
Características de la arquitectura de microservicios
Las principales características de la arquitectura de microservicios son:
- Organizado en torno a las capacidades empresariales
- Productos no proyectos
- Puntos finales inteligentes y tuberías tontas
- Gobernanza descentralizada
- Gestión de datos descentralizada
- Automatización de infraestructura
- Diseño para el fracaso
- Arquitectura con desarrollo evolutivo (Diseño Evolutivo)
El primer punto proviene de la arquitectura orientada a servicios porque los microservicios son un caso especial de servicios. Otros puntos merecen una consideración aparte.
Organizado en torno a las capacidades empresariales
Ahora es necesario recordar la ley de Conway: las organizaciones que crean sistemas organizan su arquitectura, copiando la estructura de interacción dentro de estas organizaciones. Como ejemplo, podemos recordar el caso de la creación de un compilador: un equipo de siete personas desarrolló un compilador de siete pasos y un equipo de cinco desarrolló un compilador de cinco pasos.
Si hablamos de monolitos y microservicios, entonces si el desarrollo está organizado por departamentos funcionales (backend, frontend, administradores de bases de datos), obtenemos un monolito clásico.
Para obtener microservicios, los equipos deben estar organizados por capacidad de negocio (pedidos, envíos, equipo de catálogo). Esta organización permitirá que los equipos se concentren en crear partes específicas de la aplicación.
Productos no proyectos
Un enfoque de proyecto en el que un equipo transfiere la funcionalidad desarrollada a otros equipos es completamente inadecuado en el caso de una arquitectura de microservicio. El equipo debe soportar el sistema durante todo su ciclo de vida. Amazon, uno de los líderes en la implementación de microservicios, afirmó: “tú construyes, tú lo ejecutas”. El enfoque de producto permite al equipo sentir las necesidades del negocio.
Puntos finales inteligentes y tuberías tontas
La arquitectura SOA prestó gran atención a los canales de comunicación, en particular al Enterprise Service Bus. Lo que a menudo conduce a una caja de espagueti errónea, es decir, la complejidad del monolito se convierte en complejidad de las conexiones entre servicios. La arquitectura de microservicios utiliza sólo métodos de comunicación simples.
Gobernanza descentralizada
Las decisiones clave sobre los microservicios deben ser tomadas por las personas que realmente desarrollan los microservicios. Aquí, las decisiones clave significan elecciones
lenguajes de programación, metodología de implementación, contratos de interfaz pública, etc.
Gestión de datos descentralizada
El enfoque estándar, en el que la aplicación se basa en una única base de datos, no puede tener en cuenta las particularidades de cada servicio específico. MSA implica una gestión de datos descentralizada, incluido el uso de diversas tecnologías.
Automatización de infraestructura
MSA admite procesos continuos de implementación y entrega. Esto sólo se puede lograr mediante la automatización de procesos. Al mismo tiempo, implementar una gran cantidad de servicios ya no parece algo aterrador. El proceso de implementación debería volverse aburrido. El segundo aspecto está relacionado con la gestión de servicios en un entorno de producto. Sin automatización, gestionar procesos que se ejecutan en diferentes entornos operativos se vuelve imposible.
Diseño para el fracaso
Numerosos servicios de MSA son propensos a fallar. Al mismo tiempo, el manejo de errores en un sistema distribuido no es una tarea trivial. La arquitectura de la aplicación debe ser resistente a tales fallas. Rebecca Parsons cree que es muy importante que ya ni siquiera utilicemos la comunicación en proceso entre servicios; en su lugar, recurrimos a HTTP para la comunicación, que no es tan confiable.
Arquitectura con desarrollo evolutivo (Diseño Evolutivo)
La arquitectura del sistema MSA debería desarrollarse evolutivamente. Es aconsejable limitar los cambios necesarios a los límites de un único servicio. También hay que tener en cuenta el impacto en otros servicios. El enfoque tradicional es intentar resolver este problema con el control de versiones, pero MSA sugiere utilizar el control de versiones en
como último recurso.
Conclusión
Después de todo lo anterior, podemos formular qué son los microservicios. La arquitectura de microservicios es un enfoque para desarrollar una única aplicación como una colección de pequeños servicios, cada uno de los cuales se ejecuta en su propio proceso e interactúa a través de mecanismos livianos, a menudo API de recursos HTTP. Estos servicios se basan en capacidades empresariales y se pueden implementar de forma independiente utilizando
Mecanismo de implementación automatizado. Existe un nivel mínimo de gestión centralizada de estos servicios, que pueden escribirse en diferentes lenguajes de programación y utilizar diferentes tecnologías de almacenamiento de datos.
Fuente: habr.com