Creación de microservicios: comunicación entre procesos en una arquitectura de microservicios

Chris Richardson

Editor – Esta serie de siete artículos ya está completa:

1. Introducción a los microservicios
2. Creación de microservicios: uso de una puerta de enlace de API
3. Creación de microservicios: comunicación entre procesos en una arquitectura de microservicios (este artículo)
4. Descubrimiento de servicios en una arquitectura de microservicios
5. Gestión de datos basada en eventos para microservicios
6. Cómo elegir una estrategia de despliegue de microservicios
7. Refactorización de un monolito en microservicios

También puede descargar la colección completa de artículos, junto con información sobre cómo implementar microservicios con NGINX Plus, en formato de libro electrónico: «Microservicios: del diseño a la implementación». Asimismo, consulte la nueva página de soluciones de microservicios.

Este es el tercer artículo de nuestra serie sobre la creación de aplicaciones con una arquitectura de microservicios. El primer artículo presenta el patrón de arquitectura de microservicios, lo compara con el patrón de arquitectura monolítica y analiza las ventajas y desventajas de utilizar microservicios. El segundo artículo describe cómo los clientes de una aplicación se comunican con los microservicios a través de un intermediario conocido como puerta de enlace de API. En este artículo, analizamos cómo se comunican entre sí los servicios de un sistema. El cuarto artículo explora el problema estrechamente relacionado del descubrimiento de servicios.

Introducción

En una aplicación monolítica, los componentes se invocan entre sí mediante llamadas a métodos o funciones del lenguaje. En cambio, una aplicación basada en microservicios es un sistema distribuido que se ejecuta en varias máquinas. Cada instancia de servicio suele ser un proceso. Por consiguiente, como muestra el siguiente diagrama, los servicios deben interactuar mediante un mecanismo de comunicación entre procesos (IPC).

Más adelante analizaremos tecnologías de IPC específicas, pero antes examinemos varias cuestiones de diseño.

Estilos de interacción

Al seleccionar un mecanismo de IPC para un servicio, conviene pensar primero en cómo interactúan los servicios. Existen diversos estilos de interacción entre cliente y servicio. Se pueden clasificar según dos dimensiones. La primera dimensión es si la interacción es de uno a uno o de uno a muchos:

• Uno a uno – Cada solicitud del cliente es procesada por una única instancia del servicio.
• Uno a muchos – Cada solicitud es procesada por varias instancias de servicio.

La segunda dimensión es si la interacción es síncrona o asíncrona:

• Síncrona – El cliente espera una respuesta rápida del servicio y puede incluso bloquearse mientras espera.
• Asíncrono – El cliente no se bloquea mientras espera una respuesta y, si la hay, no tiene por qué enviarse inmediatamente.

La siguiente tabla muestra los distintos estilos de interacción.

Existen los siguientes tipos de interacciones uno a uno:

• Solicitud/respuesta – Un cliente realiza una solicitud a un servicio y espera una respuesta. El cliente espera que la respuesta llegue en un plazo razonable. En una aplicación basada en hilos, el hilo que realiza la solicitud podría incluso bloquearse mientras espera.
• Notificación (también conocida como solicitud unidireccional) – Un cliente envía una solicitud a un servicio, pero no se espera ni se envía ninguna respuesta.
• Solicitud/respuesta asíncrona – Un cliente envía una solicitud a un servicio, que responde de forma asíncrona. El cliente no se bloquea mientras espera y está diseñado partiendo de la premisa de que la respuesta puede tardar en llegar.

Existen los siguientes tipos de interacciones de uno a muchos:

• Publicación/suscripción – Un cliente publica un mensaje de notificación, que consumen cero o más servicios interesados.
• Publicación/respuestas asíncronas – Un cliente publica un mensaje de solicitud y, a continuación, espera durante un tiempo determinado las respuestas de los servicios interesados.

