Microservicio receptor con worker en .NET

Curso de Introducción a los Microservicios

Contenido del curso

Fundamentos de Microservicios

Arquitectura Basada en Microservicios

Automatización y Preparación del Entorno

Comunicación Asíncrona entre Servicios

Despliegue

Observabilidad

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:006:38

Microservicio receptor con worker en .NET

Curso de Introducción a los Microservicios

Clase 13 de 24

Clase 13 / 24

Recursos

Conectar dos microservicios mediante un queue de Azure Service Bus requiere configurar un servicio receptor que escuche mensajes en segundo plano sin exponer endpoints HTTP. Aquí verás cómo construir ese servicio receptor en .NET usando un worker, paso a paso, partiendo del transcript de la clase.

¿Qué necesitas para configurar el servicio receptor PeakAge?

Antes de escribir código, prepara las dependencias y la configuración base que la documentación te indica.

El primer paso es agregar los paquetes de NuGet desde la terminal. Copias cada paquete, lo pegas en la terminal y presionas enter. Si trabajas con .NET, el flujo es idéntico. Una vez instalados, el siguiente paso es replicar el archivo appsettings.json que ya usaste en el servicio emisor.

En lugar de reescribirlo, hay un truco práctico: copia todo el contenido del appsettings de AddMember, muévete al proyecto PeakAge y reemplaza el contenido completo con Control A, Control C y pegar. Así heredas el ConnectionString y el QueueName sin errores de tipeo [03:12].

¿Qué es un worker en .NET? Es un servicio que corre en segundo plano, esperando ser despertado cuando llega un evento, como un mensaje nuevo en una cola de Service Bus. No expone endpoints HTTP.

¿Cómo modificar Program.cs para que no exponga una API?

Aquí ocurre el cambio más interesante: el receptor deja de ser una API tradicional.

Al abrir Program.cs verás el código que normalmente expone los métodos de tu API mediante endpoints. Ese código desaparece por completo. La nueva configuración se encarga solo de dos cosas:

Leer la información desde appsettings.json.
Registrar y configurar el servicio como un worker en segundo plano.

Esto significa que el proyecto ya no escuchará en un puerto HTTP. Su único trabajo será mantenerse activo esperando mensajes desde Azure Service Bus.

¿Cómo se construye el archivo Worker.cs?

El archivo Worker.cs es el corazón del servicio receptor. Lo creas dentro del proyecto PeakAge y pegas el contenido que la documentación indica [05:48].

¿Qué contiene la clase Worker?

Este archivo está pensado para mantenerse "durmiendo" y despertar solo cuando hay actividad en la cola. Su estructura incluye:

La configuración con ConnectionString y QueueName, que deben coincidir exactamente con lo declarado en appsettings.json.
Un cliente y un procesador encargados de manejar la comunicación con Service Bus.
Un constructor que recibe los servicios inyectados y los asigna a las variables internas.
El método ExecuteAsync, que mantiene al worker activo de forma indefinida y registra los manejadores de eventos.
Métodos obligatorios como ErrorHandler y StopAsync, que el worker exige implementar para gestionar errores y apagados controlados.

Dentro del manejador del mensaje recibido, el body contiene la información que llegó desde el servicio emisor. Una buena práctica de naming es nombrar la variable como mensaje recibido en español si el resto del código está en ese idioma, para mantener consistencia [07:30].

¿Para qué sirve ExecuteAsync en un worker? Es el método que mantiene vivo al servicio en segundo plano y conecta los manejadores de eventos que reaccionan cuando llega un nuevo mensaje a la cola.

¿Cómo verificar que el receptor procesa los mensajes de la cola?

La prueba final demuestra que la comunicación entre microservicios funciona sin HTTP.

Abre dos terminales. En una, ubícate en la carpeta del servicio AddMember. En la otra, en PeakAge. Ejecuta dotnet run en PeakAge y notarás algo distinto: no aparece un puerto expuesto como localhost:5242, porque este servicio no se comunica por HTTP, sino por mensajería.

La aplicación se inicia y, como spoiler, procesa de inmediato los mensajes que estaban en fila esperando. En el ejemplo del transcript aparece el nombre Miranda y dos intentos previos. Al regresar al portal de Azure y actualizar la información, el conteo de mensajes pendientes se resetea a cero [09:15].

Para probar el flujo completo en vivo:

Mantén corriendo el servicio PeakAge en una terminal.
Desde el archivo HTTP de AddMember, modifica un valor del cuerpo, por ejemplo cambia el año a 2019.
Envía la solicitud al servicio emisor.
Observa la terminal de PeakAge: aparecerá Mensaje recibido 2019, enviado del otro servicio.

