Hola habr. La inscripción para una nueva secuencia de cursos está abierta ahora mismo en OTUS . En vísperas del inicio del curso, quiero compartir con vosotros mi artículo original.
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.
Un poco de historia
Si intenta preguntar a los desarrolladores: "¿Por qué necesitamos microservicios?", obtendrá una variedad de respuestas. Escuchará que los microservicios mejoran la escalabilidad, hacen que el código sea más fácil de entender, mejoran la tolerancia a fallas y, a veces, escuchará que le permiten "limpiar su código". Miremos la historia para comprender el propósito detrás del surgimiento de los microservicios.
En resumen, los microservicios en nuestra comprensión actual surgieron de la siguiente manera: en 2011, James Lewis, analizando el trabajo de varias empresas, llamó la atención sobre el surgimiento de un nuevo patrón de "microaplicaciones", que optimizó SOA en términos de acelerar el despliegue de servicios. Un poco más tarde, en 2012, en una cumbre de arquitectura, el patrón pasó a llamarse microservicio. Así, el objetivo inicial de introducir microservicios era mejorar el notorio hora de comprar.
Los microservicios estuvieron de moda en 2015. Según algunos estudios, ni una sola conferencia estuvo completa sin un informe sobre el tema de los microservicios. Además, algunas conferencias estuvieron dedicadas exclusivamente a los microservicios. Hoy en día, muchos proyectos comienzan a utilizar este estilo arquitectónico y, si el proyecto contiene toneladas de código heredado, entonces probablemente se esté llevando a cabo activamente la migración a microservicios.
A pesar de todo lo anterior, un número bastante pequeño de desarrolladores todavía puede definir el concepto de "microservicio". Pero hablaremos de esto un poco más tarde...
Monolito
El estilo arquitectónico que contrasta los microservicios es el monolito (o todo en uno). Probablemente no tenga sentido decir qué es un monolito, por lo que enumeraré de inmediato las desventajas de este estilo arquitectónico, que inició el desarrollo posterior de los estilos arquitectónicos: tamaño, conectividad, implementación, escalabilidad, confiabilidad y rigidez. A continuación propongo echar un vistazo a cada una de las deficiencias por separado.
tamaño
El monolito es muy grande. Y suele comunicarse con una base de datos muy grande. La aplicación se vuelve demasiado grande para que un desarrollador la entienda. Solo aquellos que han pasado mucho tiempo trabajando en este código pueden trabajar bien con el monolito, mientras que los principiantes pasarán mucho tiempo tratando de descifrar el monolito y no hay garantía de que lo logren. Por lo general, cuando se trabaja con un monolito, siempre hay algún senior "condicional" que conoce el monolito más o menos bien y vence a otros nuevos desarrolladores en un año y medio. Naturalmente, un mayor condicional es un único punto de falla, y su partida puede conducir a la muerte del monolito.
Conectividad
El monolito es una “gran bola de barro”, cuyos cambios pueden tener consecuencias impredecibles. Al realizar cambios en un lugar, puedes dañar el monolito en otro (lo mismo "te rascaste la oreja, *@ se cayó"). Esto se debe al hecho de que los componentes del monolito tienen relaciones muy complejas y, lo más importante, no obvias.
Despliegue
El despliegue de un monolito, debido a las complejas relaciones entre sus componentes, es un proceso largo y con su propio ritual. Este tipo de ritual no suele estar completamente estandarizado y se transmite “oralmente”.
Escalabilidad
Los módulos Monolith pueden tener necesidades de recursos contradictorias, lo que requiere hacer concesiones en términos de hardware. Imagine que tiene un monolito que consta de los servicios A y B. El servicio A exige el tamaño del disco duro y el servicio B exige la RAM. En este caso, la máquina en la que está instalado el monolito debe cumplir con los requisitos de ambos servicios, o tendrá que desactivar manual y artificialmente uno de los servicios.
Otro ejemplo (más clásico): el servicio A es mucho más popular que el servicio B, por lo que desea que haya 100 servicios A y 10 servicios B. Nuevamente, dos opciones: o implementamos 100 monolitos completos o en algunos Los servicios B deberán desactivarse manualmente.
Confiabilidad
Dado que todos los servicios están ubicados juntos, si el monolito cae, todos los servicios caen a la vez. De hecho, esto puede no ser tan malo, al menos no habrá fallas parciales en un sistema distribuido, pero por otro lado, debido a un error en la funcionalidad que utiliza el 0.001% de los usuarios, se pueden perder todos los usuarios. de su sistema.
Inercia
Debido al tamaño del monolito, es difícil cambiar a nuevas tecnologías. Como resultado, retener a ese mismo senior es una tarea separada. El stack tecnológico elegido al inicio de un proyecto puede convertirse en un bloque que obstaculice el desarrollo del producto.
Conclusión
La próxima vez hablaremos de cómo la gente ha intentado resolver estos problemas pasando a componentes y SOA.
Lee mas:
Fuente: habr.com