Il miglior approccio per il servizio web che chiama altri servizi web

Naviga le tue risposte
0

Lo scenario è:

    Il client
  1. effettua la richiesta al server A
  2. Il server A rende potenzialmente multiple richieste al server B. Modifica per chiarire, il server A effettua le richieste contemporaneamente usando Futures.
  3. Server A blocchi fino al ritorno di tutti i risultati
  4. Il server A raggruppa le risposte nella singola risposta e ritorna al client

Quindi attualmente l'approccio è il blocco che utilizza java Futures e restituisce i risultati quando entrano. La mia preoccupazione è che è piuttosto impegnativa e sono preoccupato che esauriremo le risorse sul server. Stavo pensando di andare asincrono nel server A usando DeferredResult ma dal momento che c'è una discussione per ogni richiesta al server B, sembra che non porti molti benefici.

In alternativa, potremmo fare

  1. Il server A effettua più richieste al server B
  2. Il server B immediato restituisce un token per ogni richiesta
  3. Il server A tiene traccia dei token e restituisce DeferredResult
  4. Il server B ottiene ogni risultato, lo inserisce in memcache, invia un messaggio JMS al server A. Modifica: ho appena realizzato che potevo inviare il risultato nel messaggio JMS, quindi non c'è bisogno di memcache.
  5. Il server A può completare il DeferredResult dopo aver raccolto tutte le risposte da JMS.

Questo ha il vantaggio di essere molto più semplice nel codice (nessun complicato lavoro futuro) al costo di essere più complicato dal punto di vista dell'architettura. Introduce anche più livelli (JMS) per il fallimento. Ha anche il vantaggio di essere molto meno dispendioso in termini di risorse.

Questo è un sistema ad alto utilizzo. Le chiamate al sistema B possono richiedere da 1 a diversi secondi.

    
posta hvgotcodes 08.08.2018 - 16:25
fonte

1 risposta

0

Penso che il tuo piano originale suoni meglio della "alternativa" che hai descritto. BACIO. Il tuo approccio attuale è molto semplice.

Strutturalmente ciò che stai facendo non ha bisogno di essere thread-intensive (non più di un thread per servire la chiamata). È possibile richiamare molte chiamate al servizio B semplicemente richiamando attività asincrone. Forse è già così che Java Future < > l'implementazione funziona (non sono sicuro - dovrebbe apparire). altro articolo di overflow dello stack sembra indicarlo funziona in questo modo Altrimenti, puoi utilizzare un altro meccanismo java per richiamare richieste web asincrone.

Se il tuo motore di servizio web nel server A è stato scritto appositamente per gestire gli oggetti DeferredResult (ne dubito, ma puoi controllare), allora il tuo piano per usare DeferredResult funzionerebbe bene. Ma molto probabilmente, il tuo webservice forzerà semplicemente una chiamata GET sul risultato della chiamata a websevice e bloccherà il thread di gestione delle chiamate del servizio web mentre il lavoro termina da dove proviene.

Hai suggerito la possibilità di un'altra strategia. A seconda della natura delle tue chiamate da ServerA a ServerB, forse quelle potrebbero essere velocizzate o memorizzate nella cache. Usando qualcosa come redis / memchached (o solo una cache di memoria all'interno del tuo ServerA) POTREBBE essere un modo efficace per rendere il tuo throughput complessivo molto più veloce, ma questo dipende INTERAMENTE dalla capacità di cachability delle chiamate da ServerA a ServerB (di cui non hai detto nulla) . Se vuoi sperimentare questo approccio al caching, usa una HashMap e qualche astrazione per contare gli hit / miss, per vedere quanto è efficace l'approccio, prima di provare a scalare qualcosa di più complesso come memcached.

    
risposta data 08.08.2018 - 16:48
fonte

Leggi altre domande sui tag

Come dovrei memorizzare più modelli correlati quando è richiesto il controllo della configurazione? Chiarimento sul servizio di dominio e sul servizio applicativo dell'architettura di Onion