He visto a personas recomendar combinar todo esto en un flujo, pero parecen tener muchas características superpuestas, por lo que me gustaría investigar por qué es posible que desee pasar por 3 programas diferentes antes de acceder a su servidor web real.

nginx:

• ssl: si
• comprimir: sí
• caché: sí
• grupo de backend: sí

barniz:

• SSL: no (¿aturdimiento?)
• comprimir:?
• caché: sí (característica principal)
• grupo de backend: sí

haproxy:

• ssl: no (aturdimiento)
• comprimir:?
• caché: no
• grupo de backend: sí (característica principal)

¿La intención de encadenar todo esto frente a sus servidores web principales solo para obtener algunos de sus principales beneficios?

Parece bastante frágil tener tantos demonios juntos haciendo cosas similares.

¿Cuál es su preferencia de implementación y pedido y por qué?

Simplemente pon..

HaProxy es el mejor equilibrador de carga de código abierto del mercado.
Varnish es el mejor cacher de archivos estáticos de código abierto del mercado.
Nginx es el mejor servidor web de código abierto del mercado.

(Por supuesto, esta es mi opinión y la de muchos otros)

Pero, en general, no todas las consultas pasan por toda la pila.

Todo pasa por haproxy y nginx / multiple nginx's.
La única diferencia es que se "atornilla" al barniz para solicitudes estáticas.

• cualquier solicitud está equilibrada en carga para redundancia y rendimiento (bueno, eso es redundancia escalable)
• cualquier solicitud de archivos estáticos está llegando primero al caché de barniz (bueno, eso es rápido)
• cualquier solicitud dinámica va directamente al backend (genial, el barniz no se usa)

En general, este modelo se ajusta a una arquitectura escalable y en crecimiento (elimine el haproxy si no tiene varios servidores)

Espero que esto ayude: D

Nota: en realidad también presentaré consultas Pound para SSL: D
Puede tener un servidor dedicado a descifrar solicitudes SSL y pasar solicitudes estándar a la pila de back-end: D (hace que toda la pila se ejecute más rápido y más simple)

Prefacio

Actualización en 2016. Las cosas están evolucionando, todos los servidores están mejorando, todos admiten SSL y la web es más sorprendente que nunca.

A menos que se indique, lo siguiente está dirigido a profesionales en negocios y empresas de nueva creación, que brindan soporte a miles y millones de usuarios.

Estas herramientas y arquitecturas requieren muchos usuarios / hardware / dinero. Puede probar esto en un laboratorio casero o para ejecutar un blog, pero eso no tiene mucho sentido.

Como regla general, recuerde que desea que sea ​​simple . Cada middleware agregado es otra pieza crítica de middleware para mantener. La perfección no se logra cuando no hay nada que agregar, pero cuando no hay nada que eliminar.

Algunas implementaciones comunes e interesantes

HAProxy (equilibrio) + nginx (aplicación php + almacenamiento en caché)

El servidor web está ejecutando nginx php. Cuando nginx ya está allí, también podría manejar el almacenamiento en caché y las redirecciones.

HAProxy ---> nginx-php
A       ---> nginx-php
P       ---> nginx-php
r       ---> nginx-php
o       ---> nginx-php
x       ---> nginx-php
y       ---> nginx-php

HAProxy (equilibrio) + Barniz (almacenamiento en caché) + Tomcat (aplicación Java)

HAProxy puede redirigir a Varnish en función del URI de solicitud (* .jpg * .css * .js).

HAProxy ---> tomcat
A       ---> tomcat
        ---> tomcat
P       ---> tomcat <----+
r       ---> tomcat <---+|
o                       ||
x       ---> varnish <--+|
y       ---> varnish <---+

HAProxy (equilibrio) + nginx (SSL para el host y el almacenamiento en caché) + servidor web (aplicación)

Los servidores web no hablan SSL aunque TODOS DEBEN HABLAR SSL ( especialmente este enlace HAProxy-WebServer con información privada del usuario que pasa por EC2 ). Agregar un nginx local permite llevar SSL al host. Una vez que nginx esté allí, también podría hacer un poco de almacenamiento en caché y reescritura de URL.

