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.