Introducción a la Comunicación en la Arquitectura basada en Microservicios

El mayor desafío al cambiar de una aplicación monolítica a una aplicación basada en microservicios radica en cambiar el mecanismo de comunicación.

Una conversión directa de llamadas de método en proceso a llamadas RPC a servicios provocará una comunicación habladora y no eficiente que no funcionará bien en entornos distribuidos. Los desafíos de diseñar un sistema distribuido correctamente son lo suficientemente conocidos como para que haya incluso un canon conocido como las Falacias de la computación distribuida que enumera los supuestos que los desarrolladores suelen hacer al pasar de diseños monolíticos a diseños distribuidos.

No hay una solución, sino varias. Una solución consiste en aislar los microservicios de negocio tanto como sea posible y utilizar la comunicación asincrónica entre los microservicios internos.

Una aplicación basada en microservicios es un sistema distribuido que se ejecuta en múltiples procesos o servicios, generalmente incluso en múltiples servidores o hosts. Cada instancia de servicio suele ser un proceso. Por lo tanto, los servicios deben interactuar usando un protocolo de comunicación entre procesos como HTTP, AMQP o un protocolo binario como TCP, dependiendo de la naturaleza de cada servicio. La comunidad de microservicios promueve la filosofía de “smart endpoints and dumb pipes”. Este eslogan fomenta un diseño lo más desacoplado posible entre microservicios y lo más coherente posible dentro de un solo microservicio. Cada microservicio posee sus propios datos y su propia lógica de dominio. Pero los microservicios que componen una aplicación de extremo a extremo generalmente se coreografían simplemente mediante el uso de comunicaciones REST en lugar de protocolos complejos como WS- * y comunicaciones flexibles impulsadas por eventos en lugar de orquestadores de procesos empresariales centralizados.

Los dos protocolos de uso común son la solicitud/respuesta HTTP con las API (cuando se consulta, sobre todo) y la mensajería asincrónica ligera al comunicar actualizaciones a través de múltiples microservicios. Estos se explican con más detalle en las siguientes secciones.

Tipos de comunicación

El cliente y los servicios pueden comunicarse a través de diferentes tipos de comunicación, cada uno dirigido a un escenario y objetivos diferentes. Inicialmente, esos tipos de comunicaciones se pueden clasificar en dos ejes.

El primer eje define si el protocolo es síncrono o asíncrono:

Protocolo sincrónico: HTTP es un protocolo síncrono. El cliente envía una solicitud y espera una respuesta del servicio. Eso es independiente de la ejecución del código del cliente que podría ser síncrono (el subproceso está bloqueado) o asíncrono (el subproceso no está bloqueado y la respuesta finalmente recibirá una devolución de llamada). El punto importante aquí es que el protocolo (HTTP/HTTPS) es síncrono y el código del cliente solo puede continuar su tarea cuando recibe la respuesta del servidor HTTP.

Protocolo asincrónico: Otros protocolos como AMQP (un protocolo compatible con muchos sistemas operativos y entornos de nube) usan mensajes asincrónicos. El código del cliente o el remitente del mensaje generalmente no espera una respuesta. Simplemente envía el mensaje como cuando envía un mensaje a una cola RabbitMQ o cualquier otro agente de mensajes.

El segundo eje define si la comunicación tiene un receptor único o múltiples receptores:

Receptor individual: Cada solicitud debe ser procesada por exactamente un receptor o servicio. Un ejemplo de esta comunicación es el patrón Command.

Múltiples receptores: Cada solicitud puede ser procesada por cero a múltiples receptores. Este tipo de comunicación debe ser asíncrono. Un ejemplo es el mecanismo de publicación/suscripción utilizado en patrones como la arquitectura controlada por eventos. Se basa en una interfaz de bus de eventos o un intermediario de mensajes cuando se propagan actualizaciones de datos entre múltiples microservicios a través de eventos. Por lo general, se implementa a través de un bus de servicio o un artefacto similar como el Bus de servicio de Azure mediante temas y suscripciones.

Una aplicación basada en microservicios a menudo utilizará una combinación de estos estilos de comunicación. El tipo más común es la comunicación de receptor único con un protocolo síncrono como HTTP/HTTPS cuando se invoca un servicio HTTP API web normal. Los microservicios también suelen usar protocolos de mensajería para la comunicación asincrónica entre microservicios.

Es bueno conocer estos ejes para que tenga claridad sobre los posibles mecanismos de comunicación, pero no son las preocupaciones importantes al crear microservicios. Ni la naturaleza asincrónica de la ejecución de subprocesos del cliente ni la naturaleza asincrónica del protocolo seleccionado son los puntos importantes al integrar microservicios. Lo importante es poder integrar sus microservicios de manera asíncrona mientras se mantiene la independencia de los microservicios.

Esperemos te haya gustado el artículo, déjanos tus comentarios y puedes invitarme un café.