La configuración de mi servidor para una API muy utilizada

Pronto compraré un montón de servidores para una aplicación que estoy a punto de lanzar, pero tengo dudas sobre mi configuración. Agradezco cualquier comentario que reciba.

Tengo una aplicación que utilizará una API que escribí. Otros usuarios / desarrolladores también harán uso de esta API. El servidor API recibirá solicitudes y las transmitirá a los servidores de los trabajadores. La API solo tendrá una base de datos mysql de solicitudes para fines de registro, autenticación y limitación de velocidad.

Cada servidor de trabajo realiza un trabajo diferente y, en el futuro, para escalar, agregaré más servidores de trabajo para que estén disponibles para realizar trabajos. El archivo de configuración de la API se editará para tomar nota de los nuevos servidores de trabajo. Los servidores de trabajo realizarán un procesamiento y algunos guardarán una ruta a una imagen en la base de datos local para que la API la recupere más tarde y la vea en mi aplicación, algunos devolverán cadenas del resultado de un proceso y lo guardarán en una base de datos local. .

¿Esta configuración te parece eficiente? ¿Hay una mejor manera de reestructurar esto? ¿Qué asuntos debo considerar? Por favor, vea la imagen a continuación, espero que ayude a la comprensión.

Mayor disponibilidad

Como Chris menciona, su servidor API es el único punto de falla en su diseño. Lo que está configurando es una infraestructura de colas de mensajes, algo que muchas personas han implementado antes.

Continúa por el mismo camino

Usted menciona recibir solicitudes en el servidor API e inserta el trabajo en una base de datos MySQL que se ejecuta en cada servidor. Si desea continuar en este camino, le sugiero que elimine la capa del servidor API y diseñe los trabajadores para que acepten comandos directamente de sus usuarios de API. Podría usar algo tan simple como DNS redondo para distribuir cada conexión de usuario API directamente a uno de los nodos de trabajo disponibles (y volver a intentar si una conexión no es exitosa).

Utilice un servidor de cola de mensajes

Las infraestructuras de colas de mensajes más robustas utilizan software diseñado para este propósito como ActiveMQ . Puede usar la API RESTful de ActiveMQ para aceptar solicitudes POST de usuarios de API, y los trabajadores inactivos pueden OBTENER el siguiente mensaje en la cola. Sin embargo, esto probablemente sea excesivo para sus necesidades: está diseñado para latencia, velocidad y millones de mensajes por segundo.

Utilice Zookeeper

Como término medio, es posible que desee mirar Zookeeper , a pesar de que no es específicamente un servidor de cola de mensajes. Usamos en $ work para este propósito exacto. Tenemos un conjunto de tres servidores (análogos a su servidor API) que ejecutan el software del servidor Zookeeper, y tenemos una interfaz web para manejar las solicitudes de los usuarios y las aplicaciones. La interfaz web, así como la conexión de back-end de Zookeeper a los trabajadores, tienen un equilibrador de carga para garantizar que continuemos procesando la cola, incluso si un servidor está fuera de servicio por mantenimiento. Cuando finaliza el trabajo, el trabajador le dice al clúster de Zookeeper que el trabajo está completo. Si un trabajador muere, ese trabajo será enviado a otro trabajo para completar.

Otras preocupaciones

• Asegúrese de completar los trabajos en caso de que un trabajador no responda
• ¿Cómo sabrá la API que un trabajo está completo y cómo recuperarlo de la base de datos del trabajador?
• Intenta reducir la complejidad. ¿Necesita un servidor MySQL independiente en cada nodo de trabajo, o podrían hablar con el servidor MySQL (o MySQL Cluster replicado) en los servidores API?
• Seguridad. ¿Alguien puede enviar un trabajo? ¿Hay autenticación?
• ¿Qué trabajador debería obtener el próximo trabajo? No menciona si se espera que las tareas demoren 10 ms o 1 hora. Si son rápidos, debe eliminar las capas para mantener baja la latencia. Si son lentos, debes tener mucho cuidado para asegurarte de que las solicitudes más cortas no se atasquen detrás de algunas de larga duración.

El mayor problema que veo es la falta de planificación de conmutación por error.

Su servidor API es un gran punto único de falla. Si se cae, entonces nada funciona incluso si sus servidores de trabajo siguen siendo funcionales. Además, si un servidor de trabajo deja de funcionar, el servicio que proporciona ese servidor ya no está disponible.

Le sugiero que mire el proyecto del Servidor virtual de Linux ( http://www.linuxvirtualserver.org/ ) para tener una idea de cómo funciona el equilibrio de carga y la conmutación por error, y para tener una idea de cómo estos pueden beneficiar su diseño.

Hay muchas formas de estructurar su sistema. De qué manera es mejor es una llamada subjetiva que es mejor respondida por usted. Le sugiero que investigue un poco; sopesar las compensaciones de los diferentes métodos. Si necesita información sobre un método de implantación, envíe una nueva pregunta.