在生产中服务 Go Webapps

Question

在静态内容、灵活性和安全性方面，处理在生产中提供 Go 网络应用程序的最佳方法是什么？

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

我应该使用 aServeMux和FileServer像这里建议的那样从 Go 应用程序提供静态内容从根提供主页和静态内容吗？

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

Answer 1

您的问题很好地概述了您的权衡。不过，我不能肯定地告诉您应该选择哪个，因为这会因您的应用程序而有很大差异，但这里有一些关于每个的要点。安全您提出了关于安全性的两点：nginx 背后的反向代理沙盒如果您正在运行敏感应用程序（财务数据等），终止与 nginx（或 apache）的 SSL 连接对您来说将是一件大事，因为他们将使用 OpenSSL，它已经过许多安全专家的审查和审查. Go 加密库非常好，由在该领域备受尊敬的人创作，但尚未受到同样的审查。我不能告诉你什么最适合你的应用程序，但我没有看到很多关于在生产环境中使用沙盒本地开发的 Go 应用程序的讨论。与此相关的一个令人兴奋的新项目是docker.io，它甚至可以在 Go 应用程序之外为您提供多个级别的沙箱。在我看来，只要你跟踪 Go 的最新版本并且避免做不安全的事情（比如导入“不安全”和使用 cgo），使用 NaCl 或 AppArmor 可能会比它的价值更麻烦。也就是说，如果您正在执行Go Playground 之类的操作，几乎肯定需要对不受信任的Go 程序进行沙箱处理。静态内容你真的可以随心所欲地做到这一点。我会选择对你来说最容易的那个。Go 应用程序可以轻松地为它们自己的静态内容和动态内容提供服务，所以我想说，在您的基准测试和监控告诉您它无法处理负载之前，将其分离出来通常是过早的优化。灵活性我认为很难与将所有内容保存在一个二进制文件中的灵活性争论不休。这使得部署非常容易，它减少了你需要做的配置和监控等。现在是静态文件，以后可以是动态的；如果事实证明您需要内存缓存或共享内存缓存，则可以将其添加到那里。通常很难确切地知道未来需要什么，因此在原型设计和部署的初始阶段保持尽可能多的灵活性可能会带来巨大的好处。作为奖励，也可以追溯到之前的两个问题，如果您的应用程序/网站变得非常成功，您可能最终会在 CDN（例如CloudFlare，它碰巧将 Go 用于其基础架构的某些关键部分）之后提供服务，这将两者都处理静态内容的缓存和 SSL 连接的终止。这可以成为保持简单和最小化前期工程成本的论据，因为您可以在以后需要时使用现有的解决方案。