Microservicios

Question 1

qué es un microservicio

Answer 1

Una aplicación se divide en una colección de servicios autónomos (microservicios), especializados en una sola función de negocio (ej. un servicio para el carrito, otro para el inventario, otro para los pagos).
Están débilmente acoplados (son independientes) ej. si cae el servicio pagos, el servicio buscador de productos sigue funcionando.
Granularidad muy fina: cada servicio hace una sola cosa. Ej. servicio alta de usuario, otro cambio de contraseña, otro de perfil..
Cada microservicio “vive” en contenedores o servidores distintos y usa protocolos ligeros para comunicarse: http/REST (con JSON), gRPC, y mensajería asíncrona como RabbitMQ o Kafka.
Se pueden actualizar sin que la web deje de dar servicio. Si falla la actualización – rollback hasta estado original previo.
En resumen, resuelven los problemas de escalabilidad de las aplicaciones monolíticas

Question 2

Arquitectura Orquestada en microservicios

Answer 2

Punto de control: Centralizado (orquestador)
Acoplamiento: Mayor (dependen del orquestador)
Visibilidad: Alta (el flujo está en un sitio)
Tecnología típica: REST / Llamadas síncronas
Complejidad: Crece con el tamaño del proceso

Question 3

Arquitectura Coreografiada en microservicios

Answer 3

Punto de control: Distribuido (eventos)
Acoplamiento: Mínimo (autónomos)
Visibilidad: Baja (el flujo está repartido)
Tecnología típica: Message Brokers (Kafka, RabbitMQ)
Complejidad: Crece con el número de servicios

Question 4

Domain Driven Design (DDD)

Answer 4

Metodología que sirve para dividir un negocio en servicios autónomos (Capacidades de Negocio) con fronteras lógicas (Bounded Contexts) que aseguren que cada microservicio es dueño de su información (Aggregates) y se asegura una coordinación Asíncrona para que el negocio funcione como un todo sin que las comunicaciones entre microservicios (Domain Events) hagan que se bloqueen o provoquen acoplamientos entre ellos y bloqueen la actividad.

Question 5

Bounded Context

Answer 5

es la frontera lógica que separa e identifica cada parte del negocio. Sirve para identificar los posibles microservicios a desarrollar.

Question 6

Aggregates

Answer 6

Es un grupo de objetos que se tratan como una unidad de datos para garantizar que siempre sean coherentes.
Cada microservicio es dueño de sus propios agregados y nadie de fuera puede tocarlos directamente.

Ej. Microservicio Pedidos, contiene aggregates como Pedido, Item pedido, etc

Question 7

Domain Events

Answer 7

son mensajes, el “pegamento” que mantiene el negocio coordinado. Permiten que un cambio en un microservicio provoque una reacción en cadena de acciones en otros servicios, sin que estos estén rígidamente conectados entre sí.
Los mensajes se producen de forma asíncrona

Question 8

Bloqueo síncrono y asíncrono

Answer 8

Bloqueo síncrono: petición-respuesta directa.
Servicio A –> petición síncrona HTTP/REST –> Servicio B –> posible problema (acoplamiento temporal): que se quede esperando o bloqueado por la respuesta.

Bloqueo asíncrono:
-request-response sobre Cola
Servicio A –> petición a un cola de solicitudes y se queda esperando respuesta en otra cola de “respuestas”.
-dirigido por eventos: el servicio A publica en un topic en un canal para todos los suscritos y sigue con su vida (asíncrono puro). Multidifusión (ideal para el desacoplamiento)
-datos compartidos: que dos servicios modifiquen una misma tabla de datos (PROHIBIDO en microservicios) porque cada microservicio es dueño de su propia base de datos

Question 9

Brokers de mensajes

Answer 9

Familia de buses de eventos: para el manejo de volúmenes masivos de datos:
Apache Kafka, Confluent, Google Cloud Pub/Sub

Familia de Message Brokers tradicionales: diseñados para el modelo petición-respuesta:
RabbitMQ, Apache ActiveMQ

Question 10

API Gateway en microservicios

Answer 10

Es el punto de entrada único para las peticiones que vienen del exterior (usuarios, apps móviles, otras webs) hacia el interior de tus microservicios.
Ejercen labores de autenticación antes de dejar pasar; enrutamiento; rate limiting: evitando colapso por excesivas peticiones; orquestación de respuestas.
Ej: Kong, Zuul, Apigee

Question 11

Service Mesh en microservicios

Answer 11

Es una capa de infraestructura que gestiona la comunicación entre los microservicios una vez ya están dentro.
Ejercen labores de cifrado de la comunicación; descubrimiento de servicios; Circuit breaker (si un servicio falla, se le deja de enviar tráfico para evitar que hunda el sistema entero); gráficas del tiempo de respuesta entre microservicios.
Ej: Istio junto con Envoy, Linkerd, Consul Connect

Question 12

Patrón Circuit Breaker para la resiliencia en microservicios

Answer 12

Antes de que el servicio se bloquee por ir lento, se interrumpen las solicitudes.
Es como un interruptor:
Cerrado (todo ok) pasan las solicitudes.
Abierto (hay fallo) se interrumpen las solicitudes.
Medio abierto: se envía una petición a ver si se ha recuperado el servicio
Ej. Hystrix, Resilience4j, Istio

Question 13

Patrón Bulk Head para la resiliencia en microservicios

Answer 13

se crean compartimentos aislados. Si el microservicio “videos” colapsa, que no afecte al de “pagos”

Question 14

Patrón Retry (reintentos) para la resiliencia en microservicios

Answer 14

Si una petición falla, se reintenta automáticamente X veces. OJO!! se espera un tiempo (Backoff) y se reintenta…

Question 15

Patrón Fallback (respuesta de emergencia) para la resiliencia en microservicios

Answer 15

La estrategia: Si el servicio principal falla, ¿qué le mostramos al usuario?
por ejemplo, un contenido genérico para mantener la experiencia de usuario

Question 16

Patrón Timeouts para la resiliencia en microservicios

Answer 16

Si el Servicio B no responde en 200ms, se corta la conexión y se pasa al plan B. (NO BLOQUEAR RECURSOS ETERNAMENTE)