2010-07-07 10 views
12

Costruiamo un servizio basato su Netty/NIO e sto considerando l'implementazione di questo servizio nel nostro ambiente di produzione. Il nostro modo standard di distribuzione dei servizi è WAR, da distribuire all'interno di Tomcats.L'hosting di un server Netty all'interno di Tomcat è fattibile/desiderabile?

Quando ho suggerito lo stesso approccio qui, ho ricevuto grida e lamentele che "non dovrebbe essere fatto", perché sia ​​Netty che Tomcat sono server, e "non ha senso ospitare un server in un altro" .

Per me ha perfettamente senso perché risolve completamente il mio problema di distribuzione, oltre a consentirmi di scrivere qualche altro codice. Perché è un così grande "no no"?

+0

Potresti essere più specifico sul tuo "problema di distribuzione" e anche "mi ha salvato dalla scrittura di un altro codice"? –

+0

@Romain - Le nostre persone di operazioni hanno script che portano WARs e li distribuiscono su vari tomcats, li interrompono/avviano/etc ... Se non lo ospita in un Tomcat ma piuttosto come un jar autonomo, questi script bisogno di essere regolato "L'altro codice a cui mi riferivo sta esponendo il metodo di servizio via HTTP - abbiamo già il codice per farlo tramite un servlet HTTP standard, che ora avremo bisogno di reimplementare. La domanda è: cosa c'è che non va con il semplice hosting in un Tomcat? – ripper234

+0

Cosa c'è di sbagliato nel ridistribuire una GUERRA? Il vantaggio è che si dispone di un pezzo di codice unificato al quale si esegue il rollback, se necessario. –

risposta

16

La dinamica distribuzione e distribuzione di WAR che Tomcat fornisce sono progettate per le applicazioni Web. L'applicazione Netty che stai tentando di distribuire in Tomcat non è un'applicazione web ma solo un server separato che condivide solo la memoria della VM. Significa che Tomcat è stato riproposto in un microkernel generico come OSGi.

Tuttavia, non penso che sia un grosso problema. Poiché la tua azienda utilizza WAR come meccanismo di distribuzione standard, potrebbe essere una buona idea riutilizzarlo. Non è nemmeno necessario scrivere alcune funzioni di gestione come lo spegnimento remoto perché Tomcat le fornisce già. Tutto quello che devi fare è assicurarti che tutte le risorse vengano liberate quando non dispiegate.

Alcune persone potrebbero non gradire questo approccio. Idealmente, ci dovrebbe essere un'infrastruttura comune per la distribuzione e la gestione di qualsiasi applicazione (nota anche come microkernel), in cui anche Tomcat viene distribuito come modulo e il microkernel gestisce direttamente WAR invece di Tomcat. Ma questa è una lunga strada da percorrere.

+2

Il nostro nuovo standard aziendale è quello di implementare come una guerra, e quasi ogni app utilizza Netty o Mina per il nostro protocollo proprietario. Basta fare attenzione con l'arresto, ma non ci sono grandi problemi finora. Ora se netty potrebbe fare servlet per mvc di primavera saremmo tutti pronti. – Jason

1

Non avviare nulla in Tomcat, è molto scomodo e presenta molti problemi di dolore. Basta incorporare Tomcat (o Jetty) all'interno dell'applicazione e eseguire l'applicazione come semplice processo java.

+0

Ho usato questo approccio alcune volte in produzione e funziona. Con Maven e Jenkins è ancora più divertente. – miloxe

7

Ha un senso fantastico. Di fatto, eseguiamo un server di posta Java in Tomcat.

Tomcat ha alcuni vantaggi enormi per l'alloggiamento di una domanda:

  1. Gli script daemon sono già scritti per voi
  2. Tomcat consente la distribuzione a caldo (fino a quando non si sta usando hibernate :))
  3. A un certo punto potresti aver bisogno di un'interfaccia utente di amministrazione o di un'API di amministrazione
  4. Un sacco di strumenti per monitorare Tomcat che significa monitoraggio gratuito della tua app.

Ora con Netty, Mina o qualsiasi tecnologia di rete basata su eventi, non sarà possibile utilizzare la maggior parte dei framework MVC. In effetti non sarai in grado di utilizzare la maggior parte dei framework enterprise Java perché molte cose si basano su un thread per richiesta (transazioni, sicurezza, ecc ...).