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