Service Deployment and Maintenance

Question

I created a service discovery layer on top of Zookeeper to search for Thrift services in a distributed environment. I am looking for the best way to run these services in a production environment.

This is currently being done by packing the war that will be deployed to Tomcat. During servlet creation, the Spring ApplicationContext constructor is created, which creates the TThreadPoolServer inside Tomcat.

I do not like this for two reasons:

• This makes Tomcat useless, and it seems like a hack to facilitate deployment.
• He avoids the Tomcat thread pool and all the logic that went into finding the best way to distribute requests.

In the process of finding the best strategy to solve this problem, I came up with a couple of alternatives:

• Launching assistance services as a standalone JAR (I don't like this, mainly because now I need to rethink the logic that application container developers spent a lot of time developing
• Taking action on HTTP, thus using the Tomcat thread pool and logic for service requests (if this happens because it could lead to minor performance changes)
• Use a different type of application container to host these services.

Does anyone have any suggestions on how they could handle distributed servers before. Am I better off just using HTTP inside Tomcat?

Answer 1

I tried using Tomcat as the host for the Thrift server and found that it does not bring any additional value: all the functions of the servlet container (request routing, etc.) are not needed in this scenario. Tomcat, on the other hand, adds complexity and moving parts (i.e. makes it difficult to solve PermGen problems).

Using Thrift over HTTP has a significant performance impact, especially in high-load scenarios with a large number of client connections.

So, I got offline Thrift services running Supervisor Daemon ( http://supervisord.org/ ). This makes distributed deployment management very convenient. When it is necessary to open the Thrift API via HTTP (for example, for JS clients), we use the async thin proxy server implemented in vert.x ( http://vertx.io/ ).