Microservicios frente a arquitectura monolítica [cerrado]


82

Leí un poco sobre microservicios y estoy un poco intrigado. Parece que es un concepto interesante. Pero me pregunto cuáles son las ventajas y desventajas del uso de microservicios sobre la arquitectura monolítica y viceversa.

Cuándo los microservicios son más adecuados y dónde ir mejor con la arquitectura monolítica.


6
Martin Fawler ha escrito un extenso artículo sobre el tema. Le sugiero que lea esto: martinfowler.com/articles/microservices.html
Kaj

Consulte este artículo sobre arquitectura de microservicios: medium.com/startlovingyourself/…
Bhagwati Malav

Es solo que un microservicio es un fragmento de un sistema de aplicación completo que se ejecuta como un servidor o un proceso de servicio de forma independiente y se ejecuta en el clúster de servidores. Entonces, si ocurrió un error en ese servicio, se aislará y todo el sistema no se descompondrá por completo, esa es una ventaja además de la concurrencia que puede obtener.
LEMUEL ADANE

Respuestas:


75

Si bien soy relativamente nuevo en el mundo de los microservicios, intentaré responder su pregunta lo más completa posible.

Cuando utilice la arquitectura de microservicios, tendrá un mayor desacoplamiento y separación de preocupaciones. Dado que está dividiendo literalmente su aplicación.

Esto da como resultado que su base de código será más fácil de administrar (cada aplicación es independiente de las otras aplicaciones para mantenerse en funcionamiento). Por lo tanto, si lo hace correctamente , en el futuro será más fácil agregar nuevas funciones a su aplicación. Mientras que con una arquitectura monolítica, podría resultar muy difícil de hacer si su aplicación es grande (y puede asumir que en algún momento lo será).

Además, la implementación de la aplicación es más fácil , ya que está construyendo los microservicios independientes por separado y implementándolos en servidores separados. Esto significa que puede crear e implementar servicios cuando lo desee sin tener que reconstruir el resto de su aplicación.

Dado que los diferentes servicios son pequeños y se implementan por separado, es obvio que es más fácil escalarlos , con la ventaja de que puede escalar servicios específicos de su aplicación (con un monolítico, escala la "cosa" completa, incluso si es solo una parte específica dentro del aplicación que está recibiendo una carga excesiva).

Sin embargo, para aplicaciones que no están destinadas a ser demasiado grandes para administrarlas en el futuro. Es mejor mantenerlo en la arquitectura monolítica. Dado que la arquitectura de microservicios tiene serias dificultades involucradas. Dije que es más fácil implementar microservicios, pero esto solo es cierto en comparación con los grandes monolitos. Al usar microservicios, tiene la complejidad adicional de distribuir los servicios a diferentes servidores en diferentes ubicaciones y necesita encontrar una manera de administrar todo eso. La creación de microservicios lo ayudará a largo plazo si su aplicación se vuelve grande, pero para aplicaciones más pequeñas, es más fácil mantenerse monolítico.


21
Mi experiencia (y he trabajado en ambos tipos de bases de código) es que monolítico es mucho más simple: la base de código es mucho más fácil de administrar (¡hay mucho menos!), Es más fácil agregar características (solo tiene que agregarlas en un solo lugar y no tiene que definir API entre procesos para todo), y su implementación es mucho más fácil (solo está implementando en un conjunto de servidores, no en media docena de tipos). ¡La respuesta de @ Paulo es una imagen mucho más completa!
Ben Hoyt

"Además, la implementación de la aplicación es más fácil, ya que está creando los microservicios independientes por separado y desplegándolos en servidores separados. Esto significa que puede crear e implementar servicios cuando lo desee sin tener que reconstruir el resto de su aplicación". - Cuando tiene varios tipos de implementaciones para diferentes servicios, la implementación en general es más difícil, no más sencilla. Al tener una configuración de CI frente a muchas, una es más fácil de mantener.
Michael

