Cuando se concibe un gran producto o un pequeño software comienza a convertirse en un leviatán, ¿qué camino de desarrollo debo elegir? ¿Debo reescribir todo desde cero o continuar con las tradiciones "históricamente establecidas"? De todos modos, ¿vale la pena revisar el concepto mismo de arquitectura?
¡Hola, Khabrovites! Mi nombre es Konstantin, y soy el desarrollador principal de un sistema bastante grande que comenzó una vez como un experimento. Un pequeño sitio PHP creado literalmente "en la rodilla" y, por supuesto, un monolito. A medida que pasó el tiempo, el sitio creció y se topó con una serie de problemas, cuya solución planteó la pregunta "¿y luego cómo?".
Monolito o microservicios? Que elegir La diferencia básica entre los enfoques, en mi opinión, es que un monolito implica un ciclo centralizado para procesar la solicitud de un usuario y microservicios, uno descentralizado. Las ventajas y desventajas comunes de ambos enfoques son ampliamente conocidas y enumeradas más de una vez (por ejemplo,
aquí ,
aquí o
aquí ). Sin embargo, no hay factores tan obvios y obvios que influyen en la elección de la arquitectura.
- Carga de empleados a tiempo completo . Con el rápido desarrollo del producto, se acumula un grupo de tareas que no se pueden resolver en un marco de tiempo aceptable: todos están ocupados. Y si tal "bloqueo" es único, no tiene sentido expandir el personal de los desarrolladores. La solución obvia son los contratistas externos (empresas o autónomos). Pero, ¿cómo darles una parte del producto para que funcionen sin arriesgarse a convertirlo en un OpenSource, en términos generales? En el caso de usar microservicios, esta tarea es mucho más fácil de resolver.
- La dificultad del buceo . Cuanto más grande es el producto, más tiempo le toma a un nuevo empleado sentirse cómodo en él. Especialmente si hay muchos valores predeterminados diferentes en el código (sí, una buena documentación hace que el proceso sea mucho más fácil, pero ¿no es así?) Y personalizaciones para casos especiales individuales. Desde este punto de vista, lidiar con una pequeña parte independiente es mucho más fácil que con todo el producto de inmediato.
- Recursos en cargas máximas . En mi práctica, hubo un caso en que la carga en los servidores a veces creció a valores inaceptables (y si específicamente - la RAM se agotó, se activó un intercambio y el servidor se convirtió en un vegetal por un tiempo), durante el trabajo libre todo el resto del tiempo (la carga no fue más del 30% en términos de RAM ) Y tales picos ocurrieron de manera irregular y con largas pausas. En el caso de un monolito (creemos que no hay ningún lugar para optimizar el código), solo se guarda la conexión de nuevos servidores con una copia de todo el sistema para el equilibrio de carga. Y en el caso de los microservicios, puede organizar una cola de procesamiento (por supuesto, esto se aplica solo a las operaciones críticas de tiempo que son rápidas y no esperadas, como la descarga de una tabla de Excel).
- Realización de tareas en segundo plano . De qué manera este factor "sacude el bote" depende de su tamaño y complejidad. Como regla, un monolito y un temporizador (cron) son suficientes. Pero si las tareas comienzan a acumularse en grupos grandes, también surgen problemas. Es necesario equilibrar las tareas cron ya. Los microservicios facilitan enormemente esta situación.
- La complejidad del seguimiento . En el caso de los microservicios, se incrementan los requisitos para el mantenimiento del hierro: dónde, qué y cómo se debe configurar. Monolito: en términos generales, algunas configuraciones para todos los nodos, microservicios, la configuración depende de los requisitos de microservicios específicos que se ejecutan en el nodo.
- Requisitos de calificación . Cuantas más tecnologías tenga el zoológico (y generalmente crece si el sistema es microservicio), mayores serán los requisitos para las habilidades y el conocimiento de los empleados regulares. Después de todo, si hay mejoras o problemas, deben hacer frente. O se necesitan más profesionales para cubrir toda la pila.
¿Hay alguna necesidad de elegir? ¿Vale la pena el juego? Creo que definitivamente vale la pena. Pero uno debe abordar el problema con la cabeza fría. De lo contrario, algunos problemas simplemente serán reemplazados por otros.
En mi caso, llegó un punto de inflexión cuando el sitio dejó de "encajar" en los recursos de un servidor. Luego se decidió reescribir el sistema de acuerdo con la mejor opción en mi opinión: un híbrido. Hay
recomendaciones generales para el desarrollo de productos en el "caso híbrido". Pero me gustaría complementarlo con algunas recomendaciones.
Al diseñar un monolito de inicio, las posibilidades para una mayor conexión de servicios externos deben establecerse de inmediato. Inmediatamente construya comunicaciones entre componentes como si estos componentes ya (o casi ya) "servicios externos". Especialmente si son intensivos en recursos.
Piense inmediatamente en una política para trabajar con cachés y almacenamiento de datos (bases de datos y archivos). Por ejemplo, comparta la sesión de un usuario.
Y lo más importante es no precipitarse a los extremos. Para mí, deduje la siguiente fórmula para un buen proyecto: "un sistema efectivo es un sistema equilibrado". En particular, esto se expresa en el hecho de que en los microservicios solo extraigo fragmentos grandes y lógicamente aislados del núcleo. Y luego, solo si se cumple al menos una de las condiciones:
- se requiere limitación de carga y previsión, el retraso de tiempo debido a la ejecución de la tarea no es crítico a su vez
- El aislamiento dará un aumento significativo en la productividad.
Como resultado de este enfoque, obtuvimos un sistema, el 95% de la funcionalidad ubicada en el núcleo y el 5% en microservicios. Pero al mismo tiempo, el núcleo representa solo el 60% de la carga total. Y al mismo tiempo, puede garantizar que la carga en servidores individuales no exceda los valores críticos.
Por lo tanto, los microservicios son (a partir de cierto tamaño del producto) buenos si los usa solo si es absolutamente necesario, y no por la moda o "porque es genial". Hay grandes
productos que viven con éxito como un monolito. Pero a veces un monolito no puede resolver el problema ...
Gracias