Normalmente, cada servicio utiliza una combinación de estos estilos de interacción. Para algunos servicios, basta con un único mecanismo de IPC. Otros servicios pueden necesitar una combinación de mecanismos de IPC. El siguiente diagrama muestra cómo podrían interactuar los servicios de una aplicación de solicitud de taxis cuando el usuario solicita un trayecto.

Los servicios utilizan una combinación de notificaciones, solicitud/respuesta y publicación/suscripción. Por ejemplo, el smartphone del pasajero envía una notificación al servicio de gestión de viajes para solicitar que lo recojan. Este servicio comprueba que la cuenta del pasajero esté activa mediante una solicitud/respuesta al servicio de pasajeros. A continuación, crea el viaje y utiliza el modelo de publicación/suscripción para notificarlo a otros servicios, incluido el de asignación, que localiza a un conductor disponible.

Ahora que hemos analizado los estilos de interacción, veamos cómo definir las API.

Definición de API

La API de un servicio es un contrato entre el servicio y sus clientes. Independientemente del mecanismo de IPC que elija, es importante definir con precisión la API de un servicio mediante algún tipo de lenguaje de definición de interfaces (IDL). Incluso hay buenos argumentos a favor de adoptar un enfoque API-first para definir servicios. El desarrollo de un servicio comienza redactando la definición de la interfaz y revisándola con los desarrolladores de los clientes. El servicio no se implementa hasta después de haber perfeccionado de forma iterativa la definición de la API. Realizar este diseño de antemano aumenta las probabilidades de crear un servicio que satisfaga las necesidades de sus clientes.

Como verá más adelante en este artículo, la naturaleza de la definición de la API depende del mecanismo de IPC que utilice. Si utiliza mensajería, la API consta de los canales y los tipos de mensajes. Si utiliza HTTP, la API consta de las URL y los formatos de solicitud y respuesta. Más adelante describiremos con mayor detalle algunos lenguajes de definición de interfaces (IDL).

Evolución de las API

La API de un servicio cambia inevitablemente con el tiempo. En una aplicación monolítica, suele ser sencillo modificar la API y actualizar todos los componentes que la utilizan. En una aplicación basada en microservicios, resulta mucho más difícil, incluso si todos los consumidores de la API son otros servicios de la misma aplicación. Por lo general, no se puede obligar a todos los clientes a actualizarse al mismo tiempo que el servicio. Además, probablemente se implementarán de forma gradual nuevas versiones de un servicio, de modo que las versiones antiguas y nuevas del servicio se ejecutarán simultáneamente. Es importante contar con una estrategia para abordar estas cuestiones.

La forma de gestionar un cambio en una API depende de la magnitud del cambio. Algunos cambios son menores y mantienen la compatibilidad con la versión anterior. Por ejemplo, se pueden añadir atributos a las solicitudes o respuestas. Conviene diseñar los clientes y servicios de modo que respeten el principio de robustez. Los clientes que utilizan una API anterior deberían seguir funcionando con la nueva versión del servicio. El servicio proporciona valores predeterminados para los atributos que faltan en las solicitudes, y los clientes ignoran cualquier atributo adicional de las respuestas. Es importante utilizar un mecanismo de IPC y un formato de mensajería que permitan hacer evolucionar las API fácilmente.

Sin embargo, a veces es necesario realizar cambios importantes e incompatibles en una API. Dado que no se puede obligar a los clientes a actualizarse de inmediato, un servicio debe admitir versiones anteriores de la API durante cierto tiempo. Si se utiliza un mecanismo basado en HTTP, como REST, una opción consiste en incluir el número de versión en la URL. Cada instancia del servicio podría gestionar varias versiones simultáneamente. Otra posibilidad sería desplegar distintas instancias, cada una de las cuales gestionaría una versión concreta.

Gestión de fallos parciales

