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.
В Nos ocupamos del monolito y llegamos a la conclusión de que el monolito tiene una serie de problemas: tamaño, conectividad, implementación, escalabilidad, confiabilidad y rigidez.
En esta ocasión propongo hablar de las posibilidades de organizar un sistema como un conjunto de módulos/bibliotecas (arquitectura orientada a componentes) o servicios (arquitectura orientada a servicios).
Arquitectura orientada a componentes
La arquitectura orientada a componentes implica ejecutar un sistema como un conjunto de componentes que se pueden utilizar tanto en proyectos actuales como futuros. Al descomponer un sistema en componentes se tiene en cuenta lo siguiente: su reutilización, su reemplazabilidad, independencia del contexto, extensibilidad, encapsulación e independencia.
Con el uso adecuado de los componentes, el problema de la “gran bola de tierra” (gran tamaño + alto acoplamiento) se resuelve, y los componentes en sí pueden representar tanto unidades de ensamblaje (módulos, bibliotecas) como unidades de implementación (servicios). Las unidades de implementación no siempre se asignan al proceso en ejecución: por ejemplo, una aplicación web y una base de datos se implementan juntas.
Muy a menudo, los monolitos se desarrollan como un conjunto de módulos. Este enfoque conduce al desarrollo independiente, pero persisten los problemas de escalamiento e implementación independientes, tolerancia a fallas e independencia del conjunto tecnológico general. Por eso el módulo es un componente parcialmente independiente.
El mayor problema con un monolito de este tipo es que la división en módulos es puramente lógica y los desarrolladores pueden violarla fácilmente. Puede aparecer un módulo central, que gradualmente se convierte en un basurero, el gráfico de dependencias entre módulos puede crecer, etc. Para evitar tales problemas, el desarrollo debe ser realizado por un equipo muy maduro o bajo la guía de un "arquitecto" que se dedique a la revisión del código a tiempo completo y golpee a los desarrolladores que violan la estructura lógica.
El monolito "ideal" es un conjunto de módulos lógicamente separados, cada uno de los cuales consulta su propia base de datos.
Arquitectura orientada a Servicios
Si se supone que el sistema está organizado en forma de un conjunto de servicios, entonces estamos hablando de una arquitectura orientada a servicios. Sus principios son la interoperabilidad de aplicaciones centrada en el usuario, la reutilización de servicios empresariales, la independencia de la pila tecnológica y la autonomía (evolución, escalabilidad e implementación independientes).
La arquitectura orientada a servicios (SOA = arquitectura orientada a servicios) resuelve todos los problemas identificados de un monolito: sólo un servicio se ve afectado cuando se produce un cambio y una API bien definida admite una buena encapsulación de componentes.
Pero no todo es tan sencillo: SOA crea nuevos problemas. Las llamadas remotas son más caras que las locales y la redistribución de responsabilidades entre componentes se ha vuelto significativamente más costosa.
Por cierto, la posibilidad de implementación independiente es una característica muy importante del servicio. Si los servicios deben implementarse juntos o, además, en una secuencia determinada, entonces el sistema no puede considerarse orientado a servicios. En este caso se habla de un monolito distribuido (considerado un antipatrón no sólo desde el punto de vista de SOA, sino también desde el punto de vista de la arquitectura de microservicios).
La arquitectura orientada a servicios cuenta con el apoyo de la comunidad de arquitectos y los proveedores. Esto implica la presencia de muchos cursos y certificaciones, patrones bien desarrollados. A este último pertenece, por ejemplo, el conocido bus de servicios empresariales (ESB = bus de servicios empresariales). Al mismo tiempo, ESB es un equipaje de los proveedores y no necesariamente tiene que usarse en SOA.
La popularidad de la arquitectura orientada a servicios alcanzó su punto máximo alrededor de 2008, después de lo cual comenzó a declinar, lo que se volvió significativamente más dramático después de la llegada de los microservicios (~2015).
Conclusión
Después de haber discutido las posibilidades de organizar sistemas de información en forma de servicios y módulos, propongo pasar finalmente a los principios de la arquitectura de microservicios y prestar especial atención a la diferencia entre arquitectura de microservicios y arquitectura orientada a servicios en la siguiente parte.
Fuente: habr.com