El mejor caso de dividir el monolito en múltiples servicios cuando hay funcionalidades completamente independientes . Si no se ha deshecho de las dependencias primero, puede encontrarse con el peor de los casos: monolito distribuido (acoplamiento estrecho, cambio trivial = cambiar cada servicio). Ver más detalles: Criterio de división de microservicios
uvsmtid

Esta respuesta no es neutral porque puede crear aplicaciones modulares sin microservicios. La base del código no es más pequeña porque aplica una API de servicio en lugar de otra forma de contrato, los servicios EJB o Corba también permiten la modularidad. Por otro lado, la supuesta simplicidad de implementar un binario autónomo que incluye el servidor de aplicaciones tiene un costo de flexibilidad y está sesgada en contra de la separación de roles entre desarrolladores e ingenieros de operaciones / soporte de producción.
Jose Manuel Gomez Alvarez

158

Esta es una pregunta muy importante porque algunas personas se sienten atraídas por todos los rumores en torno a los microservicios, y hay que considerar las compensaciones. Entonces, ¿cuáles son los beneficios y desafíos de los microservicios (en comparación con el modelo monolítico)?

Beneficios

  • Implementación : más agilidad para implementar nuevas versiones de un servicio debido a ciclos más cortos de compilación + prueba + implementación. Además, flexibilidad para emplear configuraciones de seguridad, replicación, persistencia y monitoreo específicas del servicio.
  • Fiabilidad : una falla de microservicio afecta a ese microservicio solo y a sus consumidores, mientras que en el modelo monolítico una falla de servicio puede derribar todo el monolito.
  • Disponibilidad : implementar una nueva versión de un microservicio requiere poco tiempo de inactividad, mientras que implementar una nueva versión de un servicio en el monolito requiere un reinicio generalmente más lento de todo el monolito.
  • Escalabilidad : cada microservicio se puede escalar de forma independiente mediante grupos, clústeres y cuadrículas. Las características de implementación hacen que los microservicios se adapten perfectamente a la elasticidad de la nube.
  • Modificabilidad : más flexibilidad para usar nuevos marcos, bibliotecas, fuentes de datos y otros recursos. Además, los microservicios son componentes modulares de acoplamiento flexible a los que solo se puede acceder a través de sus contratos y, por lo tanto, son menos propensos a convertirse en una gran bola de barro.
  • Gestión : el esfuerzo de desarrollo de aplicaciones se divide entre equipos que son más pequeños y trabajan de forma más independiente.
  • Autonomía de diseño : el equipo tiene libertad para emplear diferentes tecnologías, marcos y patrones para diseñar e implementar cada microservicio, y puede cambiar y volver a implementar cada microservicio de forma independiente.

Desafíos

  • Implementación : hay muchas más unidades de implementación, por lo que hay trabajos, scripts, áreas de transferencia y archivos de configuración más complejos para supervisar la implementación. (Por esa razón, la entrega continua y DevOps son muy deseables para proyectos de microservicios).
  • Rendimiento : es más probable que los servicios necesiten comunicarse a través de la red, mientras que los servicios dentro del monolito pueden beneficiarse de las llamadas locales. (Por esa razón, el diseño debe evitar los microservicios "parlanchines").
  • Modificabilidad : es más probable que los cambios en el contrato afecten a los consumidores implementados en otros lugares, mientras que en el modelo monolítico es más probable que los consumidores estén dentro del monolito y se implementarán al mismo tiempo que el servicio. Además, los mecanismos para mejorar la autonomía, como la consistencia eventual y las llamadas asincrónicas, agregan complejidad a los microservicios.
  • Capacidad de prueba: las pruebas de integración son más difíciles de configurar y ejecutar porque pueden abarcar diferentes microservicios en diferentes entornos de ejecución.
  • Administración : el esfuerzo para administrar las operaciones aumenta porque hay más componentes en tiempo de ejecución, archivos de registro e interacciones punto a punto que supervisar.
  • Uso de memoria : varias clases y bibliotecas a menudo se replican en cada paquete de microservicios y aumenta la huella de memoria general.
  • Autonomía en tiempo de ejecución : en el monolito se ubica la lógica empresarial general. Con los microservicios, la lógica se distribuye entre los microservicios. Entonces, en igualdad de condiciones, es más probable que un microservicio interactúe con otros microservicios a través de la red; esa interacción disminuye la autonomía. Si la interacción entre microservicios implica cambiar datos, la necesidad de un límite transaccional compromete aún más la autonomía. La buena noticia es que para evitar problemas de autonomía en tiempo de ejecución, podemos emplear técnicas como la coherencia eventual, la arquitectura basada en eventos, CQRS, la caché (replicación de datos) y la alineación de microservicios con contextos delimitados por DDD. Estas técnicas no son inherentes a los microservicios, pero han sido sugeridas por prácticamente todos los autores que he leído.

