去年年底，netflix技術部落格上發表了這麼一篇文章，題為「轉向亞馬遜網路服務過程中學到的五個教訓」（5lessons we』ve learned using aws）。亞馬遜網路服務（amazon web services，以下簡稱aws）無疑是所謂的「雲計算」的傑出代表。因此，這篇文章實際上也可以看成是給任何想要轉向「雲」的**的關鍵性建議。當然，這些建議的確很棒！下面是一條最讓我震驚的：
譯者注：
netflix
***1997
年，總部位於加利福尼亞州的洛斯蓋圖。
1999
年開始訂閱服務。到
2009
年，該公司可提供多達
10萬部
***電影，並有
1000
萬的訂閱使用者。
我們時常把netflix在aws裡的軟體架構稱作為「藍博」。不管怎麼樣，哪怕不借助任何外力，每個系統都要有自我實現成功的能力。我們在設計每乙個分布式系統時，對我們所依賴的其他系統的容錯能力總是會充分考慮的。
譯者注：藍博（
rambo
）是電影《第一滴血》裡男主角的名字，他是乙個所向披靡的孤膽英雄的形象。
如果我們的推薦系統當機了，我們對客戶響應的質量肯定會下降，但我們仍然是有應必答的。雖然在這種情況下做不了個性化的推薦，但我們會把最流行的電影推薦給客戶。如果我們的搜尋系統突然慢得讓人無法忍受，但這絕對不會妨礙使用者以流**的方式**電影。
我們的工程師最早在aws裡建立的乙個系統其實是「混世魔猴」。這只猴子的工作就是搗蛋，它要隨機殺死我們系統架構裡的元件或服務。如果我們不持續檢驗我們在失敗面前自我恢復乃至成功的能力，那這個系統很有可能就是會在關鍵時刻掉鍊子。
猛一看，你肯定覺得這條建議太瘋狂！但我們必須面對它。我不確定會有多少公司認同這樣的做法，更別說有多少公司會真的去嘗試了。如果在你工作的地方，有人部署了乙個後台程式或服務，專門用於隨機殺死你的伺服器集群裡的服務或程序，請舉手！
如果這個人還沒被你的公司解雇，請舉起你的另外乙隻手！
但凡大腦正常的人，怎麼會願意去結交乙隻「混世魔猴」呢？
其實，有時候你沒的選擇；「混世魔猴」會自己找上門！stackexchange網路曾經碰到過乙個詭異的問題，我們也為此苦苦掙扎了幾個月。這個問題是：每隔幾天，oregon網路中心的某台伺服器總會突然對來自外部網路的任何請求停止響應。沒有原因；毫無道理；而且必須經過緩慢的關機、重啟之後才能恢復，期間還會讓伺服器出現藍屏現象……
我們花了幾個月——真正是幾個月的時間——去追蹤這個問題。我們還把可能的原因列了很長的乙個清單，一項一項去排除：
在整個事件過程中，我們的團隊成員是如此地受挫，以致於一度幾乎要打起來。（團隊成員都是遠端工作的，怎麼「打」？我們都用skype。***……）這能怪我們嗎？每隔幾天，我們的幾台伺服器中的一台會隨機地出現當機。「混世魔猴」老是來搗亂！
不過，即使在我們最受挫的時刻，我意識到我們還是做了一些積極的改變：
時間一天一天過去，我們每週都使我們的系統更加冗餘一點點，因為我們必須這麼做。儘管整個過程很痛苦，但事實擺在面前，實際上「混世魔猴」幫了我們乙個大忙，它迫使我們變得極具彈性。趕快行動起來吧！不要等明天，也不要指望將來更遠的某一天，更別說「以後再說吧」，立刻行動起來！
當你結交「混世魔猴」之後，你很快就會發現，每件事情發生的背後總是有原因的（除了那些完完全全隨機發生的事情）。「避免失敗最好的辦法就是不斷地失敗。」明白這句話的道理了吧，雖然它聽起來很瘋狂！
魔猴 stl3D檔案計算體積 面積 長寬高
前一陣子正好有個單子是做關於藝術品的3d檔案 與魔猴網有些許類似。因故自己倒騰了一下stl3d檔案的體積 面積 長寬高的計算方法。主要基於three.js，直接貼 function init group new three.mesh geometry,mat group.rotation.x 0.5...