Como se mencionó en el artículo anterior sobre la puerta de enlace de API<.htmla>, en un sistema distribuido siempre existe el riesgo de que se produzca un fallo parcial. Dado que los clientes y los servicios son procesos independientes, es posible que un servicio no pueda responder a tiempo a la solicitud de un cliente. Un servicio podría no estar disponible debido a un fallo o por tareas de mantenimiento. También podría estar sobrecargado y responder a las solicitudes con extrema lentitud.

Pensemos, por ejemplo, en el escenario de detalles del producto de ese artículo. Imaginemos que el servicio de recomendaciones no responde. Una implementación básica de un cliente podría quedarse bloqueada indefinidamente a la espera de una respuesta. Esto no solo daría lugar a una mala experiencia de usuario, sino que, en muchas aplicaciones, consumiría un recurso valioso, como un hilo. Con el tiempo, el entorno de ejecución se quedaría sin hilos y dejaría de responder, como se muestra en la siguiente figura.

Para evitar este problema, es fundamental que diseñe sus servicios de modo que puedan gestionar los fallos parciales.

Un buen enfoque que se puede seguir es el descrito por Netflix. Entre las estrategias para gestionar los fallos parciales se incluyen:

• Tiempos de espera de red – Nunca bloquee indefinidamente y establezca siempre tiempos de espera al aguardar una respuesta. El uso de tiempos de espera garantiza que los recursos nunca queden ocupados indefinidamente.
• Limitación del número de solicitudes pendientes – Establezca un límite máximo para el número de solicitudes pendientes que un cliente puede tener con un servicio concreto. Si se ha alcanzado el límite, probablemente no tenga sentido realizar más solicitudes, por lo que esos intentos deben fallar de inmediato.
• Patrón de disyuntor – Realice un seguimiento del número de solicitudes correctas y fallidas. Si la tasa de errores supera un umbral configurado, active el disyuntor para que los intentos posteriores fallen de inmediato. Si falla un gran número de solicitudes, esto indica que el servicio no está disponible y que no tiene sentido enviar más solicitudes. Tras un periodo de espera, el cliente debe volver a intentarlo y, si la solicitud se realiza correctamente, cerrar el disyuntor.
• Proporcionar alternativas: ejecute una lógica alternativa cuando falle una solicitud. Por ejemplo, devuelva datos almacenados en caché o un valor predeterminado, como un conjunto vacío de recomendaciones.

Netflix Hystrix es una biblioteca de código abierto que implementa estos y otros patrones. Si utiliza la JVM, debería plantearse seriamente usar Hystrix. Y, si trabaja en un entorno que no utiliza la JVM, debería usar una biblioteca equivalente.

Tecnologías de IPC

Hay muchas tecnologías de IPC diferentes entre las que elegir. Los servicios pueden utilizar mecanismos de comunicación síncrona basados en solicitudes y respuestas, como REST sobre HTTP o Thrift. También pueden utilizar mecanismos de comunicación asíncrona basados en mensajes, como AMQP o STOMP. Asimismo, existe una gran variedad de formatos de mensajes. Los servicios pueden utilizar formatos de texto legibles por humanos, como JSON o XML. También pueden utilizar un formato binario (que es más eficiente), como Avro o Protocol Buffers. Más adelante veremos los mecanismos de IPC síncronos, pero primero abordemos los mecanismos de IPC asíncronos.

Comunicación asíncrona basada en mensajes

Cuando se utiliza la mensajería, los procesos se comunican intercambiando mensajes de forma asíncrona. Un cliente realiza una solicitud a un servicio enviándole un mensaje. Si se espera que el servicio responda, lo hace enviando otro mensaje al cliente. Dado que la comunicación es asíncrona, el cliente no se bloquea mientras espera una respuesta. En su lugar, el cliente se implementa partiendo de la premisa de que la respuesta no se recibirá de inmediato.

