Comunicación entre servicios en una configuración de microservicios

Este documento es el tercero de una serie de cuatro partes sobre el diseño, la compilación y la implementación de microservicios. En esta serie, se describen los diversos elementos de una arquitectura de microservicios. En ella, se incluye información de los beneficios y las desventajas del patrón de arquitectura de microservicios, y cómo aplicarlo.

1. Introducción a los microservicios
2. Refactorización de aplicaciones monolíticas en microservicios
3. Comunicación entre servicios en una configuración de microservicios (este documento)
4. Seguimiento distribuido en una aplicación de microservicios

Esta serie está dirigida a desarrolladores y arquitectos de aplicaciones que diseñan y, luego, implementan la migración para refactorizar una aplicación monolítica en una aplicación de microservicios.

En este documento, se describen las compensaciones entre la mensajería asíncrona en comparación con las API síncronas en los microservicios. En el documento, se explica la deconstrucción de una aplicación monolítica y se muestra cómo convertir una solicitud síncrona en la aplicación original en un flujo asíncrono en la nueva configuración basada en microservicios. Esta conversión incluye la implementación de transacciones distribuidas entre servicios.

Aplicación de ejemplo

En este documento, utilizarás una aplicación de comercio electrónico precompilada llamada Online Boutique. La aplicación implementa flujos de comercio electrónico básicos, como explorar elementos, agregar productos a un carrito y confirmar la compra. La aplicación también presenta recomendaciones y anuncios basados en la selección del usuario.

Separación lógica del servicio

En este documento, se aísla el servicio de pagos del resto de la aplicación. Todos los flujos en la aplicación Online Boutique original son síncronos. En la aplicación refactorizada, el proceso de pago se convierte en un flujo asíncrono. Por lo tanto, cuando recibes una solicitud de compra, en lugar de procesarla de inmediato, proporcionas una confirmación de “solicitud recibida” al usuario. En segundo plano, se activa una solicitud asíncrona en el servicio de pago para procesar el pago.

Antes de mover los datos de pago y la lógica a un servicio nuevo, debes aislar los datos y la lógica de pago de la aplicación monolítica. Cuando aíslas los datos de pago y la lógica en la aplicación monolítica, es más fácil refactorizar tu código en la misma base de código si obtienes límites de servicio de pago incorrectos (lógica o datos empresariales).

Los componentes de la aplicación monolítica de este documento ya están modularizados, por lo que están aislados unos de otros. Si tu aplicación tiene interdependencias más estrictas, debes aislar la lógica empresarial y crear clases y módulos separados. También debes separar las dependencias de bases de datos en sus propias tablas y crear clases de repositorios separadas. Cuando separas las dependencias de bases de datos, puede haber relaciones de claves externas entre las tablas divididas. Sin embargo, después de separar por completo el servicio de la aplicación monolítica, estas dependencias dejan de existir y el servicio interactúa de forma exclusiva a través de la API predefinida o los contratos de RPC.

Transacciones distribuidas y fallas parciales

Después de aislar el servicio y separarlo de la aplicación monolítica, se distribuye una transacción local en el sistema monolítico original entre varios servicios. En la implementación de la aplicación monolítica, el proceso de confirmación de la compra siguió la secuencia que se muestra en el siguiente diagrama.

Figura 1. Una secuencia de proceso de confirmación de la compra en la implementación de una aplicación monolítica.

En la figura 1, cuando la aplicación recibe una orden de compra, el controlador de confirmación de la compra llama al servicio de pago y ordena al servicio procesar el pago y guardar el pedido, respectivamente. Si algún paso falla, la transacción de la base de datos se puede revertir. Considera una situación de ejemplo en la que la solicitud de pedido se almacena de forma correcta en la tabla de pedidos, pero el pago falla. En este caso, toda la transacción se revierte y la entrada se quita de la tabla de pedidos.

Después de separar el pago en su propio servicio, el flujo de confirmación de la compra modificado es similar al siguiente diagrama:

Figura 2. Una secuencia de proceso de confirmación de la compra después de que el pago se separa en su propio servicio.

