感覺「雲」

      今天由於要升級系統，因此在升級以前的這段時間寫寫關於雲計算的東西。

      時下很是流行的一個概念，就是「雲計算了」，儼然一副大勢所趨的樣子。到了只要是作IDC的就必定要作個雲產品出來。霎時間，千雲萬雲在空中向咱們飄來，真的，看上去很美。

      美，確定是顯而易見的。可是，咱們真的要作好準備，不然再好看的雲也極有可能在瞬間變成烏雲一朵，甚至雷電交加。搞很差讓你的服務瞬間傾覆。

      很不巧，做爲全球雲計算領導者amazon的用戶，我已經經受了兩次AWS的事故。只是時間和地點的不一樣。4月27日，amazon向咱們證實了雲其實和咱們平常的服務器同樣，也會出問題，並非堅如盤石的。那麼剛剛此次，甚至尚未完全解決問題，讓咱們認識到，雲不但不是堅如盤石的，並且一旦發起彪來，形成的惡劣影響範圍之大，程度之深是通常物理服務器所不能匹敵的！

      「雲」到底適合什麼樣的需求或者應用？真的很難說，估計一百我的就有一百種答案。可是咱們能夠反過來想想，有沒有不適合的？

      經過AWS的使用來看：

      若是強化單個服務器有超強的計算或者IO能力，」雲「不適合。

      其實雲仍是強調」夠用就好「的原則。這樣纔可以有效的利用物理的計算能力和IO能力。說到底，雲到最後體現的是一個服務的存在而不是一臺或是幾臺物理服務器。就像咱們要運行一個tomcat服務，不論是那種雲，哪家的產品，不管用什麼表現形式。反正就讓你把代碼部署上去，tomcat開始服務，好一點你還能夠配置一個IP搞個DNS指向。而後服務上線，別的你就不用管了。而這個tomcat提供的服務最終變成了這個雲的一個存在的服務。不用管到底在哪一個服務器，那個IDC，那個國家。

     」你見，或者不見它，它就在那裏，不來不去「

       沒有多個節點高可用設計和實現的，當心某天從雲中直接跌落。

       經過AWS出的這幾回問題，咱們不難發現，一旦底層承載」雲「計算平臺的各個層面出現問題或者故障，將會影響整個在該平臺的全部服務。固然雲服務提供商須要儘量的避免出現這樣的問題，可是一旦出現對於運行其上的公司打擊仍是很大的。畢竟雲計算平臺要有足夠規模以後，才能經過更高的使用率甚至是某些複用達到高使用率、高計算能力和其服務提供商追求的商業目標（說白了就是多掙錢）。因此在軟件設計之初就要儘可能知足或者擁有云的一些特點。固然，有些大規模的並行計算估計能夠不須要，反正某個或者幾個節點異常，甚至所有節點失效都沒有關係。它要的只是計算出結果而已，大不了重算，沒有7×24小時服務在線的要求。而除去這樣的需求，對於雲上運行的服務軟件的設計和最終的部署須要思考的東西還不少。例如：這次amazon在歐洲區出現的這個問題，若是能夠將實例分別部署在該區的3個zone中，能夠避免服務中止的故障。可是在設計之初沒有考慮多節點服務提供，部署之初考慮成本付出（帶寬等費用），則會直接形成該問題出現區域部署的服務直接全面中止。

      若是有可能，應儘可能早的和雲服務提供商進行較多的溝通，通常來說他們都會有專門的架構師來對咱們的設計和部署提供技術幫助的。

       最後，補充說下關於構建私有云的問題。

        如今有的雲服務提供商，象買硬件服務器或者作項目同樣協助某些用戶構建本身的私有云。其好處能夠說是成車列舉。可是須要注意的一點，雲平臺構建技術比較複雜（其複雜程度確定遠遠大於直接管理硬件服務器），尤爲一旦出現問題須要技術過硬的團隊進行處理和解決。其成本並不必定小於咱們的購買物理服務器和租用IDC的成本。而且，一旦出現故障搞很差全線業務中止，而傳統的物理服務器則只是會由於某幾臺出現問題而形成單一業務的中止，且修復速度會比較快（若是所有服務器都中止工做，基本上只有多是地震或者你圖便宜找了一個不入流的IDC提供商）。真的別讓雲搞花了本身的眼睛。

      雲確定是好東西，可是做爲技術而言，它確定也會有不足，也會有問題。重要的就是咱們該如何去適應它，最後到如何善用它。