Al consultar este artículo, podrá tener una mejor idea de la arquitectura de microservicios y cuándo usarla. Además, este artículo consta de los siguientes contenidos.

◼ Abreviaturas del artículo

◼ Introducción

◼ Ecosistema de microservicios

◼ Arquitectura monolítica frente a arquitectura de microservicios

◼ Desafíos en Microservicios

◼ Cuándo usar Microservicios

abreviaturas

• API: interfaz de programación de aplicaciones
• MS: Microservicio
• NoSQL: no solo SQL
• RTE: Entorno de tiempo de ejecución

La arquitectura de microservicios es un enfoque para el desarrollo de aplicaciones en el que una aplicación grande se construye como un conjunto de servicios modulares (esto significa que (microservicio) es un tipo de arquitectura de aplicación donde la aplicación se desarrolla como una colección de servicios). Cada módulo admite un objetivo comercial específico y utiliza una interfaz simple y bien definida para comunicarse con otros conjuntos de servicios. Además, existe un mínimo indispensable de servicios de gestión centralizados, que pueden estar escritos en diferentes lenguajes de programación, como Java, Python, etc., y utilizar diferentes tecnologías de almacenamiento de datos, como relacional y NoSQL, en la arquitectura de microservicios.

Hay algunas funciones/características clave de los microservicios de la siguiente manera.

• Altamente mantenible y comprobable
• Acoplamiento flexible (comunicación a través de una interfaz)
• Desplegable de forma independiente
• Organizado en torno a las capacidades empresariales.
• Propiedad de un equipo pequeño (equipo multifuncional)

En general, el sistema de microservicios contiene las siguientes entidades enumeradas. Algunas de estas entidades son fases en el desarrollo de software estándar y otras son procesos específicos de microservicios que proporcionarán la columna vertebral para un sistema de microservicios eficiente.

Equilibrador de carga

La principal responsabilidad del equilibrador de carga es distribuir la carga entrante entre muchas instancias de microservicios. Principalmente hay 2 tipos de balanceadores de carga llamados descubrimiento de cliente (balanceador de carga del lado del cliente) y descubrimiento de servidor (balanceador de carga del lado del servidor). En el descubrimiento del cliente, el cliente se comunica con el registro del servicio y equilibra la carga. Debido a eso, el cliente debe estar al tanto del registro del servicio. En el descubrimiento del servidor, el cliente se comunica con el balanceador de carga y el balanceador de carga se comunica con el registro del servicio. Por lo tanto, el servicio de atención al cliente no necesita conocer el registro del servicio. Al observar los siguientes diagramas, puede comprender mejor estos 2 tipos de balanceador de carga.

Servidor de descubrimiento de servicios

La funcionalidad de descubrimiento de servicios permite que los microservicios se registren automáticamente al inicio en lugar de realizar un seguimiento manual de los microservicios implementados actualmente y qué hosts y puertos necesitamos. Por lo tanto, si MS1 quiere hablar con MS2, en primer lugar, MS1 obtiene los detalles del servicio de registro que pertenece al paisaje y luego habla con MS2. Además, cuando hay otro MS llamado MS3 que ha estado activo o inactivo en el mismo entorno, el servicio de registro se actualizará automáticamente.

Puerta de enlace API

API Gateway es un servidor. Es un único punto de entrada a un sistema. API Gateway encapsula la arquitectura del sistema interno. Proporciona una API que se adapta a cada cliente. También tiene otras responsabilidades, como la autenticación, la supervisión, el equilibrio de carga, el almacenamiento en caché, la configuración y gestión de solicitudes y el manejo de respuestas estáticas. API Gateway también es responsable del enrutamiento de solicitudes, la composición y la traducción de protocolos. Todas las solicitudes realizadas por el cliente pasan por API Gateway. Después de eso, API Gateway enruta las solicitudes al microservicio apropiado.

API Gateway maneja la solicitud de una de dos maneras:

• Enrutó o envió las solicitudes al servicio adecuado.
• Desplegar (difundir) una solicitud a varios servicios.

Ahora sabemos que hay una gran cantidad de microservicios que se ejecutan en diferentes nodos en el mismo ecosistema. Por lo tanto, es esencial monitorearlos juntos en un solo sistema. El panel de Hystrix y el panel de administración Spring Boot son algunos ejemplos de herramientas de monitoreo. Hay cinco principios de monitoreo de microservicios de la siguiente manera:

• Supervise los contenedores y lo que hay dentro de ellos.
• Alerta sobre el desempeño del servicio.
• Monitoree los servicios que son elásticos y de múltiples ubicaciones.
• Supervisar las API.
• Supervisar la estructura organizativa.

Cuando implementamos microservicios, se ejecutan en diferentes RTE, como JRE y Node.js, ya que la implementación de los microservicios se puede realizar utilizando diferentes tecnologías. Además, sabe que estos microservicios se implementan de manera políglota. Por lo tanto, los nodos no conocen el RTE del microservicio implementado y debemos instalarlo manualmente en cada nodo. Pero cuando se trata de contenerización, empaquetamos nuestro RTE con nuestro microservicio. Por lo tanto, podemos ejecutar los microservicios en todas partes sin considerar el RTE y podemos administrar y actualizar estos servicios fácilmente.

Cortacircuitos

Es una entidad muy importante en el ecosistema de microservicios. La mayoría de las veces esto se define como un patrón. Para fines de comprensión, esto es bastante similar al disyuntor de su hogar. Te protege del desastre y detiene la propagación del problema que surgió. El mismo escenario está ocurriendo aquí (disyuntor en MS) con respecto a los microservicios. Supongamos que el cliente envía una solicitud al microservicio del proveedor y mientras llega la respuesta hay un problema de conexión. Debido a que el cliente está esperando una respuesta durante mucho tiempo y también podría afectar a otros servicios. Desde la arquitectura del interruptor automático, se descarta el canal problemático y se resuelve el problema de espera anterior. Además, hay tres estados diferentes de interruptor de circuito llamados cerrados, Abierto y Medio Abierto.

Arquitectura monolítica frente a arquitectura de microservicios

Precio

• Monolítico: más alto una vez que el proyecto escala
• Microservicio: más alto en la primera etapa de desarrollo

• Monolítico: un código base y una base de datos unidos para todo el producto
• Microservicio: Múltiples archivos de código; cada servicio maneja una base y un almacenamiento de datos

• Monolítico: se debe implementar todo el código base
• Microservicio: cada microservicio se implementa individualmente

• Monolítico: la misma pila de código
• Microservicio: diferentes pilas (lenguaje, entorno de tiempo de ejecución, etc.)

Hay algunos desafíos cuando tratamos con microservicios de la siguiente manera.

• Comunicación entre procesos (a través de la red)
• Transacciones distribuidas
• Una gran cantidad de servicios
• Requiere más automatización

Ahora tenemos una buena comprensión de los microservicios y sus desafíos. Veamos qué escenarios son adecuados para ir con microservicios.

• La empresa quiere crear un código limpio y legible de inmediato y evitar deudas técnicas.
• La empresa cuenta con recursos humanos para el desarrollo de microservicios
• La empresa prioriza las ganancias a largo plazo sobre los beneficios a corto plazo
• Un equipo de desarrolladores utiliza diferentes pilas de tecnología y herramientas.
• La plataforma tiene que ser altamente escalable y expandirse a diferentes mercados.