Unas palabras en defensa del monolito

Comparamos las características del microservicio y la arquitectura monolítica, sus ventajas y desventajas. El artículo fue preparado para Habr basado en los materiales de nuestro meta Hot Backend , que se celebró en Samara el 9 de febrero de 2019. Consideramos los factores de la elección de la arquitectura en función de la tarea específica.

Incluso hace 5 años, nadie había oído hablar de microservicios. Sin embargo, su popularidad aumenta de año en año, según las estadísticas de Google Trends.

Monolito y microservicios: ejemplos

Si el proyecto usa una arquitectura monolítica, entonces el desarrollador solo tiene una aplicación, cuyos componentes y módulos funcionan con una sola base.



La arquitectura de microservicios implica la descomposición en módulos que se ejecutan como procesos separados y pueden tener servidores separados. Cada microservicio funciona con su propia base de datos y todos estos servicios pueden comunicarse entre sí de forma síncrona (http) y asíncrona. Además, para optimizar la arquitectura, es deseable minimizar la relación entre los servicios.

El siguiente diagrama está simplificado, refleja, en primer lugar, los componentes del negocio.

Microservicios: beneficios

Existen al menos cuatro ventajas de la arquitectura de microservicios:

Escalado e implementación independientes

Se proporciona una implementación independiente para cada microservicio, y esto es conveniente al actualizar módulos individuales. Si la carga en el módulo aumenta, el microservicio correspondiente se puede escalar sin afectar a los demás. Esto le permite distribuir de manera flexible la carga y ahorrar recursos.

Desarrollo independiente

Cada microservicio (por ejemplo, un módulo de memoria) puede ser desarrollado por un equipo para aumentar la velocidad de creación de un producto de software.

Sostenibilidad

La falla de un microservicio no afecta el desempeño de otros módulos.

Heterogeneidad

Cada equipo es libre de elegir su propio idioma y tecnología para implementar microservicios, sin embargo, es deseable que tengan interfaces compatibles.

Entre los desarrolladores, puede escuchar la opinión de que la arquitectura monolítica está desactualizada, es difícil de mantener y escalar, crece rápidamente en un "gran trozo de tierra" y es prácticamente antipatrón, es decir, su presencia en el código es indeseable. Las grandes empresas, como Netflix, que cambiaron a la arquitectura de microservicios en sus proyectos, a menudo se citan como evidencia de esta opinión.

¿Veamos si todos realmente deberían cambiar de un monolito a microservicios siguiendo el ejemplo de las marcas más grandes?

Cambiar a microservicios: posibles dificultades

Problema uno: descomposición

Idealmente, la aplicación debe dividirse en microservicios para que interactúen entre sí lo menos posible, de lo contrario, la aplicación será difícil de mantener. Al mismo tiempo, la descomposición es difícil de implementar al comienzo del desarrollo, cuando los problemas comerciales y el área temática aún pueden cambiar con la llegada de nuevos requisitos. Refactorizar es costoso.

Si se hace necesario transferir parte de las funciones del servicio A al servicio B, puede haber dificultades: por ejemplo, los servicios se ejecutan en diferentes idiomas, las llamadas internas a los servicios se convierten en red, necesita conectar otras bibliotecas. Podemos verificar la corrección de la refactorización solo con la ayuda de las pruebas.



Problema dos: transacciones

Otro problema es que los microservicios no tienen el concepto de transacciones distribuidas. Podemos garantizar la integridad arquitectónica de una operación comercial solo dentro de un microservicio. Si la operación involucra varios microservicios, se pueden usar diferentes bases de datos allí, y dicha transacción tendrá que ser abandonada. Para resolver este problema, existen varios métodos utilizados en los negocios cuando la accesibilidad es más importante que la integridad. Al mismo tiempo, se proporcionan mecanismos de compensación en caso de que algo salga mal. Por ejemplo, si los productos no están en stock, debe realizar un reembolso en la cuenta del comprador.

Si un monolito nos da integridad arquitectónica automáticamente, entonces con microservicios debe crear su propio mecanismo y usar bibliotecas con soluciones listas para usar. Al distribuir una operación entre servicios, es mejor solicitar datos sincrónicamente y realizar acciones posteriores de forma asincrónica. Si es imposible acceder a uno de los servicios, el equipo se pondrá en cola tan pronto como esté disponible nuevamente.

En este sentido, es necesario revisar el enfoque de la interfaz de usuario. Se debe notificar al usuario que algunas acciones no se realizan de inmediato, sino dentro de un tiempo determinado. Cuando se procesa la solicitud, recibe una invitación para ver los resultados.



Problema tres: informes

Si utilizamos una arquitectura monolítica con una sola base de datos, para crear un informe complejo puede escribir seleccionar y extraer varias etiquetas de datos: tarde o temprano se mostrarán. Sin embargo, en microservicios, estos datos se pueden dispersar en diferentes bases.

Por ejemplo, necesitamos enumerar compañías con métricas específicas. Con una simple lista de empresas, todo funciona. ¿Y si necesita agregar métricas que se encuentran en otra base de datos? Sí, podemos hacer una solicitud adicional y solicitar métricas por TIN. ¿Y si esta lista necesita ser filtrada y ordenada? La lista de empresas puede ser muy grande, y luego tenemos que introducir un servicio adicional con su propia base de datos: informes.