¿Por qué un microservicio receptor no expone un puerto? Porque su comunicación ocurre a través de un queue de Azure Service Bus, no de HTTP. Solo necesita conectarse al broker de mensajería y escuchar.

Con esto, dos microservicios ya conversan entre sí mediante una cola, lo que abre la puerta al siguiente reto: hacer que el segundo servicio publique mensajes a un topic. ¿Qué diferencias crees que tendrá un topic frente a un queue? Déjalo en los comentarios.

Resumen

¿Qué necesitas para configurar el servicio receptor PeakAge?

Antes de escribir código, prepara las dependencias y la configuración base que la documentación te indica.

¿Qué es un worker en .NET? Es un servicio que corre en segundo plano, esperando ser despertado cuando llega un evento, como un mensaje nuevo en una cola de Service Bus. No expone endpoints HTTP.

¿Cómo modificar Program.cs para que no exponga una API?

Aquí ocurre el cambio más interesante: el receptor deja de ser una API tradicional.

Leer la información desde appsettings.json.
Registrar y configurar el servicio como un worker en segundo plano.

Esto significa que el proyecto ya no escuchará en un puerto HTTP. Su único trabajo será mantenerse activo esperando mensajes desde Azure Service Bus.

¿Cómo se construye el archivo Worker.cs?

El archivo Worker.cs es el corazón del servicio receptor. Lo creas dentro del proyecto PeakAge y pegas el contenido que la documentación indica [05:48].

¿Qué contiene la clase Worker?

Este archivo está pensado para mantenerse "durmiendo" y despertar solo cuando hay actividad en la cola. Su estructura incluye:

La configuración con ConnectionString y QueueName, que deben coincidir exactamente con lo declarado en appsettings.json.
Un cliente y un procesador encargados de manejar la comunicación con Service Bus.
Un constructor que recibe los servicios inyectados y los asigna a las variables internas.
El método ExecuteAsync, que mantiene al worker activo de forma indefinida y registra los manejadores de eventos.
Métodos obligatorios como ErrorHandler y StopAsync, que el worker exige implementar para gestionar errores y apagados controlados.

¿Para qué sirve ExecuteAsync en un worker? Es el método que mantiene vivo al servicio en segundo plano y conecta los manejadores de eventos que reaccionan cuando llega un nuevo mensaje a la cola.

¿Cómo verificar que el receptor procesa los mensajes de la cola?

La prueba final demuestra que la comunicación entre microservicios funciona sin HTTP.

Para probar el flujo completo en vivo:

Mantén corriendo el servicio PeakAge en una terminal.
Desde el archivo HTTP de AddMember, modifica un valor del cuerpo, por ejemplo cambia el año a 2019.
Envía la solicitud al servicio emisor.
Observa la terminal de PeakAge: aparecerá Mensaje recibido 2019, enviado del otro servicio.

¿Por qué un microservicio receptor no expone un puerto? Porque su comunicación ocurre a través de un queue de Azure Service Bus, no de HTTP. Solo necesita conectarse al broker de mensajería y escuchar.

Fundamentos de Microservicios

Arquitectura de microservicios vs sistemas monolíticos

Imagen, contenedor y microservicio: no son lo mismo

API monolítica base para microservicios en .NET

Arquitectura Basada en Microservicios

Dividir una API en microservicios escalables

Kafka para comunicar microservicios por eventos

Flujo de trabajo con Kafka para enrutar microservicios automáticamente

Bases de datos fuera de contenedores Docker

Automatización y Preparación del Entorno

Automatiza microservicios ASP.NET con Bash

Automatizar microservicios con Bash y Dockerfile

Azure Service Bus para comunicación entre microservicios

Rest Client como alternativa a Swagger en VS Code

Comunicación Asíncrona entre Servicios

Envía mensajes a Azure Service Bus desde .NET

Microservicio receptor con worker en .NET

Topics de Azure Service Bus con patrón Pub/Sub

Conectar Add Adult a Service Bus y SQL

Despliegue

Tres microservicios .NET corriendo sin Docker

Creación de servicios de consulta con .NET y SQL

Docker Compose con cinco microservicios .NET

Monorepo vs multirepo en microservicios

Configuración de secretos de GitHub para desplegar en Azure

Observabilidad

Despliegue de aplicaciones con Azure Container Apps desde Docker Hub

Despliegue automático de microservicios con GitHub Actions

Desplegando microservicios con GitHub Actions

Próximos pasos de mejora en arquitectura de microservicios

Microservicio receptor con worker en .NET

Progreso del curso

Fundamentos de Microservicios

Arquitectura Basada en Microservicios

Automatización y Preparación del Entorno

Comunicación Asíncrona entre Servicios

Despliegue

Observabilidad

Recursos

Recursos