Una vez que entendemos estas compensaciones , hay una cosa más que necesitamos saber para responder a la otra pregunta: ¿cuál es mejor, microservicios o monolito? Necesitamos conocer los requisitos no funcionales (requisitos de atributos de calidad) de la aplicación. Una vez que comprenda la importancia del rendimiento frente a la escalabilidad, por ejemplo, puede sopesar las compensaciones y tomar una decisión de diseño informada.


Oye, respuesta interesante. Me preguntaba si las actuaciones eran tan diferentes o no. Porque los microservicios necesitan intercambios de red donde lo monolítico no. Sin embargo, si tiene un millón de solicitudes, incluso si tiene intercambios de red, el tratamiento se divide por los microservicios donde el monolítico tiene que admitir el tratamiento de solicitud completo, ¿verdad? Si tomamos una autenticación simple, usaría una parte del bloque all donde los microservicios solo darían un poco de una parte. Entonces, ¿el rendimiento de monolithic disminuye tanto en comparación con los microservicios cuando la cantidad de solicitudes aumenta?
Emixam 23

4
No entiendo bien el comentario, pero el punto está en comparar el rendimiento de la misma funcionalidad implementada y desplegada como un conjunto de microservicios versus un conjunto de componentes dentro del mismo monolito. En igualdad de condiciones, en este caso el rendimiento (el tiempo de respuesta específicamente) tiende a ser mejor en el enfoque monolítico debido a la posibilidad de llamadas locales en contraposición a las llamadas remotas requeridas por los microservicios.
Paulo Merson

1
Las cadenas de llamadas largas que involucran múltiples microservicios son un antipatrón que debe evitarse, y existen formas específicas de hacerlo. Por tanto, el tiempo de respuesta no debería empeorar con los microservicios. Solo que probablemente usará más hardware para servir la misma carga. Sin embargo, el costo de hardware adicional le brinda cosas que no obtiene tan fácilmente con los monolitos (si hace bien los microservicios): mejores propiedades de escalamiento horizontal, mayor resistencia y confiabilidad y ciclos de lanzamiento mucho más cortos.
user625488

11

@Luxo da en el clavo. Solo me gustaría ofrecer una pequeña variación y lograr la perspectiva organizativa de la misma. Los microservicios no solo permiten desacoplar las aplicaciones, sino que también pueden ayudar a nivel organizacional. La organización, por ejemplo, podría dividirse en varios equipos donde cada uno puede desarrollarse en un conjunto de microservicios que el equipo puede proporcionar.

Por ejemplo, en tiendas más grandes como Amazon, puede tener un equipo de personalización, un equipo de comercio electrónico, un equipo de servicios de infraestructura, etc. Si desea ingresar a los microservicios, Amazon es un muy buen ejemplo de ello. Jeff Bezos estableció como un mandato para los equipos comunicarse con los servicios de otro equipo si necesitaban acceso a una funcionalidad compartida. Vea aquí para una breve descripción.

Además, los ingenieros de Etsy y Netflix también tuvieron un pequeño debate en la época de los microservicios frente al monolito en Twitter. El debate es un poco menos técnico, pero también puede ofrecer algunas ideas.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.