雲計算的前世此生（上）

做者簡介：劉超，網易雲解決方案首席架構師。10年雲計算領域研發及架構經驗，Open DC/OS貢獻者。長期專一於kubernetes, OpenStack、Hadoop、Docker、Lucene、Mesos等開源軟件的企業級應用及產品化。曾出版《Lucene應用開發揭祕》。

如下爲正文：

雲計算概述

雲計算主要解決了四個方面的內容：計算，網絡，存儲，應用。

計算就是CPU和內存，例如「1+1」這個最簡單的算法就是把「1」放在內存裏面，而後CPU作加法，返回的結果「2」又保存在內存裏面。網絡就是你插根網線能上網。存儲就是你下個電影有地方放。本次討論就是圍繞這四個部分來說的。其中，計算、網絡、存儲三個是IaaS層面，應用是PaaS層面。

雲計算髮展脈絡

雲計算整個發展過程，用一句話來形容，就是「分久必合，合久必分」。

第一階段：合，即物理設備

物理設備簡介

在互聯網發展初期，你們都愛用物理設備：

1. 服務器用物理機，像戴爾、惠普、IBM、聯想等物理服務器，隨着硬件設備的進步，物理服務器愈來愈強大了，64核128G內存都算是普通配置；
2. 網絡用的是硬件交換機和路由器，例如思科的，華爲的，從1GE到10GE，如今有40GE和100GE，帶寬愈來愈牛；
3. 存儲方面有的用普通的磁盤，也有更快的SSD盤。容量從M，到G，連筆記本電腦都能配置到T，更況且磁盤陣列；

物理設備的缺點

部署應用直接使用物理機，看起來很爽，有種土豪的感受，卻有大大的缺點：

1. 人工運維。若是你在一臺服務器上安裝軟件，把系統安裝壞了，怎麼辦？只有重裝。當你想配置一下交換機的參數，須要串口連上去進行配置；當你想增長一塊磁盤，要買一塊插進服務器，這些都須要人工來，並且很大可能要求機房。大家公司在北五環，機房在南六環，這酸爽。
2. 浪費資源。其實你只想部署一個小小的網站，卻要用128G的內存。混着部署吧，就有隔離性的問題。
3. 隔離性差。你把好多的應用部署在同一臺物理機上，他們之間搶內存、搶cpu，一個寫滿了硬盤，另外一個就無法用了，一個弄掛了內核，另外一個也跟著掛了，若是部署兩個相同的應用，端口還會衝突，動不動就會出錯。

第二階段：分，即虛擬化

虛擬化簡介

由於物理設備的以上缺點，就有了第一次「合久必分」的過程，叫作虛擬化。所謂虛擬化，就是把實的變成虛的：

1. 物理機變爲虛擬機。cpu是虛擬的，內存是虛擬的，內核是虛擬的，硬盤是虛擬的；
2. 物理交換機變爲虛擬交換機。網卡是虛擬的，交換機是虛擬的，帶寬也是虛擬的；
3. 物理存儲變成虛擬存儲。多塊硬盤虛擬成一大塊；

虛擬化解決的問題

虛擬化很好地解決了在物理設備階段存在的三個問題：

1. 人工運維。虛擬機的建立和刪除均可以遠程操做，虛擬機被玩壞了，刪了再建一個分鐘級別的。虛擬網絡的配置也能夠遠程操做，建立網卡、分配帶寬都是調用接口就能搞定的；
2. 資源浪費。虛擬化了之後，資源能夠分配地很小很小，好比1個cpu，1G內存，1M帶寬，1G硬盤，均可以被虛擬出來；
3. 隔離性差。每一個虛擬機都有獨立的cpu、 內存、硬盤、網卡，不一樣虛擬機之間的應用互不干擾；

虛擬化時代的生態

在虛擬化階段，領跑者是Vmware，能夠實現基本的計算、網絡、存儲的虛擬化。
如同這個世界有閉源就有開源、有windows就有linux、有Apple就有Android同樣，有Vmware，就有Xen和KVM。

在開源虛擬化方面，Xen 的Citrix作的不錯，後來Redhat在KVM發力很多；對於網絡虛擬化，有Openvswitch，能夠經過命令建立網橋、網卡、設置VLAN、設置帶寬；對於存儲虛擬化，本地盤有LVM，能夠將多個硬盤變成一大塊盤，而後在裏面切出一小塊給用戶。

虛擬化的缺點

可是虛擬化也有缺點。經過虛擬化軟件建立虛擬機，須要人工指定放在哪臺機器上、硬盤放在哪一個存儲設備上，網絡的VLAN ID、帶寬的具體配置等，都須要人工指定。因此僅使用虛擬化的運維工程師每每有一個Excel表格，記錄有多少臺物理機，每臺機器部署了哪些虛擬機。受此限制，通常虛擬化的集羣數目都不是特別大。

第三階段：合，即雲計算

雲計算解決的問題

