En AZ-204, API Management y los servicios de eventos son el nucleo del dominio de integracion. Esto cubre como exponer APIs de forma segura y construir arquitecturas basadas en eventos.
Azure API Management (APIM)
APIM es como el mostrador de informacion de un centro comercial. Cada visitante (cliente) pasa por el mostrador sin importar que tienda (servicio backend) quiera visitar, y el mostrador gestiona la verificacion de identidad, la orientacion y el registro.
Con APIM puedes agrupar multiples APIs backend en una unica puerta de enlace consistente y exponerlas al mundo exterior.
| Funcion | Descripcion | |---------|-------------| | Publicacion de APIs | Exponer APIs backend de forma segura a consumidores externos | | Proteccion | Autenticacion, limitacion de velocidad, filtrado por IP | | Transformacion | Convertir formatos de solicitud/respuesta, agregar/eliminar encabezados | | Monitoreo | Registros de llamadas, panel de analitica |
Productos, Suscripciones y Claves
| Concepto | Descripcion | Ejemplo | |---------|-------------|---------| | Producto | Paquete que agrupa una o mas APIs | "APIs Plan Gratuito", "APIs Premium" | | Suscripcion | Solicitud para acceder a un producto | Un desarrollador se suscribe al "Plan Gratuito" | | Clave de suscripcion | Token de autenticacion para llamar a la API | Se envia en el encabezado |
Los clientes incluyen la clave de suscripcion en un encabezado HTTP o parametro de consulta al hacer llamadas a la API.
Politicas de APIM (Policies)
Las politicas son reglas que interceptan y procesan solicitudes o respuestas en la puerta de enlace APIM. Se escriben en formato XML.
El ciclo de politicas (Pipeline)
Cada solicitud y respuesta pasa por cuatro etapas:
Entrante (Inbound): Procesa la solicitud entrante del cliente antes de llegar a la puerta de enlace Backend: Procesa la solicitud antes de reenviarla al backend Saliente (Outbound): Procesa la respuesta del backend antes de enviarla al cliente En error (On-Error): Gestiona cualquier error que ocurra
Referencia de politicas comunes
| Politica | Ubicacion | Descripcion | |---------|-----------|-------------| | rate-limit | Entrante | Limitar el numero de llamadas (devuelve 429 al exceder) | | ip-filter | Entrante | Permitir o bloquear por direccion IP | | set-header | Entrante / Saliente | Agregar, modificar o eliminar encabezados | | rewrite-uri | Entrante | Transformar la ruta URL enviada al backend | | mock-response | Entrante | Devolver una respuesta falsa sin llamar al backend real | | cache-lookup / cache-store | Entrante / Saliente | Cachear respuestas |
Azure Event Grid
Event Grid es como el servicio de notificaciones de una oficina de correos. Cuando alguien (la fuente de eventos) envia una carta, la oficina (Event Grid) la recibe y la entrega a las personas que se suscribieron para recibir ese tipo de carta.
Usalo para construir una arquitectura reactiva que responde en cuanto ocurre un evento. Por ejemplo, cuando se sube una imagen a Blob Storage, puedes activar automaticamente una Azure Function para generar una miniatura.
Componentes principales
| Componente | Rol | Ejemplo | |----------|-----|---------| | Fuente de eventos | El servicio que genera eventos | Blob Storage, Grupo de recursos, app personalizada | | Topico | El canal por el que se entregan los eventos | Topicos del sistema (creados automaticamente) / Topicos personalizados | | Suscripcion a eventos | Define que eventos van a que controlador | Evento de creacion de Blob → Function App | | Controlador de eventos | El servicio que recibe y procesa el evento | Azure Function, Logic App, Webhook, Event Hubs |
Se admite el formato CloudEvents como estandar.
Azure Event Hubs
Event Hubs es como los torniquetes de entrada de un gran estadio. Cuando decenas de miles de personas llegan al mismo tiempo, se distribuyen entre multiples accesos (particiones) para procesamiento paralelo, y el orden de entrada queda registrado para revision posterior.
Usalo para escenarios de transmision de datos masivos que necesitan manejar millones de eventos por segundo.
Conceptos principales
| Concepto | Descripcion | |---------|-------------| | Particion | Unidad que divide eventos para procesamiento paralelo (predeterminado: 4) | | Grupo de consumidores | Conjunto de consumidores que leen independientemente el mismo flujo de eventos | | Captura | Guarda automaticamente los eventos en Blob Storage o Data Lake | | Retencion | Por defecto 1 dia, hasta 90 dias |
Comparacion: Event Grid vs Event Hubs
| Aspecto | Event Grid | Event Hubs | |--------|-----------|-----------| | Uso principal | Reaccionar inmediatamente cuando ocurre un evento | Procesamiento de flujos de datos a gran escala | | Modelo de procesamiento | Entrega eventos de uno en uno (push) | Procesamiento de flujo ordenado | | Escala | Hasta miles por segundo | Hasta millones por segundo | | Retencion | Ninguna (se elimina tras la entrega) | Hasta 90 dias | | Escenario tipico | Subida de archivo dispara procesamiento | Datos de sensores IoT, transmision de logs |
!Event Grid vs Event Hubs
Puntos clave del examen
"Consolidar multiples APIs backend en una unica puerta de enlace" -- Azure API Management (APIM)
"Limitar las llamadas a la API a N por minuto" -- politica rate-limit (entrante)
"Permitir o bloquear IPs especificas para acceder a la API" -- politica ip-filter
"Transformar la ruta URL antes de reenviar al backend" -- politica rewrite-uri
"Devolver una respuesta de prueba sin un backend real" -- politica mock-response
"Orden de ejecucion de politicas" -- Entrante → Backend → Saliente → En error
"Activar automaticamente una Function cuando ocurre un evento (reactivo)" -- Azure Event Grid
"Componente clave que se suscribe a eventos de subida de Blob" -- Suscripcion a eventos
"Manejar millones de eventos por segundo para transmision masiva" -- Azure Event Hubs
"Guardar automaticamente datos de Event Hubs en Blob Storage" -- Captura (Capture)
"Multiples equipos leyendo el mismo flujo de forma independiente" -- Grupo de consumidores