I have built a service discovery layer on top of Zookeeper for finding Thrift services in a distributed environment. I'm looking for the best way to run those services in a production environment now.
Currently, it's done by packaging a war that gets deployed to Tomcat. During the servlet instantiation, the Spring ApplicationContext is created, which creates a TThreadPoolServer
inside of Tomcat.
I don't like this for a couple of reasons:
In the process of trying to find the best strategy to handle this, I have come up with a couple of alternatives:
Does anyone have suggestions on how they may have handled hosting distributed servers before. Am I better off just using HTTP inside of Tomcat?
I've tried using Tomcat as a host for Thrift server and found out that it doesn't bring any additional value: all the features of servlet container (request routing, etc) aren't necessary in this scenario. On the other hand, Tomcat adds complexity and moving parts (i.e., it brings hard to resolve PermGen issues).
Using Thrift over HTTP causes significant performance impact, especially in high-load scenarios with a lot of client connections.
So I ended up with standalone Thrift services running under Supervisor Daemon (http://supervisord.org/). It makes management of distributed deployment really convenient. When it's necessary to expose Thrift API over HTTP (for example, for JS clients), we use thin async proxy implemented in vert.x (http://vertx.io/).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With