在部署Rails API ONLY应用程序时是否有必要使用Nginx？

Question

目前我已经阅读了许多关于Rails App部署的教程，几乎每个人都使用Nginx或Apache之类的其他替代方案来提供静态页面。同样在这个质量保证Why do we need nginx with thin on production setup?中他们说Nginx用于负载平衡。

我可以理解上面提到的原因，但我将Rails应用程序编写为纯API后端服务，唯一的目的是为其他客户端应用程序提供JSON格式的数据，根本不提供任何页面呈现。所以我的问题是：

1. 在我的情况下，我是否真的需要Nginx来部署纯API Rails应用程序？
2. 如果没有，我该如何部署我的应用？只是在后台运行它（在生产环境中使用独角兽）就够了吗？比如rails server -e production -d？

我对这两个问题很好奇，希望有人可以解释一下细节，或者向我展示一些很好的参考资料，提前谢谢。

Answer 1

基本上看，Unicorn或thin都是单线程服务器。这在某种程度上意味着他们使用延迟和其他技术一次处理单个请求。

对于生产设置，您通常会运行许多unicorn或thin的实例（取决于您的负载等），您需要对这些rails应用程序服务器实例进行负载平衡，这就是为什么您需要Nginx或类似的东西在顶部。

Answer 2

  

为其他客户端应用程序提供JSON格式的数据，而不提供任何页面呈现

你看，它没有任何区别。这些任务类似：将某些数据格式化为特定的基于文本的结构。就像在HAML，ERB或其他任何地方渲染视图一样。

不同之处在于，您不会为静态资产提供服务。至少，它对纯JSON API不实用。

如果您的目标是紧凑型JSON响应，那么最好的选择是 Unicorn（多个工作人员）+ nginx 。

Unicorn 更简单，旨在实现快速的单客户端响应。也就是说，一个缓慢的客户可能会迫使 Unicorn 浪费大量时间为他提供响应。但是，当由 nginx 支持时，它会将整个响应触发到nginx的缓冲区，然后前往下一个只等待 nginx 接受响应（因为它＆＃ 39; s通常在同一台机器上，它的速度非常快。 nginx 然后发出回复。可能有多个 Unicorn 实例，如果还不够：但只使用一个可以消除应用级别上的任何类型的数据争用（这在多线程应用程序中是可能的）。

精简本身就是通过使用线程和工作程序来自行处理多个客户端。请记住，虽然MRI（＆＃34;经典＆＃34; Ruby）没有＆＃34;真正的并发线程＆＃34;因为GIL。基于（Ruby + C）的技术在资源使用效率方面使其不如 nginx （纯C）。 nginx 有时甚至用于抵御DDoS攻击，效率在野外证明（<1> <2> <3>等等。

如果您的应用程序暗示多个客户端的并发服务（如服务器发送事件或WebSocket使用）需要维护持续连接，则可以从精简中受益。这个似乎并不适合。在不需要的情况下，不要过多依赖并发性。