Construir servicios web altamente escalables

Mi equipo y yo estamos en el medio de desarrollar una aplicación que necesita ser capaz de manejar un tráfico bastante pesado. No en Facebook, pero en el futuro me gustaría poder escalar sin volver a escribir código masivo.

Mi idea era modular todo en servicios separados con sus propias interfaces. Así que, por ejemplo, la mensajería tendría una interfaz de mensajería que podría tener send y getMessages () como métodos y luego la aplicación web PHP simplemente consultaría esta interfaz a través de soap o curl o algo así. La aplicación de mensajería podría ser cualquier tipo de aplicación para que una aplicación Java o Python o lo que sea sea adecuada para esa funcionalidad en particular con su propio fragmento de base de datos separado.

¿Es este un buen enfoque?

Modular

Mi idea era modular todo en servicios separados con sus propias interfaces. Entonces, por ejemplo, la mensajería tendría una interfaz de mensajería que podría tener send y getMessages () como métodos y luego la aplicación web de PHP simplemente consultaría esta interfaz mediante soap o curl o algo así

Me gusta la idea de separar cada uno de los módulos de servicio (buen principio de encoding). No me gusta la parte sobre SOAP :(. Creo que es un camino complejo. Iría por algo como JSON-RPC o algo así.

Algunos consejos rápidos:

Mi equipo y yo estamos en el medio de desarrollar una aplicación que necesita ser capaz de manejar un tráfico bastante pesado. No en Facebook, pero en el futuro me gustaría poder escalar sin volver a escribir código masivo.

  • Al igual que los demás, también insinué que te aconsejaría que busques en el blog High Scalability .
  • Primero concéntrese en el front-end usando la velocidad de la página YSlow / google. Esta optimización es fácil de implementar y puede brindarle impulsos significativos. Una cita de la página web de Yslow:

El 80% del tiempo de respuesta del usuario final se gasta en el front-end. La mayor parte de este tiempo está relacionado con la descarga de todos los componentes de la página: imágenes, hojas de estilo, scripts, Flash, etc. La reducción del número de componentes reduce la cantidad de solicitudes HTTP requeridas para representar la página. Esta es la clave para páginas más rápidas.

  • También le aconsejo que eche un vistazo a HipHop para php, que convierte su código php en código C, que fue un gran impulso para Facebook. Una cita del artículo:

Con HipHop, hemos reducido el uso de la CPU en nuestros servidores web en un promedio del cincuenta por ciento, dependiendo de la página. Menos CPU significa menos servidores, lo que significa menos gastos generales

  • Supongo que otra mejora grande / fácil si no es la configuración es utilizar APC (caché de código de operación) para almacenar en caché su código comstackdo. Esto le dará un gran impulso (no es necesario para las piezas convertidas a HipHop).
  • Si desea que sus sitios web se amplíen, debe seguir el siguiente lema:

    RAM es el nuevo disco

    ! Caché, caché, caché! con, por ejemplo, APC, memcached , redis .

  • Primero perfila tu código PHP y luego optimiza la fruta baja. Encontré este archivo de audio de Rasmus Lerdorf realmente útil. Al leer la publicación del blog, encontrará muchos buenos consejos para mejorar el rendimiento.
  • También consideraría alejarme de la base de datos de relaciones a favor de, por ejemplo, Cassandra . Este es un movimiento que veo muchos jugadores importantes recientemente (por ejemplo, twitter, digg, facebook, reddit). Tendrás que adoptar una mentalidad completamente diferente de esta manera, pero mi apuesta es que valdrá la pena el esfuerzo.
  • Ponga en cola todo y deleite a todos con, por ejemplo, la tarea de beanstalkd , gearman o google app engine.

Eso suena razonable como primer paso, solo tenga en cuenta que el tráfico entre la capa de PHP y la capa de mensajería agregará un poco de latencia. También podrías considerar:

  • Almacenamiento en caché de datos en la capa PHP, utilizando (por ejemplo) memcached . También puede considerar el uso de un caché proxy web como calamar

  • Escalar su servidor web a más de una máquina, por ejemplo, almacenando datos de sesión en la base de datos. Una vez que pueda admitir tener 2 servidores web, agregar un tercero (cuarto, quinto, etc.) debería ser simple. Tenga en cuenta que posiblemente también necesite escalar la capa de mensajes a varias máquinas.

  • Usar herramientas como PHP e-Accelerator para almacenar en caché scripts comstackdos; debería ayudar a boost el rendimiento en la capa web

También hay algunos excelentes artículos sobre Alta escalabilidad , que pueden ser útiles.

Finalmente, tenga en cuenta que es fácil sobre-diseñar una solución. Su mejor opción es medir continuamente la carga, el rendimiento, la utilización de los recursos, etc. a lo largo del camino; luego, use estos datos para hacer los ajustes necesarios.

Caché, caché y más caché. Almacenamiento en caché de consultas SQL, almacenamiento en caché de código de operación, evite consultas varias veces para obtener el mismo resultado. Luego usa un generador de perfiles mientras corres para saber dónde están tus puntos lentos.

Basar el diseño de alto nivel en un conjunto de módulos es una buena forma de gestionar la complejidad y el desarrollo de la estructura (incluso más que a nivel micro) sin embargo

la aplicación web PHP simplemente consulta esta interfaz a través de soap o rizo

Esto introduce mucha latencia en la aplicación. Sugeriría definir API, pero para cualquier solicitud gestionada de forma síncrona, ejecute tanto código como sea posible en un único hilo.

Claro, si tiene que lidiar con múltiples lenguajes de desarrollo, usar una interfaz que se ejecute sobre HTTP es una solución muy pragmática, pero si está desarrollando la interfaz en PHP entonces progtwigndo una API abstracta de PHP (que puede llamarse Soap, Corba) , u otras cosas), todavía tienes la opción de volver a implementar el servidor de una manera diferente más tarde.

No estoy seguro de lo que quieres decir con mensajes. Si está hablando de procesamiento de solicitudes asíncronas, entonces debe pensar en cómo implementar un suscriptor en PHP. Esta es una lata de gusanos completa. No he visto un buen sistema de manejo de mensajes escrito en PHP, pero tampoco he visto una buena solución escalable escrita en Java, y eso incluye los productos robados por algunos de los principales jugadores de gama alta. sistemas. Tal vez algún día escriba uno;) mientras tanto, realmente desea mantener su compleja (y potencialmente menos confiable) lógica de negocios ejecutándose en un hilo separado de cualquier tipo de daemon de suscriptor, por lo que una forma obvia de hacerlo es exponer el objective como una página web y hacer que el suscriptor se ejecute como un daemon que simplemente capta mensajes y llama a API basadas en la web.

Realmente no desea basar un sistema síncrono en la mensajería si le preocupa el rendimiento / confiabilidad / escalabilidad.

HTH

DO.

    Intereting Posts