Introducción a la Arquitectura Reactiva
Antes de comenzar con lo que entendemos por arquitectura reactiva es necesario comprender el problema que intenta resolver. Para hacerlo, recurrí a este curso de Cognitive Class y les comparto un resumen los puntos más importantes.
Los usuarios actuales elevaron sus expectativas y exigen condiciones para seguir en relación con determinada compañía que consuman:
- No quieren tener cortes en el servicio (downtime and manteniance mode).
- No quieren que las aplicaciones se rompan sin control (crash and no options for continue).
- No quieren esperar por lo que solicitan, lo quieren si es posible, de manera inmediata (wait response).
Entonces podemos decir que la meta que perseguimos es tener software que cumpla lo anterior y además:
- Sea escalable pero consumiendo solo los recursos necesarios para dar respuesta a la demanda de un momento dado.
- Pueda funcionar de manera distribuida en “n” máquinas.
- Tolere fallos de manera controlada.
- Mantenga un nivel de consistencia y respuesta adecuado.
Los principios
Siguiendo el documento los sistemas reactivos son:
Responsivos: El sistema responde a tiempo en la medida de lo posible. La responsividad es la piedra angular de la usabilidad y la utilidad, pero más que esto, responsividad significa que los problemas pueden ser detectados rápidamente y tratados efectivamente. Los sistemas responsivos se enfocan en proveer tiempos de respuesta rápidos y consistentes, estableciendo límites superiores confiables para así proporcionar una calidad de servicio consistente. Este comportamiento, a su vez, simplifica el tratamiento de errores, aporta seguridad al usuario final y fomenta una mayor interacción.
Resilientes: El sistema permanece responsivo frente a fallos. Esto es aplicable no sólo a sistemas de alta disponibilidad o de misión crítica — cualquier sistema que no sea resiliente dejará de ser responsivo después de un fallo. La resiliencia es alcanzada con replicación, contención, aislamiento y delegación. Los fallos son manejados dentro de cada componente, aislando cada componente de los demás, y asegurando así que cualquier parte del sistema pueda fallar y recuperarse sin comprometer el sistema como un todo. La recuperación de cada componente se delega en otro componente (externo) y la alta disponibilidad se asegura con replicación allí donde sea necesario. El cliente de un componente no tiene que responsabilizarse del manejo sus fallos.
Elásticos: El sistema se mantiene responsivo bajo variaciones en la carga de trabajo. Los Sistemas Reactivos pueden reaccionar a cambios en la frecuencia de peticiones incrementando o reduciendo los recursos asignados para servir dichas peticiones. Esto implica diseños que no tengan puntos de contención o cuellos de botella centralizados, resultando en la capacidad de dividir o replicar componentes y distribuir las peticiones entre ellos. Los Sistemas Reactivos soportan algoritmos de escalado predictivos, así como Reactivos, al proporcionar relevantes medidas de rendimiento en tiempo real. La elasticidad se consigue de forma rentable haciendo uso de plataformas con hardware y software genéricos.
Orientados a Mensajes: Los Sistemas Reactivos confían en el intercambio de mensajes asíncronos para establecer fronteras entre componentes, lo que asegura bajo acoplamiento, aislamiento y transparencia de ubicación. Estas fronteras también proporcionan los medios para delegar fallos como mensajes. El uso del intercambio de mensajes explícito posibilita la gestión de la carga, la elasticidad, y el control de flujo, gracias al modelado y monitorización de las colas de mensajes en el sistema, y la aplicación de back-pressure cuando sea necesario. La mensajería basada en ubicaciones transparentes como medio de comunicación permite que la gestión de fallos pueda trabajar con los mismos bloques y semánticas a través de un clúster o dentro de un solo nodo. La comunicación No-bloqueante permite a los destinatarios consumir recursos sólo mientras estén activos, llevando a una menor sobrecarga del sistema.
Programación reactiva
No hay que confundir que por usar lenguajes que soporten técnicas de programación reactiva, como serían Futures / Promises, se está haciendo de ese sistema un sistema reactivo. Cuando pensamos por ejemplo en microservicios reactivos pensamos en microservicios que cumplan los principios mencionados anteriormente.
Actor Model
Actor Model es un paradigma de programación que sirve para la construcción de sistemas reactivos. Está orientado a mensajes y con su abstracción permite cumplir con los principios de elasticidad y resiliencia.
Como conceptos fundamentales:
- Todo el cómputo ocurre dentro de un actor.
- Todo actor tiene una dirección.
- Los actores se comunican solo con mensajes asincrónicos.
Los actores se comunican de la misma manera tanto local como remotamente, esto se llama transparencia de localización y le permite al sistema ser resiliente y elástico. Las llamadas locales son consideradas siempre remotas, planteando un escenario en donde se puedan tener fallas en la comunicación.
Sistemas reactivos sin actores
Se puede pensar en construir sistemas reactivos sin actores, teniendo algunos componentes como un registro de servicios, un balanceador de carga y un bus de mensajería. Con el registro y el balanceador podemos escalar y ser transparente en cuanto a donde corre cada servicio, y con el bus de mensajería podemos manejar los mensajes de manera asincrónica y no bloqueante. Igualmente es más sencillo pensar en sistemas reactivos usando Actor Model.