Nota : La redirección de puertos 443: 8080 está sucediendo pero no es parte de las características. No tiene sentido hacer redirección de puertos. El equilibrador de carga podría hablar directamente al servidor web: 8080.

          (nginx + webserver on same host)
HAProxy ---> nginx:443 -> webserver:8080
A       ---> nginx:443 -> webserver:8080
P       ---> nginx:443 -> webserver:8080
r       ---> nginx:443 -> webserver:8080
o       ---> nginx:443 -> webserver:8080
x       ---> nginx:443 -> webserver:8080
y       ---> nginx:443 -> webserver:8080

Middleware

HAProxy: EL equilibrador de carga

Características principales :

• Equilibrio de carga (TCP, HTTP, HTTPS)
• Múltiples algoritmos (round robin, fuente ip, encabezados)
• Persistencia de la sesión
• Terminación SSL

Alternativas similares : nginx (servidor web multipropósito configurable como equilibrador de carga)
Diferentes alternativas : nube (Amazon ELB, equilibrador de carga de Google), hardware (F5, fortinet, citrix netscaler), otros y en todo el mundo (DNS, anycast, CloudFlare)

¿Qué hace HAProxy y cuándo TIENES QUE usarlo?
Siempre que necesite equilibrio de carga. HAProxy es la solución.

Excepto cuando quieras muy barato O rápido y sucio O no tienes las habilidades disponibles, entonces puedes usar un ELB: D

Excepto cuando se encuentre en la banca / gobierno / similar que requiera usar su propio centro de datos con requisitos estrictos (infraestructura dedicada, conmutación por error confiable, 2 capas de firewall, material de auditoría, SLA para pagar x% por minuto de tiempo de inactividad, todo en uno) entonces puede colocar 2 F5 en la parte superior del bastidor que contiene sus 30 servidores de aplicaciones.

Excepto cuando desee pasar más de 100k HTTP (S) [y sitios múltiples], DEBE tener múltiples HAProxy con una capa de equilibrio de carga [global] frente a ellos (nube, DNS, cualquier difusión). Teóricamente, el equilibrador global podría hablar directamente con los servidores web permitiendo deshacerse de HAProxy. Sin embargo, por lo general, DEBE mantener HAProxy (s) como punto (s) de entrada público a su centro de datos y ajustar las opciones avanzadas para equilibrar de manera equitativa los hosts y minimizar la variación.

Opinión personal : un proyecto pequeño, contenido y de código abierto, totalmente dedicado a UN PROPÓSITO VERDADERO. Entre la configuración más fácil (UN archivo), el software de código abierto más útil y confiable que he encontrado en mi vida.

Nginx: Apache que no apesta

Características principales :

• Servidor web HTTP o HTTPS
• Ejecute aplicaciones en CGI / PHP / alguna otra
• Redireccionamiento / reescritura de URL
• Control de acceso
• Manipulación de encabezados HTTP
• Almacenamiento en caché
• Proxy inverso

Alternativas similares : Apache, Lighttpd, Tomcat, Gunicorn ...

Apache era el servidor web de facto, también conocido como un grupo gigante de docenas de módulos y miles de líneas httpd.confen la parte superior de una arquitectura de procesamiento de solicitud rota. nginx rehace todo eso, con menos módulos, una configuración (ligeramente) más simple y una mejor arquitectura central.

¿Qué hace nginx y cuándo DEBE usarlo?
Un servidor web está destinado a ejecutar aplicaciones. Cuando su aplicación está desarrollada para ejecutarse en nginx, ya tiene nginx y también puede usar todas sus funciones.

Excepto cuando su aplicación no está diseñada para ejecutarse en nginx y nginx no se encuentra en ninguna parte de su pila (¿Java compra a alguien?), Entonces no tiene mucho sentido en nginx. Es probable que las características de los servidores web existan en su servidor web actual y las otras tareas se manejan mejor con la herramienta dedicada apropiada (HAProxy / Varnish / CDN).

Excepto cuando su servidor web / aplicación carece de funciones, es difícil de configurar y / o prefiere morir de trabajo antes de mirarlo (¿Gunicorn alguien?), Entonces puede poner un nginx al frente (es decir, localmente en cada nodo) para realizar la URL reescribir, enviar redireccionamientos 301, aplicar control de acceso, proporcionar cifrado SSL y editar encabezados HTTP sobre la marcha. [Estas son las características que se esperan de un servidor web]