爲了解決虛擬化階段遺留的問題，因而有了分久必合的過程。這個過程咱們能夠形象地稱爲池化。
虛擬化將資源分得很細，可是如此細分的資源靠Excel去管理，成本過高。池化就是將資源打成一個大的池，當須要資源的時候，幫助用戶自動地選擇，而非用戶指定。這個階段的關鍵點：調度器Scheduler。

私有云、公有云的兩極分化

這樣，Vmware有了本身的Vcloud；也有了基於Xen和KVM的私有云平臺CloudStack（後來Citrix將其收購後開源）。

當這些私有云平臺在用戶的數據中內心賣得奇貴無比、賺得盆滿鉢盈的時候，有其餘的公司開始了另外的選擇。這就是AWS和Google，他們開始了公有云領域的探索。

AWS最初就是基於Xen技術進行虛擬化的，而且最終造成了公有云平臺。也許AWS最初只是不想讓本身的電商領域的利潤所有交給私有云廠商吧，因此本身的雲平臺首先支撐起了本身的業務。在這個過程當中，AWS嚴肅地使用了本身的雲計算平臺，使得公有云平臺並非對資源的配置更加友好，而是對應用的部署更加友好，最終大放異彩。

私有云廠商與公有云廠商的聯繫與區別

若是仔細觀察就會發現，私有云和公有云雖然使用的是相似的技術，但在產品設計上倒是徹底不一樣的兩種生物。

私有云廠商和公有云廠商也擁有相似的技術，但在產品運營上呈現出徹底不一樣的基因。

私有云廠商是賣資源的，因此每每在賣私有云平臺的時候伴隨着賣計算、網絡、存儲設備。在產品設計上，私有云廠商每每會對客戶強調其幾乎不會使用的計算、網絡、存儲的技術參數，由於這些參數能夠在和友商對標的過程當中佔盡優點。私有云的廠商幾乎沒有本身的大規模應用，因此私有云廠商的平臺作出來是給別人用的，本身不會大規模使用，因此產品每每圍繞資源展開，而不會對應用的部署友好。

公有云的廠商每每都是有本身大規模的應用須要部署，因此其產品的設計能夠將常見的應用部署須要的模塊做爲組件提供出來，用戶能夠像拼積木同樣，拼接一個適用於本身應用的架構。公有云廠商沒必要關心各類技術參數的PK，沒必要關心是否開源，是否兼容各類虛擬化平臺，是否兼容各類服務器設備、網絡設備、存儲設備。你管我用什麼，客戶部署應用方便就好。

公有云生態及老二的逆襲

公有云的第一名AWS活的天然很爽，做爲第二名Rackspace就不那麼舒坦了。

沒錯，互聯網行業基本上就是一家獨大，那第二名如何逆襲呢？開源是很好的辦法，讓整個行業一塊兒爲這個雲平臺出力。因而Rackspace與美國航空航天局（NASA）合做創始了開源雲平臺OpenStack。

OpenStack如今發展的和AWS有點像了，因此從OpenStack的模塊組成能夠看到雲計算池化的方法。

OpenStack的組件

1. 計算池化模塊Nova：OpenStack的計算虛擬化主要使用KVM，然而到底在哪一個物理機上開虛擬機呢，這要靠nova-scheduler；
2. 網絡池化模塊Neutron：OpenStack的網絡虛擬化主要使用Openvswitch，然而對於每個Openvswitch的虛擬網絡、虛擬網卡、VLAN、帶寬的配置，不須要登陸到集羣上配置，Neutron能夠經過SDN的方式進行配置；
3. 存儲池化模塊Cinder: OpenStack的存儲虛擬化，若是使用本地盤，則基於LVM，使用哪一個LVM上分配的盤，也是經過scheduler來的。後來就有了將多臺機器的硬盤打成一個池的方式Ceph，而調度的過程，則在Ceph層完成。

OpenStack帶來私有云市場的紅海

有了OpenStack，全部的私有云廠商都瘋了，原來VMware在私有云市場賺的實在太多了，眼巴巴的看着，沒有對應的平臺能夠和他抗衡。如今有了現成的框架，再加上本身的硬件設備，幾乎全部的IT廠商巨頭，所有都加入到社區裏，將OpenStack開發爲本身的產品，連同硬件設備一塊兒，殺入私有云市場。

公有or私有？網易雲的選擇

網易雲固然也沒有錯過此次風口，上線了本身的OpenStack集羣，網易雲基於OpenStack自主研發了IaaS服務，在計算虛擬化方面，經過裁剪KVM鏡像，優化虛擬機啓動流程等改進，實現了虛擬機的秒級別啓動。在網絡虛擬化方面，經過SDN和Openvswitch技術，實現了虛擬機之間的高性能互訪。在存儲虛擬化方面，經過優化Ceph存儲，實現高性能雲盤。

