Al momento ho una configurazione simile a questa:
__________________ _________ ________ ___________
| Front end server |----| Varnish |----| NodeJS |----| C-service |
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾ ‾‾‾‾‾‾‾‾‾ ‾‾‾‾‾‾‾‾ ‾‾‾‾‾‾‾‾‾‾‾
NodeJS e C-service vengono eseguiti sullo stesso server virtuale.
Il front-end potrebbe avere centinaia di client collegati: ognuno di questi può generare centinaia di richieste simultanee al servizio C, quindi le richieste risultanti al servizio C saranno numerate a migliaia.
Da esperienze precedenti so che i socket possono gestire solo un limite di connessioni in attesa (backlog). Per gestirlo ho implementato una coda di messaggi in NodeJS (converte anche messaggi HTTP in messaggi che il C-service capisce, ma questa è una cosa minore che potrei fare nel C-service).
Problema:
- Varnish gestisce facilmente le migliaia di richieste
- Il C-service può tenere il passo con le migliaia di richieste, purché siano in coda.
- NodeJS ... Non così tanto. (Ho provato il clustering, ma a causa di altri problemi di implementazione questa non è un'opzione.)
In altre parole, ho un server NodeJS che limita seriamente il mio throughput, ma non so in quale altro modo gestire le richieste concomitanti.
Ho esaminato broker di messaggi come Kafka / RabbitMQ / ZeroMQ, ma non sembrano gestire il mio problema di base relativo al collegamento di un servizio HTTP (Varnish) a un socket di dominio TCP / Unix sottostante con l'accodamento dei messaggi. Non sono sicuro che siano adatti anche per il funzionamento sincrono.
Questo è l'approccio sbagliato? Che altro potrei fare?
Ho bisogno che le risposte siano inviate in modo sincrono, ma non necessariamente nello stesso ordine in cui vengono inviate da Varnish (posso eseguire più istanze del servizio C per un migliore utilizzo della CPU, nel qual caso l'invio delle risposte in ordine rallenterebbe cose giù).