Entrevista: Microservicios
Tags: microservices, architecture, webdev, interview
Published: 2022-02-24 22:26:06

## MICROSERVICIOS


**¿Qué es la arquitectura de Microservicios?**

Podriamos hablar de un conjunto de caracteristicas para definirlos:

- Es un enfoque para crear una aplicacion como un conjunto de pequeños servicios independencientes.

- Pueden comunicarse por HTTP (API REST) u otros mecanismos ligeros.

- Hay un mínimo de genstion centralizada, es decir contamos con variedad de servicios independientes que contribuyen a estos servicios mas grandes,desacomplando responsabilidades.

- Cada uno de los microservicios puede escribirse en lenguajes diferentes y utilizar diferentes bases de datos.

**¿Cuáles son las ventajas de los microservicios?**

- Como suelen ser servicios más pequeños suelen ser asignados a equipos de desarrollo chicos con conocimientos especificos haciendolos más manejables.

- Pruebas atómicas, testeo de componentes más faciles.

- Pruebas de integracion sectorizadas, E2E testing.

- Permite utilizar diversas tecnoligias, teniendo cada microservicio la implementación que mas se ajuste a sus necesidades.

- Facilita la implementación de múltiples instancias de un microservicio en diversos nodos. Escalabilidad horizontal.

**Retos de la implementación de microservicios**

- El diseño adecuado, tanto cada microservicio particular como el conjunto de ellos formando la aplicación principal.

- Gestión de infraestructura: configuracion distribuida, ApiGateway, control de resiliencia (adaptabilidad a fallos), patrones de reintentos, patron de circuit breaker. 

- Gestión de transaccionalidad y la consistencia de los datos. Al tener servios con posibles bases de datos independientes es necesario asegurar la correcta persistencia y traslado de los datos de un lugar a otro.

 **¿Cómo puede resolverse el problema de los parámetro de configuracion de los microservicios y sus instancias?**

Patrón de configuración centralizada, cuando una aplicación se va a iniciar en el proceso de arranque va a buscar su configuración a un algun lugar (servidor de configuración) la lee y termina el arranque con esos datos. No hay que tener configuraciones locales.
Se pueden cambiar estas configuraciones en "caliente" (una vez ya levantado el microservicio) utilizando features flags (hay empresas dedicadas a esto) o utilizando variables de entorno.

**¿Qué mecanismos pueden implementarse para evitar fallos? RESILIENCIA** 

- Debemos conocer los fallos que puede tener la computación distribuida. (Voy a hacer otro post de esto)

- Dar una solución con Reintentos. Mecanismo que cuando un microservicio A llama a otro B  y este responde con un error, el A seguirá reintentando hacer la llamamada al servicio B.
Sirve para dar solución a problemas transitorios de la red.

- Dar una solución con Circuit Breaker (CB). 
En el mismo escenario que arriba, el microservicio A tambien vuelve a reintentar llamados al microservicio B, pero luego de un estipulado número de fallos el CB hace un cambio de estado, para evitar la utilización innecesaria de recursos en procesar errores.

El CB consiste en la implementación de una solución que permite tener mayor resiliencia,  hace de intermediario entre el cliente y el servicio que se desea consumir dando tres diferentes estados a las transacciones realiazadas. 

CLOSE, es cuando el flujo de llamada está funcionando correctamente. En caso de algun problema,una vez fallados ciertos intentos de llamada el CB pasa a estado abierto. 

OPEN, cuando pasa a estado abierto, corta el flujo de llamadas para evitar propagaciones de errores, encargandosé de la respuesta directa al cliente, avitando así la utilización de recursos innecesarios. El circuito continua abierto durante un periodo ya definido, luego de transcurrido ese tiempo pasa a estado semi-abierto.

HALF-OPEN,se hace un mínimo de intentos para la corroboración del estado del servicio, si todo anda correctamente se restaura el flujo pasando a estado cerrado, de lo contrario volvera nuevamente a abierto y  se repite nuevamente el proceso.

Podemos agregar a la fórmula una Fallback Policy (política de contingencia) y evitar cualquier tiempo de caida en nuestro flujo. Utilizando por ejemplo un servicio de respaldo alternativo mientras nuestro servicio principal esté caido.

**¿Que es servicio de descubrimiento y porqué son importantes?**

Supongamos que tenemos 4 instancias de un servicio de menú y 2 instancias de pagos, todos con ids independientes. Si un tercer servicio de orden quiere consumir uno de los 4 servicios de menu y ademas que se realice el pago ¿Como sabe que servicio esta disponible y como encontrar su dirección?

Necesitamos un Servidor de Registro y Descubrimiento (SRD):

REGISTRO, cuando un servicio de la infraestructura inicia su operación o se levanta va a SRD a guardar su ubicación y disponibilidad Cualquier otro consumidor (por ejemplo el servicio de órdenes) puede saber en todo momento el estado y lugar del servicio requerido. Cada determinada cantidad de tiempo se realizan nuevas corroboraciones para asegurar la disponibilidad (healthCheck).

DESCUCRIMIENTO, es la capacidad del servidor de devolver la ubicación correcta de las instancias activadas. Trabaja junto al balanceador de carga para determinar cual instancia esta con mayor disponibilidad.

Continuara...