Sistemas distribuidos con Node.js

Capítulo 8. Resiliencia

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Este capítulo se centra en la resiliencia de la aplicación, que es la capacidad de sobrevivir a situaciones que, de otro modo, podrían provocar un fallo. A diferencia de otros capítulos que se centraban en servicios externos al proceso Node.js, éste se centra sobre todo en el interior del proceso.

Las aplicaciones deben ser resistentes a ciertos tipos de fallos. Por ejemplo, hay muchas opciones disponibles para un servicio descendente como web-api cuando no puede comunicarse con un servicio ascendente como recipe-api. Tal vez deba reintentar la solicitud saliente, o tal vez deba responder a la solicitud entrante con un error. Pero en cualquier caso, bloquearse no es la mejor opción. Del mismo modo, si se pierde una conexión a una base de datos con estado, la aplicación probablemente debería intentar volver a conectarse a ella, mientras responde a las solicitudes entrantes con un error. Por otra parte, si se pierde una conexión con un servicio de caché, la mejor acción podría ser responder al cliente como de costumbre, aunque de forma más lenta y "degradada".

En muchos casos es necesario que una aplicación se bloquee. Si se produce un fallo que un ingeniero no prevé -a menudo global al proceso y no asociado a una única solicitud-, entonces la aplicación puede entrar potencialmente en un estado comprometido. En estas situaciones, lo mejor es ...