Ticker

6/recent/ticker-posts

Reactive Manifesto



Los sistemas informáticos o aplicaciones están compuestos de otros sistemas más pequeños y normalmente dependen de respuestas o eventos Reactivas; no necesariamente pueden ser reactivas, sin embargo, en este tutorial revisaremos los principios del Reactive Manifesto.

Los sistemas informáticos más grandes del mundo hoy en dia aplican este principio (Reactive Manifesto) en la elaboración de sus arquitecturas con el fin de atiender las necesidades de miles de millones de usuarios diariamente. 

¿Qué es Reactive Manifesto?

En primer instancia el Reactive Manifesto o Manifiesto Reactivo es el documento que define los principios fundamentales de la programación reactiva que fue lanzado en el año 2013 por un grupo de desarrolladores liderado por Jonas Boner, publicaron en un blog explicando las razones detrás del manifiesto.

El Reactive Manifesto o Manifiesto Reactivo sustenta los principios de la programación reactiva, es decir, se puede considerar como guía o mapa del tesoro de la programación reactiva, todos los que comienzan con la programación reactiva deben leer el manifiesto para comprender de qué se trata la programación reactiva y cuáles son sus principios. 

En 2014 se publicó una segunda versión actualizada del Manifiesto Reactivo y varios programadores de alto perfil firmaron el manifiesto reactivo. Algunos de los nombres detrás de esto incluyen a Erik Meijer, Martin Odersky, Greg Young, Martin Thompson y Roland Kuhn.

Los 4 principios del Manifiesto Reactivo

Responsivo: El sistema responde de manera oportuna si es posible. La capacidad de respuesta es la piedra angular de la usabilidad y la utilidad, pero más que eso, la capacidad de respuesta significa que los problemas pueden detectarse rápidamente y tratarse con eficacia. Los sistemas receptivos se enfocan en proporcionar tiempos de respuesta rápidos y consistentes, estableciendo límites superiores confiables para que brinden una calidad de servicio constante. Este comportamiento consistente, a su vez, simplifica el manejo de errores, genera confianza en el usuario final y fomenta una mayor interacción.

Resiliente: El sistema se mantiene receptivo frente a fallas. Esto se aplica no solo a los sistemas de orientación crítica y alta disponibilidad: cualquier sistema que no sea resistente no responderá después de una falla. La resiliencia se logra mediante la replicación, la contención, el aislamiento y la delegación. Las fallas están contenidas dentro de cada componente, aislando los componentes entre sí y asegurando así que partes del sistema puedan fallar y recuperarse sin comprometer el sistema como un todo. La recuperación de cada componente se delega a otro componente (externo) y la alta disponibilidad se garantiza mediante la replicación cuando sea necesario. El cliente de un componente no tiene la carga de manejar sus fallas.

Elástico: El sistema se mantiene receptivo bajo una carga de trabajo variable. Los sistemas reactivos pueden reaccionar a los cambios en la tasa de entrada aumentando o disminuyendo los recursos asignados para dar servicio a estas entradas. Esto implica diseños que no tienen puntos de contención ni cuellos de botella centrales, lo que da como resultado la capacidad de fragmentar o replicar componentes y distribuir entradas entre ellos. Los sistemas reactivos admiten algoritmos de escalado predictivos y reactivos al proporcionar medidas relevantes de rendimiento en vivo. Logran elasticidad de una manera rentable en plataformas de hardware y software de productos básicos.

Orientado a mensajes: Los sistemas reactivos se basan en el paso de mensajes asincrónicos para establecer un límite entre los componentes que garantiza un acoplamiento débil, aislamiento, transparencia de ubicación y proporciona los medios para delegar errores como mensajes. Emplear el paso explícito de mensajes permite la gestión de carga, la elasticidad y el control de flujo al dar forma y monitorear las colas de mensajes en el sistema y aplicar contrapresión cuando sea necesario. La mensajería transparente de ubicación como medio de comunicación hace posible que la gestión de fallas funcione con las mismas construcciones y semánticas en un clúster o dentro de un solo host. La comunicación sin bloqueo permite que los destinatarios solo consuman recursos mientras están activos, lo que reduce la sobrecarga del sistema.




Es tiempo de aplicar los principios de diseño conscientemente desde el inicio de cada proyecto de software, principios que ya están provados en la industria del desarrollo de software.


Referencias:

El Manifiesto de Sistemas Reactivos

Spring - Reactive

Publicar un comentario

0 Comentarios