¿Cuál es la mejor arquitectura o marco para implementar un servicio firehose como Twitter Firehose?

Es difícil responder a este tipo de preguntas sin comprender al menos algunos de los parámetros de su servicio. Antes de comenzar, haría al menos algunas de las siguientes preguntas

  1. ¿Quiénes son los clientes de su API? Si se trata de navegadores, es probable que desee recorrer el camino de WebSocket más temprano que tarde. Si se trata de clientes de escritorio o un juego de servidor a servidor, probablemente pueda hacer JSON por un tiempo.
  2. ¿Cómo está recibiendo mensajes en su servicio? Esta decisión es probablemente tan importante como la forma en que construye el servicio real, y puede impulsar algunas de las decisiones tecnológicas en torno a la construcción de la API.
  3. ¿Cuáles son los parámetros operativos de su servicio? ¿Cuántos mensajes / bytes en / seg? ¿Cuántos mensajes / bytes salen / seg? ¿Cuántos clientes concurrentes? ¿Cuánto tiempo dura una conexión? ¿Cuál es la demora aceptable del percentil 99 en la entrega de mensajes? ¿Cuáles son las especificaciones de hardware para su host? ¿Cuántos de ellos en el grupo?
  4. ¿Cómo cambiarán los parámetros operativos en 3 meses? ¿12 meses?

Node.js es probablemente una buena opción, pero probablemente pueda hacer que casi cualquier idioma funcione en una escala de 10 a 100 mensajes por segundo. Usamos Scala en Twitter, lo que significa que tratamos con JVM JIT y GC. No ha sido un problema para nosotros en este sistema, pero estamos dispuestos a tolerar los ocasionales problemas de entrega de 100 ms cuando se comparan con los beneficios que nos brinda la JVM.

En cuanto al formato / protocolo de mensaje, parece que WebSockets es el futuro, pero el soporte en el presente es desigual. Preferimos JSON, ya que es ampliamente compatible, más compacto que XML, más rápido de analizar que XML (comparado con Scala XML y StAX vs. GSON y Jackson), y nuestros formatos de mensaje no son lo suficientemente complejos como para garantizar una escritura y definición más fuertes que Ofertas XML.

Primero, ¡debes pensar en la intención!
Si desea permitir que los clientes de escritorio no tiren, debe elegir un protocolo con conexiones mantenidas. La transmisión HTTP es una opción (¡la transmisión Atom de LiveJournal es el ejemplo vivo más antiguo que conozco!), Pero otras opciones como XMPP también son perfectamente válidas (y estándar, que no debe subestimar si desea facilitarlo) personas para construir sobre su API de transmisión).

Si te gusta más el juego de servidor a servidor, definitivamente recomendaría usar PubSubHubbub y feeds virtuales. Esa es la forma elegida por Tumblr, Posterous, Gowalla, Google Buzz, Etsy … etc. Es tan flexible como la transmisión HTTP, porque también se basa en HTTP, pero probablemente sea más fácil de escalar. Yo diría que es mucho más fácil enviar muchas solicitudes HTTP que mantener abiertos muchos sockets.

Si está buscando algo fuera de la caja que proporcione todo lo anterior, consulte http://superfeedr.com/publisher . Estoy feliz de ayudarte en ese proceso.

Agregaría una voz adicional al nodo.js: DataSift ( http://datasift.net ) websocket + HTTP Streaming se basa en el nodo, y nos permitió construirlo muy rápidamente. En el camino hemos encontrado una serie de errores, pero el desarrollador es extremadamente receptivo a los comentarios.

Una advertencia real es la velocidad: node.js NO es rápido, pero depende de su definición de rápido, estamos buscando el rendimiento de 10.000 flujos simultáneos por servidor y actualmente el nodo no está a la altura.

Es probable que migremos lejos en el futuro, pero si no necesita esta escala, le dará mucha flexibilidad.