Barniz: EL servidor de almacenamiento en caché

Características principales :

• Almacenamiento en caché
• Almacenamiento en caché avanzado
• Almacenamiento en caché de grano fino
• Almacenamiento en caché

Alternativas similares : nginx (servidor web multipropósito configurable como servidor de almacenamiento en caché)
Diferentes alternativas : CDN (Akamai, Amazon CloudFront, CloudFlare), Hardware (F5, Fortinet, Citrix Netscaler)

¿Qué hace Varnish y cuándo DEBE USARLO?
Hace el almacenamiento en caché, solo el almacenamiento en caché. Por lo general, no vale la pena el esfuerzo y es una pérdida de tiempo. Prueba CDN en su lugar. Tenga en cuenta que el almacenamiento en caché es lo último que debe preocuparse al ejecutar un sitio web.

Excepto cuando esté ejecutando un sitio web exclusivamente sobre imágenes o videos, entonces debe examinar CDN a fondo y pensar en el almacenamiento en caché en serio.

Excepto cuando se ve obligado a usar su propio hardware en su propio centro de datos (CDN no es una opción) y sus servidores web son terribles para entregar archivos estáticos (agregar más servidores web no ayuda), entonces Varnish es el último recurso.

Excepto cuando tiene un sitio con contenido generado en su mayoría estático pero complejo-generado dinámicamente (vea los siguientes párrafos), Varnish puede ahorrar mucha potencia de procesamiento en sus servidores web.

El almacenamiento en caché estático está sobrevalorado en 2016

El almacenamiento en caché es casi libre de configuración, dinero y tiempo. Simplemente suscríbase a CloudFlare, CloudFront o Akamai o MaxCDN. El tiempo que me lleva escribir esta línea es más largo que el tiempo que lleva configurar el almacenamiento en caché Y la cerveza que tengo en la mano es más costosa que la suscripción mediana de CloudFlare.

Todos estos servicios funcionan fuera de la caja para static * .css * .js * .png y más. De hecho, respetan principalmente la Cache-Controldirectiva en el encabezado HTTP. El primer paso del almacenamiento en caché es configurar sus servidores web para enviar directivas de caché adecuadas. No importa qué CDN, qué Barniz, qué navegador esté en el medio.

Consideraciones de rendimiento

Varnish fue creado en un momento en que los servidores web promedio se ahogaban para servir una foto de gato en un blog. Hoy en día, una sola instancia del servidor web moderno, moderno, multiproceso y asincrónico impulsado por palabras de moda puede entregar gatitos de manera confiable a todo un país. Cortesía sendfile().

Hice algunas pruebas rápidas de rendimiento para el último proyecto en el que trabajé. Una sola instancia de Tomcat podría servir de 21 000 a 33 000 archivos estáticos por segundo a través de HTTP (archivos de prueba de 20B a 12kB con recuento variable de conexiones HTTP / cliente). El tráfico saliente sostenido está más allá de 2.4 Gb / s. La producción solo tendrá interfaces de 1 Gb / s. No puedo hacer nada mejor que el hardware, ni siquiera tiene sentido probar Varnish.

Almacenamiento en caché de contenido dinámico cambiante complejo

Los servidores CDN y de almacenamiento en caché generalmente ignoran la URL con parámetros como ?article=1843, ignoran cualquier solicitud con cookies de sesión o usuarios autenticados, e ignoran la mayoría de los tipos MIME, incluido el application/jsonde /api/article/1843/info. Hay opciones de configuración disponibles, pero por lo general no son de grano fino, sino "todo o nada".

Barniz puede tener reglas complejas personalizadas (ver VCL) para definir qué se puede almacenar en caché y qué no. Estas reglas pueden almacenar en caché contenido específico por URI, encabezados y cookies de sesión de usuario actual y tipo MIME y contenido TODOS JUNTOS. Eso puede ahorrar mucha potencia de procesamiento en los servidores web para un patrón de carga muy específico. Ahí es cuando Varnish es útil y GENIAL.

Conclusión

Me tomó un tiempo entender todas estas piezas, cuándo usarlas y cómo encajan. Espero que esto le pueda ayudar.