可是網易雲並無殺進私有云市場，而是使用OpenStack支撐起了本身的應用，這是互聯網的思惟。而僅僅是資源層面彈性是不夠的，還須要開發出對應用部署友好的組件。例如數據庫，負載均衡，緩存等，這些都是應用部署必不可少的，也是網易雲在大規模應用實踐中，千錘百煉過的。這些組件稱爲PaaS。

第四階段：分，即容器

如今來談談，應用層面，即PaaS層。

前面一直在講IaaS層的故事，也即基礎設施即服務，基本上在談計算、網絡、存儲的事情。如今應該說說應用層，即PaaS層的事情了。

1. PaaS的定義與做用

IaaS的定義比較清楚，PaaS的定義就沒那麼清楚了。有人把數據庫、負載均衡、緩存做爲PaaS服務；有人把大數據Hadoop,、Spark平臺做爲PaaS服務；還有人將應用的安裝與管理，例如Puppet、 Chef,、Ansible做爲PaaS服務。

其實PaaS主要用於管理應用層。我總結爲兩部分：一部分是你本身的應用應當自動部署，好比Puppet、Chef、Ansible、 Cloud Foundry等，能夠經過腳本幫你部署；另外一部分是你以爲複雜的通用應用不用部署，好比數據庫、緩存、大數據平臺，能夠在雲平臺上一點即得。

要麼就是自動部署，要麼就是不用部署，總的來講就是應用層你也少操心，就是PaaS的做用。固然最好仍是都不用去部署，一鍵可得，因此公有云平臺將通用的服務都作成了PaaS平臺。另外一些你本身開發的應用，除了你本身其餘人不會知道，因此你能夠用工具變成自動部署。

2. PaaS的優勢

PaaS最大的優勢，就是能夠實現應用層的彈性伸縮。好比在雙十一期間，10個節點要變成100個節點，若是使用物理設備，再買90臺機器確定來不及，僅僅有IaaS實現資源的彈性是不夠的，再建立90臺虛擬機，也是空的，仍是須要運維人員一臺一臺地部署。因此有了PaaS就行了，一臺虛擬機啓動後，立刻運行自動部署腳本，進行應用的安裝，90臺機器自動安裝好了應用，纔是真正的彈性伸縮。

3. PaaS部署的問題

固然這種部署方式也有一個問題，就是不管Puppet、 Chef、Ansible把安裝腳本抽象的再好，說到底也是基於腳本的，然而應用所在的環境千差萬別。文件路徑的差異，文件權限的差異，依賴包的差異，應用環境的差異，Tomcat、 PHP、 Apache等軟件版本的差異，JDK、Python等版本的差異，是否安裝了一些系統軟件，是否佔用了哪些端口，均可能形成腳本執行的不成功。因此看起來是一旦腳本寫好，就可以快速複製了，可是環境稍有改變，就須要把腳本進行新一輪的修改、測試、聯調。例如在數據中心寫好的腳本移到AWS上就不必定直接能用，在AWS上聯調好了，遷移到Google Cloud上也可能會再出問題。

容器的誕生

1. 容器的定義

因而容器便應運而生。容器是Container，Container另外一個意思是集裝箱，其實容器的思想就是要變成軟件交付的集裝箱。集裝箱的特色，一是打包，二是標準。設想沒有集裝箱的時代，若是將貨物從A運到B，中間要通過三個碼頭，換三次船的話，貨物每次都要卸下船來，擺的七零八落，而後換船的時候，須要從新擺放整齊，在沒有集裝箱的時候，船員們都須要在岸上待幾天再走。而在有了集裝箱後，全部的貨物都打包在一塊兒了，而且集裝箱的尺寸所有一致，因此每次換船的時候，總體一個箱子搬過去就能夠了，小時級別就能完成，船員不再用長時間上岸等待了。

2.容器在開發中的應用

設想A就是程序員，B就是用戶，貨物就是代碼及運行環境，中間的三個碼頭分別是開發，測試，上線。
假設代碼的運行環境以下：

1. Ubuntu操做系統
2. 建立用戶hadoop
3. 下載解壓JDK 1.7在某個目錄下
4. 將這個目錄加入JAVA_HOME和PATH的環境變量裏面
5. 將環境變量的export放在hadoop用戶的home目錄下的.bashrc文件中
6. 下載並解壓tomcat 7
7. 將war放到tomcat的webapp路徑下面
8. 修改tomcat的啓動參數，將Java的Heap Size設爲1024M

看，一個簡單的Java網站，就須要考慮這麼多零零散散的東西，若是不打包，就須要在開發，測試，生產的每一個環境上查看，保證環境的一致，甚至要將這些環境從新搭建一遍，就像每次將貨物打散了重裝同樣麻煩。中間稍有差池，好比開發環境用了JDK 1.8，而線上是JDK 1.7；好比開發環境用了root用戶，線上須要使用hadoop用戶，均可能致使程序的運行失敗。

第五階段，未完，待續~~欲知容器如何對應用打包，且聽下回分解。