nginx - 在生产环境中提供 Go Webapps

Question

在静态内容、灵 active 和安全性方面，处理生产环境中的 Go 网络应用程序服务的最佳方式是什么？

我应该从像 nginx 这样的完全缓冲的反向代理后面为 Go 服务吗？如果是这样，我应该让 nginx 处理静态内容吗？

我是否应该使用 ServeMux 和 FileServer 从 Go 应用程序提供静态内容，就像这里建议的那样 Serve homepage and static content from root ？

我的生产应用是否需要使用 NaCL 或 AppArmor 等沙盒？

Answer 1

您的问题很好地概述了您的权衡。不过，我不能肯定地告诉您应该选择哪个，因为这会根据您的应用程序而有很大差异，但这里有一些关于每个应用程序的要点。

安全

您提出了两点关于安全性的问题:

1. nginx 背后的反向代理
2. 沙盒

如果您正在运行一个敏感的应用程序(财务数据等)，终止与 nginx(或 apache)的 SSL 连接对您来说将是一件大事，因为它们将使用 OpenSSL，OpenSSL 已经过众多安全专家。 Go 加密库非常好，由在该领域备受尊敬的人编写，但尚未受到同样的审查。

我无法告诉您什么最适合您的应用程序，但我还没有看到很多关于沙盒化本土 Go 应用程序在生产中使用它们的讨论。一个与此相关的令人兴奋的新项目是 docker.io ，它甚至可以在您的 Go 应用程序之外为您提供多个级别的沙箱。在我看来，只要你跟踪 Go 的最新版本并且避免做不安全的事情(比如导入“不安全”和使用 cgo)，使用 NaCl 或 AppArmor 可能会比它值得的麻烦更多。也就是说，如果您正在做类似 Go Playground 的事情，几乎肯定需要对 不受信任 的 Go 程序进行沙盒处理。 .

静态内容

你真的可以随心所欲地做到这一点。我会选择对你来说最简单的那个。 Go 应用程序可以轻松地同时提供自己的静态内容和动态内容，所以我认为将其分离出来通常是一种过早的优化，直到您的基准测试和监控告诉您它无法处理负载。

灵 active

我认为很难对将所有内容保存在一个二进制文件中的灵 active 提出异议。这使得部署非常容易，它减少了您需要做的配置和监控等工作。现在的静态文件以后可以是动态的；如果事实证明您需要内存缓存或共享内存缓存，则可以将其添加到那里。通常很难确切地知道您以后需要什么，因此在制作原型(prototype)和部署的初始阶段保持尽可能多的灵 active 可能会带来巨大的好处。

这里的奖励也可以追溯到前面的两个问题，如果您的应用程序/网站变得非常成功，您可能最终会在 CDN 后面提供服务(例如 CloudFlare ，它恰好使用 Go 来处理一些关键部分他们的基础设施)将同时处理静态内容的缓存和 SSL 连接的终止。这可能是保持事情简单并最大限度地减少前期工程成本的理由，因为您可以在以后需要时使用现有解决方案。