Un mensaje consta de encabezados (metadatos como el remitente) y un cuerpo. Los mensajes se intercambian a través de canales. Cualquier número de productores puede enviar mensajes a un canal. Del mismo modo, cualquier número de consumidores puede recibir mensajes de un canal. Hay dos tipos de canales: punto a punto y publicación-suscripción. Un canal punto a punto entrega un mensaje exactamente a uno de los consumidores que leen el canal. Los servicios utilizan canales punto a punto para los estilos de interacción uno a uno descritos anteriormente. Un canal de publicación-suscripción entrega cada mensaje a todos los consumidores conectados. Los servicios utilizan canales de publicación-suscripción para los estilos de interacción uno a muchos descritos anteriormente.

El siguiente diagrama muestra cómo podría utilizar la aplicación de solicitud de taxis los canales de publicación-suscripción.

El servicio de gestión de trayectos notifica a los servicios interesados, como el despachador, que hay un nuevo trayecto escribiendo un mensaje de trayecto creado en un canal de publicación-suscripción. El despachador busca un conductor disponible y notifica a los demás servicios escribiendo un mensaje de conductor propuesto en un canal de publicación-suscripción.

Hay muchos sistemas de mensajería entre los que elegir. Debes escoger uno que sea compatible con diversos lenguajes de programación. Algunos sistemas de mensajería admiten protocolos estándar como AMQP y STOMP. Otros utilizan protocolos propietarios, pero documentados. Existe una gran cantidad de sistemas de mensajería de código abierto entre los que elegir, como RabbitMQ, Apache Kafka, Apache ActiveMQ y NSQ. A grandes rasgos, todos admiten algún tipo de mensajes y canales. Todos aspiran a ser fiables, ofrecer un alto rendimiento y ser escalables. Sin embargo, existen diferencias significativas en los detalles del modelo de mensajería de cada bróker.

El uso de la mensajería ofrece muchas ventajas:

• Desacopla el cliente del servicio – Un cliente realiza una solicitud simplemente enviando un mensaje al canal correspondiente. El cliente desconoce por completo las instancias del servicio. No necesita utilizar ningún mecanismo de descubrimiento para determinar la ubicación de una instancia del servicio.
• Almacenamiento en búfer de mensajes: con un protocolo síncrono de solicitud/respuesta, como HTTP, tanto el cliente como el servicio deben estar disponibles durante todo el intercambio. En cambio, un bróker de mensajes pone en cola los mensajes enviados a un canal hasta que el consumidor pueda procesarlos. Esto significa, por ejemplo, que una tienda en línea puede aceptar pedidos de los clientes incluso cuando el sistema de gestión de pedidos funciona con lentitud o no está disponible. Los mensajes de los pedidos simplemente se ponen en cola.
• Interacciones flexibles entre cliente y servicio – La mensajería admite todos los estilos de interacción descritos anteriormente.
• Comunicación explícita entre procesos – Los mecanismos basados en RPC intentan que invocar un servicio remoto parezca lo mismo que llamar a un servicio local. Sin embargo, debido a las leyes de la física y a la posibilidad de que se produzcan fallos parciales, en realidad son bastante diferentes. La mensajería pone claramente de manifiesto estas diferencias para evitar que los desarrolladores se dejen llevar por una falsa sensación de seguridad.

Sin embargo, el uso de la mensajería presenta algunas desventajas:

• Complejidad operativa adicional – El sistema de mensajería es otro componente más del sistema que debe instalarse, configurarse y gestionarse. Es fundamental que el bróker de mensajes tenga una alta disponibilidad; de lo contrario, la fiabilidad del sistema se verá afectada.
• Complejidad de implementar una interacción basada en solicitud/respuesta – La interacción de tipo solicitud/respuesta requiere cierto trabajo de implementación. Cada mensaje de solicitud debe contener un identificador del canal de respuesta y un identificador de correlación. El servicio escribe en el canal de respuesta un mensaje que contiene el identificador de correlación. El cliente utiliza dicho identificador para asociar la respuesta con la solicitud. A menudo resulta más sencillo utilizar un mecanismo de IPC que admita directamente el modelo de solicitud/respuesta.

