5
Tenemos un sistema que, dado un lote de solicitudes, realiza un número equivalente de llamadas a una API externa de terceros. Dado que se trata de una tarea enlazada de E/S, actualmente usamos un grupo de subprocesos en caché de tamaño 20 para atender estas solicitudes. Excepto lo de arriba, es la solución a:software/hardware de escalado para un gran número de solicitudes externas de API?
Uso menos máquinas con más núcleos (menos del contexto de conmutación, capaz de soportar más hilos concurrentes)
o
uso más máquinas aprovechando el hardware básico/barato (cajas de pizza)
El número de solicitudes que recibimos por día está en el orden de millones.
Estamos usando Java, por lo que los hilos aquí son núcleo, no "verde".
Puntos Otros/Pensamientos:
- Hadoop se utiliza comúnmente para problemas de esta naturaleza, pero esto tiene que ser en tiempo real frente a la minería de datos en línea estereotipada.
- Las solicitudes de API tomar de 200 ms y 2 segundos en promedio
- No hay un estado compartido entre las peticiones
- La tercera Parte en cuestión es capaz de dar servicio a más solicitudes de las que puede posiblemente el fuego (pagos a proveedores).
¿Tiene estado compartido, usado para manejar solicitudes? Si es así, ¿con qué frecuencia está cambiando? ¿Cuál es el tamaño de este estado compartido? –
¿Cuál es el límite en la API de terceros?No tiene sentido escalar tu pila si la API que llamas sigue siendo el cuello de botella. ¿Puede almacenar en caché los datos que recibe de él o utilizar los datos de una llamada al servicio/suministrar a muchos de sus clientes al mismo tiempo? – Paolo
Edité mi publicación original para responder a las preguntas anteriores. Las llamadas son completamente independientes, por lo que no hay datos para almacenar en caché. – smonky