Quando dovrei usare Reactive web framework

Question

Quando dovrei usare Reactive web framework

Naviga le tue risposte

#1 da (1 voti)

0

Quando si costruisce un Apis web standard nel mondo Java ci sono due modi che potrei fare oggigiorno

Utilizza SpringMVC (non reattivo)
Usa SpringWebFlux (Reattivo)

Ci sono alcuni vantaggi dell'utilizzo di Reactive a cui posso pensare

Utilizza meno risorse di memoria in quanto c'è meno thread in esecuzione (forse meglio per una distribuzione basata su container)
È meglio per lo scenario in cui la tua API potrebbe dover chiamare altri apis e non vuoi pensare al problema della concorrenza (questo può essere fatto anche nel webmvc tradizionale, ma poi devi usare completableFuture etc mentre in reattivo lasci che il framework lo gestisca)

Ci sono pochi svantaggi che posso pensare quando si utilizza Reactive

Complessità del codice, poiché ora tutto è incatenato e devi occuparti di non bloccare il thread e devi essere consapevole del fatto che non esiste ThreadLocal in quanto tali operazioni come la registrazione usando MDC sono più complicate ora
Aumento della latenza in quanto ora ci sono meno thread

Uno dei punti di forza del modo reattivo di fare le cose è il concetto di backpressure ma quando si arriva alla normale richiesta / risposta in web apis non viene usato come o lo si elabora o lo si fa non c'è nessun processo lungo la catena che ridurrà la produzione di dati.

Non sono sicuro che il vantaggio di cui sopra possa valere la complessità di un web apis. Mi piacerebbe sentire pensieri su questo. Se web apis non è il posto giusto per usare reattivo dove penseresti sia il posto giusto per usarlo. O se il modo reattivo è il modo per farlo, allora non significa che non c'è più posto per il modo tradizionale di fare webmvc?

architecture architectural-patterns reactive

posta tabiul 18.12.2018 - 00:17

fonte

1 risposta

Leggi altre domande sui tag architecture architectural-patterns reactive

Microservice / Soa: come attivare la notifica a seconda del chiamante? Architettura di classe C # per servizi REST

score 1 · Answer 1

Il motivo principale per utilizzare un'architettura reattiva (leggi: asincrona) per un server Web è che sono molto più efficienti in termini di velocità effettiva e di conseguenza possono scalare verticalmente molto meglio di servlet / un thread-per-connessione classico Modelli. Questa efficienza si traduce in una maggiore robustezza sotto carico, migliori velocità di connessione e latenze (durante il ridimensionamento orizzontale) e, infine, una migliore esperienza utente.

In risposta alla tua altra domanda:

Or if reactive way is the way to do it then does not mean there is no place any more for traditional webmvc way of doing things?

C'è un posto per questo: quando la scalabilità non è un fattore o quando viene aggiunta la complessità aggiunta (anche se "la non familiarità" potrebbe essere più accurata) aggiungerebbe troppo ai costi di manutenzione del software complessivo. Ad esempio, il web server integrato di Python, o l'interfaccia di gestione della stampante basata sul web di CUPS, sono buoni esempi di quando un server web molto semplice è perfettamente appropriato per l'utilizzo.

Tuttavia, una API web deve gestire migliaia di connessioni simultanee quasi per definizione. Quindi considererei l'utilizzo di un framework reattivo (come Spring WebFlux) un requisito assoluto se si sta partendo da zero. I benefici superano sicuramente i costi di formazione.