Distribuisci e fornisci un servizio di risparmio

Question

Ho costruito un livello di rilevamento servizi su Zookeeper per la ricerca di servizi di risparmio in un ambiente distribuito. Sto cercando il modo migliore per eseguire tali servizi in un ambiente di produzione ora.

Attualmente, viene eseguito mediante il confezionamento di una guerra che viene distribuita a Tomcat. Durante l'istanziazione servlet, viene creato Spring ApplicationContext, che crea un TThreadPoolServer all'interno di Tomcat.

Non mi piace questo per un paio di motivi:

• Si fa Tomcat sorta di inutile, e ci si sente come un hack per facilitare l'implementazione
• Si evita la messa in comune filo Tomcat e tutti della logica che è andato in capire il modo migliore per distribuire le richieste

Nel processo di cercare di trovare la migliore strategia per gestire questa situazione, sono venuto su con un paio di alternative:

• servizi di lancio di risparmio come un JAR standalone (che non mi piace questo, soprattutto perché ora ho bisogno di reinventare la logica che gli sviluppatori di app container hanno speso un sacco di tempo a lavorare fuori
• Host parsimonia su HTTP, utilizzando in tal modo la piscina Tomcat filo e la logica per le richieste di servizio (incerto circa questo a causa della - seppur minore - le prestazioni colpito questa verrà applicata)
• Utilizzare un diverso tipo di contenitore di applicazioni per ospitare questi servizi

qualcuno ha suggerimenti su come potrebbero aver gestito l'hosting di server distribuiti prima. Sto meglio usando solo HTTP all'interno di Tomcat?

Answer 1

Ho provato a utilizzare Tomcat come host per il server Thrift e ho scoperto che non porta alcun valore aggiuntivo: tutte le funzionalità del contenitore servlet (instradamento delle richieste, ecc.) Non sono necessarie in questo scenario. D'altra parte, Tomcat aggiunge complessità e parti in movimento (vale a dire, è difficile risolvere i problemi di PermGen).

Utilizzo di Thrift over HTTP provoca un impatto significativo sulle prestazioni, in particolare in scenari con carichi elevati con molte connessioni client.

Così ho finito con servizi Thrift standalone in esecuzione sotto Supervisor Daemon (http://supervisord.org/). Rende davvero conveniente la gestione della distribuzione distribuita. Quando è necessario esporre Thrift API su HTTP (ad esempio, per client JS), viene utilizzato un proxy asincrono sottile implementato in vert.x (http://vertx.io/).