2012-03-04 19 views
32

Soy nuevo en Node.js y actualmente estoy cuestionando su fiabilidad.Fiabilidad de Node.js para aplicaciones grandes

Según lo que he visto hasta ahora, parece haber un error importante: cualquier error/excepción no bloqueada bloquea el servidor. Claro, puede tratar de proteger su código a prueba de balas o ponerlo en áreas clave, pero casi siempre habrá errores que se escabullen. Y parece peligroso si una solicitud problemática podría afectar a todas las demás solicitudes. Hay 2 soluciones que he encontrado:

  1. Usar servidor o módulo como forever para reiniciar automáticamente el servidor cuando se rompe. Lo que no me gusta de esto es que el servidor aún está inactivo por un segundo o dos (para un sitio grande, que podría ser cientos (¿miles?) De solicitud).

  2. Captura excepciones no detectadas usando process.on('uncaughtException'). El problema con este enfoque (hasta donde yo sé) es que no hay forma de obtener una referencia a la solicitud que causa la excepción. Entonces esa solicitud particular se deja colgando (el usuario ve el indicador de carga hasta el tiempo de espera). Pero al menos en este caso, otras solicitudes no problemáticas aún pueden ser manejadas.

¿Puede un lanzamiento veterano de Node.js entrar?

+5

No me gusta el poco acerca de "cientos de miles" de solicitudes perdidas en un sitio grande. Un sitio grande se escalará horizontalmente, por lo que un solo proceso solo afectará una pequeña fracción del tráfico total. – Kevin

+1

posibles duplicados: http://stackoverflow.com/questions/7310521/node-js-best-practice-exception-handling http://stackoverflow.com/questions/9181027/node-js-doesnt-display-entire- error-message-on-uncaughtexception-is-it-possibl aunque parezco entender que las respuestas aceptadas no son satisfactorias? – Dirk

+1

@Kevin que aún podría estar entre cientos o simplemente inaceptable –

Respuesta

1

Las excepciones no bloquean el servidor, generan excepciones.

Los errores en node.js que reducen todo el proceso son una historia diferente.

Su mejor opción (que debe hacer con cualquier tecnología), simplemente pruébela con su aplicación lo antes posible para ver si le queda.

2

Tiene el control total del proceso base, y esa es una característica.

Si compara el nodo a una configuración de Apache/PHP, este último es simplemente equivalente a tener un servidor de nodo simple que envía cada solicitud entrante a su propio proceso que finaliza después de que se haya manejado la solicitud.

Puede configurarlo en Nodo si lo desea, y en muchos casos algo así es probablemente una buena idea. Lo mejor de Node es que puedes romper este patrón, por ejemplo, puedes hacer que el proceso principal u otro proceso permanente se ocupen de la sesión antes de que se pase una solicitud a su manejador.

El nodo es una herramienta muy flexible, que es buena si necesita esta flexibilidad, pero requiere cierta habilidad.

+1

Sí, es una espada de doble filo ... la mayoría de las personas que se sienten atraídas por Node no necesariamente tienen el conocimiento o el deseo de construir correctamente la configuración del servidor "correcto". Como nadie realmente se preocupó mucho por los recientes fallos de seguridad de Ruby hasta que algo sucede. Personalmente me atrae el nodo porque estoy muy familiarizado con Javascript. Siento que debería haber múltiples sabores de Node out-of-the-box para manejar varios escenarios. – pixelfreak

3

Para reinicios automáticos y balanceo de carga, le sugiero que revise Learnboost's up balanceador.

Le permite recargar a un trabajador detrás del equilibrador de carga sin omitir ninguna solicitud. Deja de dirigir nuevas solicitudes al trabajador, pero para las solicitudes existentes que ya se están atendiendo, proporciona el período de gracia workerTimeout para esperar a que finalicen las solicitudes antes de que realmente se cierre el proceso.

Puede adaptar esta estrategia para que también sea activada por el evento uncaughtException.

+0

en muchos casos es mejor dejar que el nodo falle en excepciones inesperadas y con algo así como hasta sus reinicios pueden ser invisibles para el visitante. Cuando estaba usando nginx para páginas de php, aprendí que los trabajadores de php se bloquean todo el tiempo y no lo sabes como un usuario de apache porque parece que apache hace lo mismo que arriba.Me hace pensar que apache podría ser configurado para el nodo hmmm .... –

1

Una excepción no detectada, si no se detecta, bloqueará el servidor. Algo así como llamar a una función mal escrita. Uso process.on('uncaughtException') para capturar tales excepciones.Si usa esto, entonces, sí, el error enviado a process.on('uncaughtException') es menos informativo.

Normalmente incluyo un módulo como nomnom para permitir que se muestren las líneas de comando. Incluyo uno llamado --exceptions que, cuando se establece, pasa por alto process.on('uncaughtException'). Básicamente, si veo que están ocurriendo excepciones no detectadas, entonces, en desarrollo, inicio la aplicación con --exceptions para que cuando se produzca ese error no se capture, lo que hace que Node escuche el seguimiento de la pila y luego muera. Esto le dice en qué línea sucedió y en qué archivo.

Capturar las excepciones es una forma de resolverlo. Pero, como dijiste, eso significa que si ocurre un error, puede provocar que los usuarios no reciban respuestas, etcétera. De hecho, recomendaría dejar que el error bloquee el servidor. (Uso process.on('uncaughtException') en aplicaciones, no en servidores web). Y usando forever. El hecho es que es probable que el servidor web se bloquee y exponga lo que necesita reparar.

Digamos que usaste PHP en lugar de Node. PHP no interrumpe abruptamente el servidor (ya que realmente no sirve). Escupe errores realmente feos. Claro, no da como resultado que todo el servidor se caiga y luego tenga que volver a subir. Nadie quiere que sus clientes tengan tiempo de inactividad. Pero también significa que el problema persistirá y será menos perceptible. Todos hemos visto sitios que han dicho errores, y no se parchan muy rápido. Si tal error fuera tomar todo por un pequeño blip (que honestamente no es tan malo en la imagen más grande) entonces seguramente llamaría la atención sobre sí mismo. Lo verías suceder y rastrearías ese error.

El hecho es que los errores existirán en cualquier sistema, independientemente del idioma o la plataforma. Y podría decirse que es mejor que sean fatales para que sepa que sucedieron. Y con el tiempo hace que te vuelvas más consciente de cómo ocurren estos errores. No sé ustedes, pero conozco a muchos desarrolladores de PHP que cometen los mismos errores comunes una y otra vez.

+0

IMO, el sitio web nunca debería bajar. – wayofthefuture

Cuestiones relacionadas