Ahora que hemos visto cómo usar la IPC basada en mensajería, examinemos la IPC basada en solicitudes y respuestas.

IPC síncrona de solicitud/respuesta

Cuando se utiliza un mecanismo de IPC síncrono basado en solicitudes y respuestas, un cliente envía una solicitud a un servicio. El servicio procesa la solicitud y devuelve una respuesta. En muchos clientes, el hilo que realiza la solicitud se bloquea mientras espera una respuesta. Otros clientes pueden utilizar código de cliente asíncrono y basado en eventos, quizá encapsulado mediante Futures u Observables de Rx. Sin embargo, a diferencia de lo que ocurre al utilizar mensajería, el cliente presupone que la respuesta llegará en un plazo razonable. Existen numerosos protocolos entre los que elegir. Dos de los más populares son REST y Thrift. Veamos primero REST.

REST

Hoy en día está de moda desarrollar API siguiendo el estilo RESTful. REST es un mecanismo de comunicación entre procesos (IPC) que utiliza HTTP (casi siempre). Un concepto clave de REST es el recurso, que normalmente representa un objeto de negocio, como un cliente o un producto, o bien una colección de objetos de negocio. REST utiliza los verbos HTTP para manipular recursos, a los que se hace referencia mediante una URL. Por ejemplo, una solicitud GET devuelve la representación de un recurso, que puede adoptar la forma de un documento XML o un objeto JSON. Una solicitud POST crea un recurso nuevo y una solicitud PUT actualiza un recurso. En palabras de Roy Fielding, el creador de REST:

«REST proporciona un conjunto de restricciones arquitectónicas que, cuando se aplican en su totalidad, favorecen la escalabilidad de las interacciones entre componentes, la generalidad de las interfaces, el despliegue independiente de los componentes y el uso de componentes intermediarios para reducir la latencia de las interacciones, garantizar la seguridad y encapsular los sistemas heredados».

El siguiente diagrama muestra una de las formas en que la aplicación para pedir taxis podría utilizar REST.

El smartphone del pasajero solicita un viaje mediante una petición POST al recurso /trips del servicio de gestión de viajes. Este servicio procesa la petición enviando una petición GET al servicio de gestión de pasajeros para obtener información sobre el pasajero. Tras verificar que el pasajero está autorizado para crear un viaje, el servicio de gestión de viajes crea el viaje y devuelve una respuesta 201 al smartphone.

Muchos desarrolladores afirman que sus API basadas en HTTP son RESTful. Sin embargo, como explica Fielding en esta entrada de blog, no todas lo son realmente. Leonard Richardson (sin parentesco) define un modelo muy útil de madurez de REST que consta de los siguientes niveles.

• Nivel 0 – Los clientes de una API de nivel 0 invocan el servicio realizando solicitudes HTTP POST a su único endpoint URL. Cada solicitud especifica la acción que se debe realizar, el objetivo de la acción (p. ej., el objeto de negocio) y los parámetros necesarios.
• Nivel 1 – Una API de nivel 1 admite el concepto de recursos. Para realizar una acción en un recurso, un cliente envía una solicitud POST que especifica la acción que se debe realizar y los parámetros necesarios.
• Nivel 2 – Una API de nivel 2 utiliza verbos HTTP para realizar acciones: GET para recuperar, POST para crear y PUT para actualizar. Los parámetros de consulta y el cuerpo de la solicitud, si los hay, especifican los parámetros de la acción. Esto permite que los servicios aprovechen la infraestructura web, como el almacenamiento en caché, para las solicitudes GET.
• Nivel 3 – El diseño de una API de nivel 3 se basa en el principio HATEOAS (hipertexto como motor del estado de la aplicación), cuyo nombre resulta bastante desafortunado. La idea básica es que la representación de un recurso devuelta por una solicitud GET contiene enlaces para realizar las acciones permitidas en dicho recurso. Por ejemplo, un cliente puede cancelar un pedido mediante un enlace incluido en la representación del pedido devuelta en respuesta a la solicitud GET enviada para recuperar el pedido. Entre las ventajas de HATEOAS se encuentra el hecho de que ya no es necesario codificar las URL de forma fija en el código del cliente. Otra ventaja es que, dado que la representación de un recurso contiene enlaces para las acciones permitidas, el cliente no tiene que adivinar qué acciones se pueden realizar en un recurso en su estado actual.

