在靜態內容、靈活性和安全性方面，處理在生產中提供 Go 網絡應用程序的最佳方法是什么？我應該從像 nginx 這樣的完全緩沖的反向代理后面提供 Go 嗎？如果是這樣，我應該讓 nginx 處理靜態內容嗎？我應該使用 aServeMux和FileServer像這里建議的那樣從 Go 應用程序提供靜態內容從根提供主頁和靜態內容嗎？我是否需要在生產中的應用程序中使用 NaCL 或 AppArmor 等沙盒？
1 回答
炎炎設計
TA貢獻1808條經驗 獲得超4個贊
您的問題很好地概述了您的權衡。不過，我不能肯定地告訴您應該選擇哪個，因為這會因您的應用程序而有很大差異，但這里有一些關于每個的要點。
安全
您提出了關于安全性的兩點：
nginx 背后的反向代理
沙盒
如果您正在運行敏感應用程序（財務數據等），終止與 nginx（或 apache）的 SSL 連接對您來說將是一件大事，因為他們將使用 OpenSSL，它已經過許多安全專家的審查和審查. Go 加密庫非常好，由在該領域備受尊敬的人創作，但尚未受到同樣的審查。
我不能告訴你什么最適合你的應用程序，但我沒有看到很多關于在生產環境中使用沙盒本地開發的 Go 應用程序的討論。與此相關的一個令人興奮的新項目是docker.io，它甚至可以在 Go 應用程序之外為您提供多個級別的沙箱。在我看來，只要你跟蹤 Go 的最新版本并且避免做不安全的事情（比如導入“不安全”和使用 cgo），使用 NaCl 或 AppArmor 可能會比它的價值更麻煩。也就是說，如果您正在執行Go Playground 之類的操作，幾乎肯定需要對不受信任的Go 程序進行沙箱處理。
靜態內容
你真的可以隨心所欲地做到這一點。我會選擇對你來說最容易的那個。Go 應用程序可以輕松地為它們自己的靜態內容和動態內容提供服務，所以我想說，在您的基準測試和監控告訴您它無法處理負載之前，將其分離出來通常是過早的優化。
靈活性
我認為很難與將所有內容保存在一個二進制文件中的靈活性爭論不休。這使得部署非常容易，它減少了你需要做的配置和監控等?，F在是靜態文件，以后可以是動態的；如果事實證明您需要內存緩存或共享內存緩存，則可以將其添加到那里。通常很難確切地知道未來需要什么，因此在原型設計和部署的初始階段保持盡可能多的靈活性可能會帶來巨大的好處。
作為獎勵，也可以追溯到之前的兩個問題，如果您的應用程序/網站變得非常成功，您可能最終會在 CDN（例如CloudFlare，它碰巧將 Go 用于其基礎架構的某些關鍵部分）之后提供服務，這將兩者都處理靜態內容的緩存和 SSL 連接的終止。這可以成為保持簡單和最小化前期工程成本的論據，因為您可以在以后需要時使用現有的解決方案。
- 1 回答
- 0 關注
- 190 瀏覽
添加回答
舉報
0/150
提交
取消