En la figura 2, la transacción ahora abarca varios servicios y sus bases de datos correspondientes, por lo que es una transacción distribuida. Cuando recibe una solicitud de pedido, el controlador de confirmación de la compra guarda los detalles del pedido en su base de datos local y llama a otros servicios para completar el pedido. Estos servicios, como el servicio de pago, pueden usar su propia base de datos local para almacenar detalles sobre el pedido.

En la aplicación monolítica, el sistema de bases de datos garantiza que las transacciones locales sean atómicas. Sin embargo, de forma predeterminada, el sistema basado en microservicios, que tiene una base de datos independiente para cada servicio, no tiene un coordinador de transacciones global que abarque las diferentes bases de datos. Debido a que las transacciones no están coordinadas de forma central, una falla en el procesamiento de un pago no revierte los cambios confirmados en el servicio de pedidos. Por lo tanto, el sistema se encuentra en un estado incoherente.

Los siguientes patrones se usan en general para administrar transacciones distribuidas:

• Protocolo de confirmación en dos fases (2PC): forma parte de una familia de protocolos de consenso. El 2PC coordina la confirmación de una transacción distribuida y mantiene la garantía de atomicidad, coherencia, aislamiento y durabilidad (ACID). El protocolo se divide en las fases de preparación y confirmación. Una transacción se confirma solo si todos los participantes votaron por ella. Si los participantes no llegan a un consenso, se revierte toda la transacción.
• Saga: el patrón Saga consiste en ejecutar transacciones locales dentro de cada microservicio que conforma la transacción distribuida. Un evento se activa al final de cada operación exitosa o con errores. Todos los microservicios involucrados en la transacción distribuida se suscriben a estos eventos. Si los siguientes microservicios reciben un evento exitoso, ejecutan su operación. Si hay una falla, los microservicios anteriores completan acciones de compensación para deshacer cambios. Saga proporciona una vista coherente del sistema, ya que garantiza que cuando se completen todos los pasos, todas las operaciones se realizarán de forma correcta o las acciones de compensación desharán todo el trabajo.

Recomendamos Saga para transacciones de larga duración. En una aplicación basada en microservicios, se esperan llamadas entre servicios y comunicación con sistemas de terceros. Por lo tanto, es mejor diseñar para lograr una coherencia eventual: reintentar los errores recuperables y exponer los eventos de compensación que con el tiempo enmiendan los errores no recuperables.

Existen varias formas de implementar un patrón Saga. Por ejemplo, puedes usar motores de tareas y flujos de trabajo, como Apache Airflow, Apache Camel o Conductor. También puedes escribir tus propios controladores de eventos a través de sistemas basados en Kafka, RabbitMQ o ActiveMQ.

La aplicación Online Boutique usa el servicio de confirmación de la compra para organizar los servicios de pago, envío y notificación por correo electrónico. El servicio de confirmación de la compra también controla el flujo de trabajo del negocio y los pedidos. Como alternativa a compilar tu propio motor de flujo de trabajo, puedes usar un componente de terceros, como Zeebe. Zeebe proporciona un modeler basado en IU. Te recomendamos evaluar con cuidado las opciones para el organizador de microservicios según los requisitos de tu aplicación. Esta elección es una parte fundamental de la ejecución y el escalamiento de tus microservicios.

Aplicación refactorizada

Para habilitar las transacciones distribuidas en la aplicación refactorizada, el servicio de confirmación de la compra controla la comunicación entre el servicio de pago, envío y correo electrónico. El flujo de trabajo del modelo y notación de procesos empresariales (BPMN) utiliza el siguiente flujo:

Figura 3. Un flujo de trabajo de pedidos que ayuda a garantizar las transacciones distribuidas en microservicios típicos.

En el diagrama anterior, se muestra el siguiente flujo de trabajo:

