Hola, Habr. Hoy continuo la serie de publicaciones que escribí especialmente para el inicio de un nuevo flujo del curso. .
Introducción
La elección del estilo arquitectónico es una de las decisiones técnicas fundamentales al construir un sistema de información. En esta serie de artículos, propongo analizar los estilos arquitectónicos más populares para la construcción de aplicaciones y responder a la pregunta de cuándo es preferible un estilo arquitectónico en particular. A lo largo de la exposición, intentaré establecer una cadena lógica que explique el desarrollo de estilos arquitectónicos desde monolitos hasta microservicios.
En Hemos lidiado con el monolito y hemos llegado a la conclusión de que presenta una serie de problemas: tamaño, cohesión, despliegue, escalabilidad, fiabilidad y rigidez.
En esta ocasión, propongo hablar sobre 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 que el sistema funcione como un conjunto de componentes que se pueden utilizar tanto en proyectos actuales como en futuros. Al descomponer el sistema en componentes, se tienen en cuenta: su reutilización, intercambiabilidad, independencia del contexto, extensibilidad, encapsulamiento e independencia.
Con el uso adecuado de componentes, se resuelve el problema de 'la gran bola de barro' (gran tamaño + alta cohesión), y los propios componentes pueden ser tanto unidades de ensamblaje (módulos, bibliotecas), como unidades de despliegue (servicios). Las unidades de despliegue no siempre se corresponden con un proceso ejecutable: por ejemplo, una aplicación web y una base de datos se despliegan juntas.
Los monolitos se desarrollan más a menudo como un conjunto de módulos. Este enfoque asegura la independencia en el desarrollo, pero todavía quedan problemas de escalabilidad y despliegue independientes, resistencia a fallos e independencia del stack tecnológico general. Es por eso que un módulo es un componente parcialmente independiente.
El principal problema de este monolito es que la división en módulos es puramente lógica y puede ser fácilmente violada por los desarrolladores. Puede surgir un módulo core que gradualmente se convierte en un desastre, pueden aumentar los gráficos de dependencias entre módulos, y así sucesivamente. Para evitar tales problemas, el desarrollo debe ser llevado a cabo por un equipo muy maduro, o bajo la supervisión de un 'arquitecto' que se dedique a tiempo completo a la revisión del código y corría a los desarrolladores que violen la estructura lógica.
Un monolito 'ideal' consiste en un conjunto de módulos lógicamente separados, cada uno de los cuales accede a su propia base de datos.
Arquitectura orientada a servicios
Si se prevé la organización del sistema en forma de un conjunto de servicios, se trata de una arquitectura orientada a servicios. Sus principios son: la compatibilidad de las aplicaciones orientadas al usuario, la reutilización de servicios empresariales, la independencia del conjunto de tecnologías y la autonomía (evolución, escalabilidad y despliegue independientes).
La arquitectura orientada a servicios (SOA = service oriented architecture) resuelve todos los problemas mencionados del monolito: al realizar cambios, solo se ve afectado un servicio, y una API claramente definida mantiene una buena encapsulación de los componentes.
Pero no todo es tan sencillo: SOA da lugar a nuevos problemas. Las llamadas remotas son más costosas que las locales, y la redistribución de responsabilidades entre los componentes se ha vuelto significativamente más cara.
Por cierto, la posibilidad de un despliegue independiente es una característica muy importante del servicio. Si los servicios deben desplegarse conjuntamente o, aun más, en un cierto orden, entonces el sistema no puede considerarse orientado a servicios. En este caso, se habla de un monolito distribuido (se considera un antipatrón no solo desde la perspectiva de SOA, sino también de la arquitectura de microservicios).
La arquitectura orientada a servicios cuenta con un buen respaldo de la comunidad arquitectónica y de los proveedores. De aquí se derivan numerosos cursos y certificaciones, así como patrones bien elaborados. Entre estos últimos se encuentra, por ejemplo, la famosa bus de servicios empresariales (ESB = enterprise service bus). Cabe destacar que la ESB es un legado de los proveedores y no necesariamente debe utilizarse en SOA.
El pico de popularidad de la arquitectura orientada a servicios fue aproximadamente en 2008, después de lo cual comenzó a decaer, siendo el descenso mucho más pronunciado tras la llegada de los microservicios (~2015).
Conclusión
Después de haber discutido las posibilidades de organización de sistemas de información en forma de servicios y módulos, propongo finalmente pasar a los principios de la arquitectura de microservicios, prestando especial atención a la diferencia entre la arquitectura de microservicios y la orientada a servicios en la siguiente parte.
Fuente: habr.com
