¿Qué es la arquitectura de microservicios?

La arquitectura de microservicios, principalmente la descomposición de la capa intermedia, divide el sistema en muchas aplicaciones pequeñas (los microservicios se pueden implementar en diferentes servidores o en diferentes contenedores en el mismo servidor). Cuando una falla de la aplicación no afectará a otras aplicaciones, la carga de una sola aplicación no afectará a otras aplicaciones. Los marcos representativos incluyen Spring Cloud, Dubbo, etc.

Martin Fowler, el padre de los microservicios, ofrece una visión general de los microservicios de la siguiente manera: Aunque actualmente no existe una definición precisa de microservicios en la industria, sí se puede definir este estilo arquitectónico). Pero en términos generales, la arquitectura de microservicios es un patrón arquitectónico o un estilo arquitectónico que aboga por dividir una única aplicación en un conjunto de pequeños servicios. Cada servicio se ejecuta en su propio proceso independiente. Coordine y coopere entre sí para brindar a los usuarios lo último. valor. Los servicios se comunican entre sí mediante un mecanismo de comunicación ligero (normalmente una API RESTful basada en HTTP). Cada servicio se basa en un negocio específico y se puede implementar de forma independiente en entornos de producción, entornos similares a los de producción, etc. Además, se debe evitar en la medida de lo posible un mecanismo de gestión de servicios unificado y centralizado. Para un servicio específico, se deben seleccionar lenguajes y herramientas adecuados de acuerdo con el contexto empresarial para lograr una gestión centralizada muy ligera. para coordinar estos servicios. Los servicios se pueden escribir en diferentes idiomas y se pueden utilizar diferentes almacenes de datos.

Seis patrones de arquitectura de microservicios comunes:

1. Patrón de diseño de microservicios del agregador

El agregador llama a múltiples servicios para implementar la función que necesita la aplicación. Puede ser una página web sencilla que procese y muestre los datos recuperados. También puede ser un microservicio combinado de nivel superior que agrega lógica empresarial a los datos recuperados y luego los publica en un nuevo microservicio, lo que está en línea con el principio DRY. Además, cada servicio tiene su propia caché y base de datos. Si el agregador es un servicio de composición, también tiene su propia caché y base de datos. Los agregadores pueden escalar de forma independiente a lo largo de los ejes X y Z.

2. Patrón de diseño de microservicio proxy

Esta es una variante del patrón de agregación. En este caso, el cliente no agrega datos, sino que los llamará en función de las diferencias en las necesidades comerciales. . Diferentes microservicios. El proxy puede simplemente delegar la solicitud o puede realizar un trabajo de transformación de datos.

3. Patrón de diseño de microservicio encadenado

Este patrón generará una respuesta fusionada después de recibir la solicitud. En este caso, después de que el servicio A reciba la solicitud, se comunicará con el servicio B y de manera similar. , el servicio B se comunicará con el servicio C. Todos los servicios utilizan mensajería sincrónica. El cliente se bloqueará hasta completar toda la cadena de llamadas. Por lo tanto, la cadena de llamadas de servicio no debe ser demasiado larga para evitar que el cliente espere mucho tiempo.

4. Patrón de diseño de microservicios de sucursal

Este patrón es una extensión del patrón agregador, que permite llamar a dos cadenas de microservicios al mismo tiempo.

5. Patrón de diseño de microservicios para compartir datos

La autonomía es uno de los principios de diseño de los microservicios, lo que significa que los microservicios son servicios completos. Pero al refactorizar una "aplicación monolítica" existente, la desnormalización de la base de datos SQL puede provocar duplicación e inconsistencia de los datos. Por lo tanto, este patrón de diseño se puede utilizar durante la etapa de transición de una aplicación monolítica a una arquitectura de microservicio. En este caso, algunos microservicios pueden compartir caché y almacenamiento de base de datos. Sin embargo, esto sólo es posible si existe una fuerte relación de acoplamiento entre los dos servicios. Este es un antipatrón para nuevas aplicaciones basadas en microservicios.

6. Patrón de diseño de microservicio de mensajería asincrónica

Aunque el patrón de diseño REST es muy popular, es sincrónico y puede provocar bloqueos.

Por lo tanto, algunas arquitecturas basadas en microservicios pueden optar por utilizar colas de mensajes en lugar de solicitudes/respuestas REST.