6

我在 Zookeeper 之上构建了一个服务发现层，用于在分布式环境中查找 Thrift 服务。我现在正在寻找在生产环境中运行这些服务的最佳方式。

目前，它是通过打包部署到 Tomcat 的战争来完成的。在 servlet 实例化期间，会创建 Spring ApplicationContext，这会创建TThreadPoolServerTomcat 内部。

我不喜欢这个有几个原因：

  • 它使 Tomcat 有点无用，感觉就像是一种便于部署的 hack
  • 它避免了 Tomcat 线程池和所有用于找出分发请求的最佳方式的逻辑

在试图找到处理这个问题的最佳策略的过程中，我想出了几个替代方案：

  • 将 thrift 服务作为独立的 JAR 启动（我不喜欢这样，主要是因为我现在需要重新发明应用程序容器开发人员花费大量时间制定的逻辑
  • 通过 HTTP 进行主机节俭，从而利用 Tomcat 线程池和服务请求逻辑（关于这一点的不确定性，因为这将导致性能下降 - 尽管很小 - 性能损失）
  • 使用不同类型的应用程序容器来托管这些服务

有没有人对他们以前如何处理托管分布式服务器有任何建议。我最好在 Tomcat 中使用 HTTP 吗？

4

1 回答 1

6

我尝试使用 Tomcat 作为 Thrift 服务器的主机，发现它并没有带来任何额外的价值：在这种情况下，servlet 容器的所有功能（请求路由等）都不是必需的。另一方面，Tomcat 增加了复杂性和移动部件（即，它带来了难以解决的 PermGen 问题）。

在 HTTP 上使用 Thrift 会导致显着的性能影响，尤其是在具有大量客户端连接的高负载场景中。

所以我最终得到了在 Supervisor Daemon ( http://supervisord.org/ ) 下运行的独立 Thrift 服务。它使分布式部署的管理非常方便。当需要通过 HTTP 公开 Thrift API 时（例如，对于 JS 客户端），我们使用在 vert.x ( http://vertx.io/ ) 中实现的瘦异步代理。

于 2013-07-15T10:10:34.050 回答