在静态内容，灵活性和安全性方面，处理生产中Go Web应用程序的最佳方式是什么？
我应该从像nginx这样的完全缓冲的反向代理服务后面吗？如果是这样，我应该让nginx处理静态内容吗？
我应该使用ServeMux和FileServer提供来自Go应用的静态内容，例如Serve homepage and static content from root建议的内容吗？
我是否需要在生产中使用我的应用程序中的NaCL或AppArmor沙盒？
答案 0 :(得分：6)
你的问题很好地概括了你的权衡。我不能告诉你，你应该选择哪一个，因为根据你的申请，这会有很大差异，但每个都有一些要点。
你提出了两点安全问题：
如果您正在运行敏感应用程序（财务数据等），使用nginx（或apache）终止SSL连接对您来说将是一件大事，因为他们将使用OpenSSL，而OpenSSL已经过审核和审核众多安全专家。 Go加密库非常好，由在该领域备受推崇的人撰写，但尚未受到同样的审查。
我不能告诉你什么对你的应用程序有什么好处，但是在使用它们在生产中服务时，我还没有看到很多关于沙盒自制的Go应用程序的讨论。与此相关的一个令人兴奋的新项目是docker.io，它可以在Go应用程序之外的多个级别为您提供沙盒。在我看来，只要你跟踪Go的最新版本并且你避免做不安全的事情（比如导入“不安全”和使用cgo），使用NaCl或AppArmor可能会比它的价值更麻烦。也就是说，如果您正在执行Go Playground之类的操作，几乎肯定需要沙盒不受信任的 Go程序。
你可以随心所欲地做到这一点。我会选择最适合你的方式。 Go应用程序可以轻松地将自己的静态内容与动态内容一起提供，因此我认为将其分离出来通常是不成熟的优化，直到您的基准测试和监控告诉您它无法处理负载。
我认为很难与将所有内容保存在一个二进制文件中的灵活性争论。这使得它非常容易部署，它减少了您需要执行的配置和监视的数量等。现在，什么是静态文件可以是动态的;如果事实证明你需要内存缓存或共享内存缓存，你可以在那里添加它。通常很难确切地知道您将要采取什么措施，因此在进行原型设计和部署的初始阶段时尽可能保持灵活性可以带来巨大的好处。
作为奖励，这也可以追溯到两个早期的问题，如果您的应用程序/网站变得非常成功，您可能最终在CDN后面服务（如CloudFlare，这恰好使用Go来获取某些密钥它们的基础设施部分）将处理静态内容的缓存和SSL连接的终止。这可以成为保持简单和最小化前期工程成本的理由，因为如果需要，您可以在以后使用现有解决方案。