Netty vs Apache MINA

Entrambi forniscono all'incirca la stessa funzionalità. Quale dovrei scegliere per sviluppare il mio server TCP ad alte prestazioni? Quali sono i pro e i contro?

Link di riferimento:

Apache MINA ( fonte )

Netty ( fonte )

Mentre MINA e Netty hanno ambizioni simili, nella pratica sono abbastanza diverse e dovresti considerare attentamente la tua scelta. Siamo stati fortunati perché abbiamo avuto molta esperienza con MINA e abbiamo avuto il tempo di giocare con Netty. Abbiamo apprezzato in particolare l'API più pulita e una documentazione molto migliore. Le prestazioni sembravano migliori anche sulla carta. Ancora più importante, sapevamo che Trustin Lee sarebbe stato pronto a rispondere a qualsiasi domanda avessimo, e sicuramente lo ha fatto.

Abbiamo trovato tutto più facile in Netty. Periodo. Mentre cercavamo di reimplementare la stessa funzionalità che avevamo già su MINA, lo abbiamo fatto da zero. Seguendo l'eccellente documentazione ed esempi abbiamo finito con più funzionalità in molto, molto meno codice.

La Netty Pipeline ha funzionato meglio per noi. È in qualche modo più semplice dei MINA, in cui tutto è un gestore e spetta a te decidere se gestire eventi a monte, eventi a valle, entrambi o consumare più cose di basso livello. Divulgare byte nel "riprodurre" i decodificatori è stato quasi un piacere. È stato anche molto bello poter riconfigurare la pipeline al volo così facilmente.

Ma l'attrazione principale di Netty, imho, è la capacità di creare gestori di condutture con una "copertura di uno". Probabilmente hai già letto questa annotazione sulla copertura nella documentazione, ma essenzialmente ti dà lo stato in una singola riga di codice. Senza problemi, mappe di sessioni, sincronizzazione e cose del genere, siamo stati semplicemente in grado di dichiarare variabili regolari (diciamo "nome utente") e usarle.

Ma poi abbiamo raggiunto un blocco. Avevamo già un server multiprotocollo sotto MINA, in cui il nostro protocollo applicativo funzionava su TCP / IP, HTTP e UDP. Quando siamo passati a Netty abbiamo aggiunto SSL e HTTPS all'elenco in pochi minuti! Fin qui tutto bene, ma quando si è trattato di UDP ci siamo resi conto di essere scivolati. MINA è stata molto gentile con noi in quanto potevamo trattare UDP come un protocollo "connesso". Sotto Netty non esiste tale astrazione. UDP è senza connessione e Netty lo tratta come tale. Netty espone più della natura senza connessione di UDP a un livello inferiore rispetto a MINA. Ci sono cose che puoi fare con UDP sotto Netty che non puoi sotto l'astrazione di livello superiore che MINA fornisce, ma su cui ci siamo affidati.

Non è così semplice aggiungere un wrapper "UDP connesso" o qualcosa del genere. Dati i vincoli temporali e il consiglio di Trustin secondo cui il modo migliore di procedere era implementare il nostro fornitore di servizi di trasporto a Netty, il che non sarebbe stato rapido, alla fine abbiamo dovuto abbandonare Netty.

Quindi, osserva attentamente le differenze tra loro e raggiungi rapidamente una fase in cui puoi testare qualsiasi funzionalità complessa funzioni come previsto. Se sei soddisfatto del fatto che Netty farà il lavoro, non esiterei a seguirlo su MINA. Se stai passando da MINA a Netty, lo stesso vale, ma vale la pena notare che le due API sono davvero significativamente diverse e dovresti considerare una riscrittura virtuale per Netty: non te ne pentirai!

MINA ha più funzioni pronte all'uso a scapito della complessità e delle prestazioni relativamente scarse. Alcune di queste funzionalità sono state integrate nel core troppo strettamente per essere rimosse anche se non sono necessarie all'utente. In Netty, ho cercato di affrontare tali problemi di progettazione mantenendo i punti di forza noti di MINA.

Attualmente, la maggior parte delle funzionalità disponibili in MINA sono disponibili anche in Netty. Secondo me, Netty ha API più pulite e più documentate poiché Netty è il risultato del tentativo di ricostruire MINA da zero e affrontare i problemi noti. Se trovi che manca una funzionalità essenziale, non esitare a pubblicare i tuoi suggerimenti sul forum. Sarei felice di rispondere alla tua preoccupazione.

È anche importante notare che Netty ha un ciclo di sviluppo più rapido. Semplicemente, controlla la data di rilascio delle versioni recenti. Inoltre, dovresti considerare che il team MINA procederà a una riscrittura importante, MINA 3, il che significa che interromperanno completamente la compatibilità API.

Ho testato le prestazioni di 2 implementazioni "Google Protobuffer RPC" in cui una era basata su Netty (netty-protobuf-rpc) e l'altra basata su mina (protobuf-mina-rpc). Netty ha finito per essere costantemente più veloce (+ - 10%) per tutte le dimensioni dei messaggi - il che conferma la richiesta di prestazioni complessive sul sito web di Netty. Dato che vuoi spremere ogni minima efficienza dal tuo codice quando usi una libreria RPC, ho finito per scrivere protobuf-rpc-pro basato su Netty. Ho usato MINA in passato, ma trovo che la loro documentazione relativa alle cose 2.0 abbia grandi buchi e che la rottura della compatibilità con le API all'indietro sia un grande svantaggio.

MINA e Netty sono stati inizialmente progettati e realizzati dallo stesso autore. Ecco perché sono così simili tra loro. MINA è progettata a un livello leggermente superiore con un po 'più di funzionalità, mentre Netty è un po' più veloce. Penso che non ci sia molta differenza, i concetti di base sono gli stessi.

Nel sito Netty è possibile trovare alcuni rapporti sulle prestazioni . Come previsto :-) indicano Netty come il framework con le migliori prestazioni.

Non ho mai usato Netty, ma ho già usato MINA per implementare un protocollo TCP. L'implementazione della codifica e decodifica è stata semplice, ma l'implementazione della macchina a stati non è stata così semplice. MINA fornisce alcune classi per aiutarti nell'implementazione della macchina a stati, ma le ho trovate difficili da usare. Alla fine abbiamo deciso di abbandonare MINA e implementare il protocollo da zero, e sorprendentemente abbiamo finito con un server più veloce.

Preferisco Netty.

Twitter ha anche scelto Netty per costruire il suo nuovo sistema di ricerca e accelerarlo fino a 3 volte più velocemente.

Rif: Twitter Search è ora 3 volte più veloce

Abbiamo scelto Netty rispetto ad alcuni dei suoi concorrenti, come Mina e Jetty, perché ha un'API più pulita, una migliore documentazione e, soprattutto, perché molti altri progetti su Twitter utilizzano questo framework.

Ho sempre usato MINA per costruire un piccolo server http come. I maggiori problemi che ho riscontrato finora:

1. Conterrà la "richiesta" e la "risposta" in memoria. Questo è solo un problema perché il protocollo che scelgo di usare è http. Tuttavia, è possibile utilizzare il proprio protocollo per aggirare il problema.
2. Nessuna opzione per fornire un flusso dal disco nel caso in cui si desideri pubblicare file di grandi dimensioni. Ancora una volta può essere aggirato implementando il proprio protocollo

Belle cose a riguardo:

1. Può gestire molte connessioni
2. Se si sceglie di implementare una sorta di sistema di lavoro distribuito, sapere quando uno dei nodi si interrompe e perde la connessione è utile per riavviare il lavoro su un altro nodo.