Utilizar un protocolo basado en HTTP ofrece numerosas ventajas:

• HTTP es sencillo y conocido.
• Puedes probar una API HTTP desde un navegador utilizando una extensión como Postman o desde la línea de comandos utilizando curl (siempre que se utilice JSON u otro formato de texto).
• Admite directamente la comunicación de tipo solicitud/respuesta.
• HTTP es, por supuesto, compatible con los cortafuegos.
• No requiere un intermediario, lo que simplifica la arquitectura del sistema.

El uso de HTTP presenta algunos inconvenientes:

• Solo admite directamente el modelo de interacción de solicitud/respuesta. Puede utilizar HTTP para las notificaciones, pero el servidor siempre debe enviar una respuesta HTTP.
• Dado que el cliente y el servicio se comunican directamente (sin un intermediario que almacene temporalmente los mensajes), ambos deben estar en ejecución mientras dure el intercambio.
• El cliente debe conocer la ubicación (es decir, la URL) de cada instancia del servicio. Como se explica en el artículo anterior sobre la puerta de enlace de API, este es un problema nada trivial en una aplicación moderna. Los clientes deben utilizar un mecanismo de descubrimiento de servicios para localizar las instancias del servicio.

La comunidad de desarrolladores ha redescubierto recientemente el valor de los lenguajes de definición de interfaces para las API RESTful. Existen varias opciones, entre ellas RAML y Swagger. Algunos IDL, como Swagger, permiten definir el formato de los mensajes de solicitud y respuesta. Otros, como RAML, requieren el uso de una especificación independiente, como JSON Schema. Además de describir las API, los IDL suelen incluir herramientas que generan stubs de cliente y esqueletos de servidor a partir de una definición de interfaz.

Thrift

Apache Thrift es una alternativa interesante a REST. Es un framework para desarrollar RPC clientes y servidores en distintos lenguajes. Thrift proporciona un IDL de estilo C para definir tus API. El compilador de Thrift permite generar stubs del lado del cliente y esqueletos del lado del servidor. El compilador genera código para diversos lenguajes, como C++, Java, Python, PHP, Ruby, Erlang y Node.js.

Una interfaz de Thrift consta de uno o varios servicios. La definición de un servicio es análoga a una interfaz de Java. Se trata de una colección de métodos con tipado fuerte. Los métodos de Thrift pueden devolver un valor (posiblemente void) o definirse como unidireccionales. Los métodos que devuelven un valor implementan el estilo de interacción de solicitud/respuesta. El cliente espera una respuesta y puede lanzar una excepción. Los métodos unidireccionales se corresponden con el estilo de interacción basado en notificaciones. El servidor no envía ninguna respuesta.

Thrift admite varios formatos de mensaje: JSON, binario y binario compacto. El formato binario es más eficiente que JSON porque se descodifica más rápido. Y, como su nombre indica, el binario compacto es un formato que ocupa poco espacio. JSON, por supuesto, es fácil de usar tanto para las personas como para los navegadores. Thrift también permite elegir entre varios protocolos de transporte, incluidos TCP sin procesar y HTTP. Es probable que TCP sin procesar sea más eficiente que HTTP. Sin embargo, HTTP es compatible con los cortafuegos y resulta fácil de usar tanto para los navegadores como para las personas.

Formatos de mensajes