Eso resulta ser bastante largo (6 horas para escribir. OMG!: O). Tal vez debería comenzar un blog o un libro sobre eso. Dato curioso: no parece haber un límite en la longitud de la respuesta.

Es cierto que las 3 herramientas comparten características comunes. La mayoría de las configuraciones están bien con cualquier combinación de 2 entre 3. Depende de cuál sea su propósito principal. Es común aceptar sacrificar algo de almacenamiento en caché si sabe que su servidor de aplicaciones es rápido en estática (por ejemplo: nginx). Es común sacrificar algunas características de equilibrio de carga si vas a instalar decenas o cientos de servidores y no te importa sacar el máximo provecho de ellos ni resolver problemas. Es común sacrificar algunas características del servidor web si tiene la intención de ejecutar una aplicación distribuida con muchos componentes en todas partes. Aún así, algunas personas construyen granjas interesantes con todos ellos.

Debes tener en cuenta que estás hablando de 3 productos sólidos. En general, no necesitará cargarlos para equilibrarlos. Si necesita SSL frontal, entonces nginx primero como proxy inverso está bien. Si no necesita eso, entonces el barniz en el frente está bien. Luego puede poner haproxy para equilibrar la carga de sus aplicaciones. A veces, también querrá cambiar a diferentes granjas de servidores en el propio haproxy, dependiendo de los tipos de archivos o rutas.

A veces tendrás que protegerte contra ataques DDoS pesados, y el haproxy en el frente será más adecuado que los otros.

En general, no debe preocuparse por qué compromiso hacer entre sus elecciones. Debe elegir cómo ensamblarlos para obtener la mejor flexibilidad para sus necesidades ahora y en el futuro. Incluso si apila varias de ellas varias veces, a veces puede ser correcto según sus necesidades.

Esperando que esto ayude!

Todas las demás respuestas son anteriores a 2010, por lo tanto, agregan una comparación actualizada.

Nginx

• Un servidor web completo, otras funciones también se pueden utilizar. Por ejemplo: Compresión HTTP
• Soporte SSL
• Muy ligero ya que Nginx fue diseñado para ser ligero desde el principio.
• Rendimiento de almacenamiento en caché cercano al barniz
• Cerca del rendimiento de equilibrio de carga HAProxy

Barniz

• ideal para escenarios de almacenamiento en caché complejos e incorporación con las aplicaciones.
• mejor cacher de archivos estáticos
• Sin soporte SSL
• Memoria y CPU

Haproxy

• El mejor equilibrador de carga, para funciones de equilibrio de carga de vanguardia, comparable a equilibradores de carga de hardware
• SSL es compatible desde 1.5.0
• Más simple, ser solo un proxy tcp sin una implementación http, lo que lo hace más rápido y menos propenso a errores.

Entonces, el mejor método parece ser implementarlos todos en un orden apropiado.

Sin embargo, para fines generales, Nginx es mejor ya que obtiene un rendimiento superior al promedio para todos: almacenamiento en caché, proxy inverso, equilibrio de carga , con muy poca sobrecarga en la utilización de recursos. Y luego tiene SSL y funciones completas de servidor web.

Varnish tiene soporte para el equilibrio de carga: http://www.varnish-cache.org/trac/wiki/LoadBalancing

Nginx tiene soporte para el equilibrio de carga: http://wiki.nginx.org/NginxHttpUpstreamModule

Simplemente configuraría esto con barniz + stunnel. Si necesitaba nginx por alguna otra razón, simplemente usaría nginx + barniz. Puede hacer que nginx acepte conexiones SSL y que las use como proxy para barnizar, luego haga que barniz hable con nginx a través de http.

Algunas personas pueden agregar nginx (o Apache) a la mezcla porque son herramientas de propósito algo más generales que Varnish. Por ejemplo, si desea transformar el contenido (por ejemplo, usando XDV, filtros de apache, etc.) en la capa proxy, necesitaría uno de estos, porque Varnish no puede hacerlo por sí mismo. Algunas personas pueden estar más familiarizadas con la configuración de estas herramientas, por lo que es más fácil usar Varnish como caché simple y hacer el equilibrio de carga en otra capa porque ya están familiarizados con Apache / nginx / haproxy como equilibrador de carga.