• El servicio de frontend recibe una solicitud de pedido y, luego, hace lo siguiente:
  • Envía los artículos del pedido al servicio del carrito. Luego, el servicio del carrito guarda los detalles del pedido (Redis).
  • Redirecciona a la página de confirmación de la compra. El servicio de confirmación de la compra extrae los pedidos del servicio de carrito, establece el estado del pedido como Pending y solicita el pago al cliente.
  • Confirma que el usuario pagó. Una vez que está confirmado, el servicio de confirmación de la compra le indica al servicio de correo electrónico que genere un correo electrónico de confirmación y lo envíe al cliente.
• Luego, el servicio de pago procesa la solicitud.
  • Si la solicitud de pago se realiza de forma correcta, el servicio de pago actualiza el estado del pedido a Complete.
  • Si la solicitud de pago falla, el servicio de pago inicia una transacción de compensación.
    • Se canceló la solicitud de pago.
    • El servicio de frontend cambia el estado del pedido a Failed.
  • Si el servicio de pago no está disponible, el tiempo de espera de la solicitud se agota después de N segundos y el servicio de confirmación de la compra inicia una transacción de compensación.
  • El servicio de frontend cambia el estado del pedido a Failed.

Objetivos

• Implementar la aplicación monolítica de Online Boutique en Google Kubernetes Engine (GKE).
• Valida el flujo de confirmación de la compra de la aplicación monolítica.
• Implementa la versión de microservicios de la aplicación refactorizada de la aplicación monolítica
• Verificar que el nuevo flujo de confirmación de la compra funcione
• Verificar que las transacciones distribuidas y las acciones de compensación funcionen si hay una falla

Costos

En este documento, usarás los siguientes componentes facturables de Google Cloud:

• GKE
• Cloud SQL
• Container Registry

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios. Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.

Cuando termines esta guía, puedes borrar los recursos que creaste para evitar que se sigan facturando. Para obtener más información, consulta Realiza una limpieza.

Antes de comenzar

1. En la página del selector de proyectos de la consola de Google Cloud, selecciona o crea un proyecto de Google Cloud.

   Ir al selector de proyectos

2. Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.

3. En la consola de Google Cloud, activa Cloud Shell.

   Activar Cloud Shell

   En la parte inferior de la consola de Google Cloud, se inicia una sesión de Cloud Shell en la que se muestra una ventana de línea de comandos. Cloud Shell es un entorno de shell con Google Cloud CLI ya instalada y con valores ya establecidos para el proyecto actual. La sesión puede tardar unos segundos en inicializarse.

4. Habilita las APIs para Compute Engine, Google Kubernetes Engine, Cloud SQL, Artifact Analysis y Container Registry:

    gcloud services enable \
        compute.googleapis.com \
        sql-component.googleapis.com \
        servicenetworking.googleapis.com\
        container.googleapis.com \
        containeranalysis.googleapis.com \
        containerregistry.googleapis.com \
        sqladmin.googleapis.com
   

5. Exporta las siguientes variables de entorno:

   export PROJECT=$(gcloud config get-value project)
   export CLUSTER=$PROJECT-gke
   export REGION="us-central1"
   

Limpia

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

Si planificas completar los pasos del siguiente documento de esta serie, Seguimiento distribuido en una aplicación de microservicios, puedes volver a usar el proyecto y los recursos en lugar de borrarlos.

Borra el proyecto

1. En la consola de Google Cloud, ve a la página Administrar recursos.

   Ir a Administrar recursos

2. En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
3. En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

Borra recursos

Si deseas conservar el proyecto de Google Cloud que usaste en este instructivo, borra los recursos individuales.

1. En Cloud Shell, ejecuta el siguiente comando:

   cd setup && terraform destroy -auto-approve
   

2. Para borrar el clúster de microservicios con Google Cloud CLI, ejecuta el siguiente comando:

   gcloud container clusters delete online-boutique \
       --location $REGION
   

Próximos pasos

• Obtén más información de la arquitectura de microservicios.
• Lee el primer documento de esta serie para obtener información de los microservicios, sus beneficios, sus desafíos y sus casos de uso.
• Lee el segundo documento de esta serie para obtener información de las estrategias de refactorización de aplicaciones para descomponer microservicios.
• Lee el último documento de esta serie para obtener información del seguimiento distribuido de solicitudes entre microservicios.