Ahora que hemos analizado HTTP y Thrift, examinemos la cuestión de los formatos de mensaje. Si utiliza un sistema de mensajería o REST, puede elegir el formato de los mensajes. Otros mecanismos de IPC, como Thrift, podrían admitir únicamente un número reducido de formatos de mensaje, quizá solo uno. En cualquier caso, es importante utilizar un formato de mensaje compatible con varios lenguajes. Aunque actualmente escriba sus microservicios en un único lenguaje, es probable que en el futuro utilice otros.

Existen dos tipos principales de formatos de mensajes: de texto y binarios. Entre los formatos basados en texto se encuentran JSON y XML. Una ventaja de estos formatos es que no solo son legibles para las personas, sino que también son autodescriptivos. En JSON, los atributos de un objeto se representan mediante un conjunto de pares nombre-valor. Del mismo modo, en XML los atributos se representan mediante elementos con nombre y valores. Esto permite que el consumidor de un mensaje seleccione los valores que le interesan e ignore el resto. Por tanto, los cambios menores en el formato de los mensajes pueden mantener fácilmente la compatibilidad con versiones anteriores.

La estructura de los documentos XML se especifica mediante un esquema XML. Con el tiempo, la comunidad de desarrolladores se ha dado cuenta de que JSON también necesita un mecanismo similar. Una opción es utilizar JSON Schema, ya sea de forma independiente o como parte de un IDL como Swagger.

Una desventaja de utilizar un formato de mensajes basado en texto es que los mensajes suelen ser extensos, especialmente en XML. Como los mensajes son autodescriptivos, cada uno contiene los nombres de los atributos además de sus valores. Otro inconveniente es la sobrecarga que supone analizar el texto. Por tanto, puede ser conveniente utilizar un formato binario.

Hay varios formatos binarios entre los que elegir. Si utiliza Thrift RPC, puede usar Thrift binario. Si puede elegir el formato de los mensajes, algunas opciones populares son Protocol Buffers y Apache Avro. Ambos formatos proporcionan un IDL con tipos para definir la estructura de los mensajes. Sin embargo, una diferencia es que Protocol Buffers utiliza campos etiquetados, mientras que un consumidor de Avro necesita conocer el esquema para interpretar los mensajes. Por ello, la evolución de las API es más sencilla con Protocol Buffers que con Avro. Esta entrada de blog ofrece una excelente comparación entre Thrift, Protocol Buffers y Avro.

Resumen

Los microservicios deben comunicarse mediante un mecanismo de comunicación entre procesos. Al diseñar cómo se comunicarán los servicios, hay que tener en cuenta varias cuestiones: cómo interactúan, cómo especificar la API de cada servicio, cómo evolucionar las API y cómo gestionar los fallos parciales. Los microservicios pueden utilizar dos tipos de mecanismos de IPC: la mensajería asíncrona y el modelo síncrono de solicitud/respuesta. En el próximo artículo de la serie, analizaremos el problema del descubrimiento de servicios en una arquitectura de microservicios.

Editor – Esta serie de siete artículos ya está completa:

1. Introducción a los microservicios
2. Creación de microservicios: uso de una puerta de enlace de API
3. Creación de microservicios: comunicación entre procesos en una arquitectura de microservicios (este artículo)
4. Descubrimiento de servicios en una arquitectura de microservicios
5. Gestión de datos basada en eventos para microservicios
6. Cómo elegir una estrategia de despliegue de microservicios
7. Refactorización de un monolito en microservicios

También puede descargar la colección completa de artículos, junto con información sobre cómo implementar microservicios con NGINX Plus, en formato de libro electrónico: «Microservicios: del diseño a la implementación».

El bloguero invitado Chris Richardson es el fundador de la plataforma original CloudFoundry.com, una de las primeras PaaS (plataforma como servicio) de Java para Amazon EC2. Actualmente asesora a organizaciones para mejorar la forma en que desarrollan e implementan aplicaciones. También publica regularmente sobre microservicios en http://microservices.io.

Sobre el autor

Chris Richardson

Más artículos de Chris Richardson