caching - ¿Procesamiento posterior de solicitudes HTTP con proxy inverso?(como el ESI de Akamai)
amazon reverse-proxy (4)
Sé que algunas personas han escrito sobre el uso de nginx SSI con el módulo Memcache nginx para unir fragmentos de contenido. Es mucho más limitado que algo como ESI, pero sigue siendo útil.
Ejecutamos un sitio de contenido de volumen relativamente alto. Al igual que la mayoría de los sitios de contenido, la mayoría de cada página es relativamente estática. Los artículos rara vez cambian, lo que los convierte en buenos candidatos para alguna forma de almacenamiento en caché estático / borde. Sin embargo, hay dos grandes problemas. Los elementos secundarios de la página (navegación, listas de contenido reciente, etc.) cambian con bastante frecuencia, invalidando rápidamente las páginas "completas" almacenadas en caché. También es bastante común que incluyamos más bits dinámicos en una página, como información específica del usuario, etc.
Sería realmente bueno tener un equilibrador de carga / proxy inverso que el contenido posprocesado y que podamos manejar incluya en el proxy / edge. La solicitud inicial al backend devolvería una plantilla aproximada, luego el software proxy podría procesar esa plantilla para completarla. El marcado podría verse más o menos así:
<html>
<body>
<div id="content">
Lorem ipsum whackem smackem.
<%
dynamic "http://related.content.service/this/story"
%>
</div>
<div id="sidebar">
<%
dynamic do |request|
url = "http://my.user.service/user-widget.html"
if request.cookies.contains?("user_token")
url = "http://my.user.service/" + request.cookies["user_token"] + "/user-widget.html"
end
error_text = "User service not available"
{ :url => url, :timeout => 500, :error => error_text }
end
%>
</div>
</body>
</html>
Lo que verá en ese ejemplo es un pequeño rubí que determina el archivo incluido en función del valor de una cookie, luego devuelve un hash con la URL para extraer, un tiempo de espera y un texto predeterminado para mostrar en el caso de una error. En teoría, todas las inclusiones podrían solicitarse de forma asíncrona también.
Tengo entendido que Amazon hace algo como esto. Los servicios de back-end generan varios componentes de página, con límites estrictos de tiempo de espera para garantizar la velocidad general de la página. Esperaba que su servicio CDN incluyera algo como esto, ¡pero no es así!
Hay una especificación W3 para Edge Side Includes (ESI) es casi lo que quiero. Sin embargo, hay muy poco apoyo para eso. Está disponible a través de Akamai, hay algún software de Oracle que lo hace, y el caché de Varnish de código abierto tiene una implementación muy básica. También es un formato XML realmente feo.
Entonces la pregunta es: ¿qué me dejará hacer lo que quiero? ¿Alguien más está haciendo las cosas de esta manera?
configure Nginx como front-end y use SSI para elegir las partes dinámicas de las páginas. La fuente dinámica puede ser un servidor HTTP, como Apache, o un servidor FastCGI, por ejemplo, PHP o Django.
editar:
Muchos servidores web admiten alguna forma de SSI (Server Side Includes), esta característica le permite agregar algunas etiquetas en el HTML como una forma muy limitada de scripts, mucho más simple y más rápida (y más antigua) que PHP. Al usar esto, puede establecer páginas estáticas con la mayor parte del contenido, y para las ''pequeñas partes dinámicas'', una etiqueta SSI hace referencia a una página dinámica generada en otro lugar.
Particularmente me gusta nginx como interfaz para casi cualquier cosa. es muy rápido, ligero en recursos y enormemente escalable (piense en un código más limpio y estable). el autor lo describe no como un servidor web de propósito general; pero como una interfaz de proxy. Los backends pueden ser un servidor HTTP (generalmente Apache) o procesos FastCGI (PHP, Python, Perl, lo que sea), o una granja de cualquiera de los dos, o ambos.
el módulo memcached es increíble, utiliza memcached (que es la tabla hash distribuida de uso general más rápida y escalable) para relacionar directamente una página web con una URL, sin acceso al disco. dado que a memcached se puede acceder desde "fuera" del servidor web, se puede usar incluso con páginas dinámicas (con una URL sana / asignación de recursos); pero no creo que ayude mucho en tu caso. en cualquier caso, primero haga que funcione con SSI, luego puede (si es necesario) optimizar la parte dinámica con memcached.
Así que resulta que Varnish tiene (y tuvo) soporte básico de ESI que hace casi todo lo que yo quería. Si alguien necesita hacer algo de ESI, Varnish parece funcionar bastante bien para eso. Es bastante básico, pero aún impresionante.
Akamai tiene una solución para Edge Computing que permite que J2EE se ejecute en Edge. Otras alternativas hoy incluyen cualquier servicio de Cloud Computing: Rackspace y Amazon son un par de jugadores en este mercado. Lo ideal sería utilizar una combinación de CDN y Cloud Computing para obtener el resultado deseado. Además, puede optar por que el contenido dinámico se sirva de manera asincrónica a través de un servicio web después de que se cargue la plantilla de página y luego simplemente almacenar en caché el contenido de la página estática con la plantilla html.