Problema cuatro: alta complejidad de desarrollo

El trabajo en servicios distribuidos es más complicado: todas las solicitudes se realizan a través de la red y se pueden desactivar, debe proporcionar un mecanismo de devolución de llamada (¿volverá a hacer la llamada? ¿Cuántas veces?). Estos son los "ladrillos" que se acumulan gradualmente y contribuyen a aumentar la complejidad del proyecto.

Los servicios pueden ser desarrollados por varios equipos diferentes, y debe documentarlos, mantener la documentación actualizada y advertir a otros equipos cuando cambie la versión. Estos son costos laborales adicionales.

Si cada equipo tiene una implementación independiente, debe mantener al menos la versión anterior y deshabilitarla solo después de que todos los consumidores del servicio hayan cambiado a la nueva API.
Por supuesto, podemos llevar todas las API a algún tipo de artefacto que estará disponible públicamente. Pero, en primer lugar, los servicios se pueden escribir en diferentes idiomas y, en segundo lugar, esto no se recomienda. Por ejemplo, en uno de nuestros proyectos, rechazamos esto a pedido del cliente, relacionado con consideraciones de seguridad. Cada microservicio tiene un repositorio separado y el cliente no les da acceso.

En el proceso de desarrollo, todo puede funcionar correctamente, y luego, no. Sucede que, en caso de excepciones, la aplicación intenta procesarlos infinitamente, y esto genera una gran carga: todo el sistema "se despliega". Para evitar tales situaciones, debe configurar todo, por ejemplo, para limitar el número de intentos, no devolver esta llamada a la cola en el mismo segundo, etc.





El quinto problema: la complejidad de las pruebas, el rastreo y la depuración

Para probar un problema, debe descargar todos los microservicios involucrados. La depuración se convierte en una tarea no trivial, y todos los registros deben recopilarse en algún lugar en un solo lugar. En este caso, necesita tantos registros como sea posible para descubrir qué sucedió. Para rastrear el problema, debe comprender todo el camino que ha recorrido el mensaje. Las pruebas unitarias no son suficientes aquí, ya que es probable que haya errores en la unión de los servicios. Al realizar cambios, es posible verificar la operatividad solo después de ejecutar en el soporte. Podemos limitar cada microservicio a una cierta cantidad de memoria (por ejemplo, 500 megabytes), pero hay momentos de carga máxima cuando se necesitan hasta dos gigabytes. Hay momentos en que el sistema comienza a ralentizarse. Como resultado, los recursos se pueden gastar en algo que no pertenece a las tareas inmediatas del cliente: por ejemplo, solo hay dos microservicios comerciales, y la mitad de los recursos se gastan en tres microservicios adicionales que respaldan el trabajo de los demás.

Microservicio o monolito: criterios de selección

Al elegir entre arquitectura monolítica y microservicio, en primer lugar, debe proceder de la complejidad del área temática y la necesidad de escalar.

Si el área temática es simple y no se espera un aumento global en el número de usuarios, entonces los microservicios se pueden usar sin ninguna duda. En otros casos, es mejor comenzar el desarrollo en un monolito y ahorrar recursos si no se requiere escalar. Si el área temática es compleja, y en la etapa inicial no se definen los requisitos finales, también es mejor comenzar con un monolito, para no volver a hacer los microservicios varias veces. Con el desarrollo posterior del proyecto, es posible distinguir sus partes individuales en microservicios.



Una ventaja es la presencia de límites al comienzo del proyecto, ya que esto ayudará a no romperlos durante el proceso de desarrollo. También tiene sentido comenzar con una base de datos, pero definir un esquema para cada módulo (por ejemplo, un esquema de pago). Posteriormente, esto ayudará a simplificar la división de módulos en microservicios. En este caso, observamos los límites de los módulos y podemos usar microservicios.

Cada módulo debe tener su propia API, para que luego se pueda asignar y convertir el módulo en un microservicio.



Una vez determinados los límites de los módulos, puede proceder a la descomposición en microservicios, si es necesario. En aproximadamente el 90% de los casos será posible permanecer en el monolito, pero si es necesario, será más fácil y económico cambiar la arquitectura.

En nuestra práctica de trabajar con monolitos y microservicios, llegamos a las siguientes conclusiones:

• No cambie a microservicios solo porque los usa Netflix, Twitter, Facebook
• Comience con dos o tres microservicios que interactúen entre sí, resuelva en detalle todos los requisitos no funcionales (seguridad, tolerancia a fallas, escalabilidad, etc.) y solo luego pase a otros servicios
• Automatiza todo lo posible
• Configurar monitoreo
• Escribir autotests
• No utilice transacciones distribuidas (pero esta no es una razón para rechazar la garantía de integridad de los datos).
• Si desea utilizar la arquitectura de microservicios, prepárese para el hecho de que el desarrollo puede costarle aproximadamente 3 veces más que en un monolito. Sin embargo, ambas tecnologías tienen sus propias desventajas y ventajas; cada una de ellas tiene su propio nicho.