云計算的整個過程，用一個詞來講就是“分久必合，合久必分”。

云計算其實主要解決了四個方面的內容：計算，網絡，存儲，應用。前三者是資源層面的，最后是應用層面的。

計算是CPU和內存，為啥？1+1這個最簡單的算法是把1放在內存里面，運行加法是CPU做的，做完了結果2又保存在內存里面。
網絡就是你插根網線能上網。
存儲就是你下個電影有地方放。本次討論就是圍繞這四個部分來講的。

在原始社會，大家最愛用的是物理設備：

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

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

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

于是有了第一次合久必分的過程，叫做虛擬化。所謂虛擬化，就是把實的變成虛的。

物理機變為虛擬機：cpu是虛擬的，內存是虛擬的，內核是虛擬的，硬盤是虛擬的。
物理交換機變為虛擬交換機：網卡是虛擬的，交換機是虛擬的，帶寬也是虛擬的。
物理存儲變成虛擬存儲：多塊硬盤虛擬成一大塊。

虛擬化很好的解決了上面的三個問題：

人工運維：虛擬機的創建和刪除都可以遠程操作，虛擬機被玩壞了，刪了再建一個分鐘級別的。虛擬網絡的配置也可以遠程操作，創建網卡，分配帶寬都是調用接口就能搞定的。
浪費資源：虛擬化了以后，資源可以分配的很小很小，比如1個cpu，1G內存，1M帶寬，1G硬盤，都可以被虛擬出來。
隔離性差：每個虛擬機有獨立的cpu, 內存，硬盤，網卡，不同虛擬機的應用互不干擾。

但是虛擬化還有以下的缺點，通過虛擬化軟件創建虛擬機，需要人工指定放在哪臺機器上，硬盤放在哪個存儲設備上，網絡的VLAN ID，帶寬具體的配置，都需要人工指定。所以單單使用虛擬化的運維工程師往往有一個Excel表格，有多少臺機器，每臺機器部署了哪些虛擬機。所以，一般虛擬化的集群數目都不是特別的大。

在虛擬化階段，領跑者是Vmware，可以實現基本的計算，網絡，存儲的虛擬化。

當然這個世界有閉源，就有開源，有windows就有linux，有apple就有andord，有Vmware，就有Xen和KVM。在開源虛擬化方面，Xen方面Citrix做的不錯，后來Redhat在KVM發力不少。

對于網絡虛擬化，有Openvswitch，可以通過命令創建網橋，網卡，設置VLAN，設置帶寬。

對于存儲虛擬化，對于本地盤，有LVM，可以將多個硬盤變成一大塊盤，然后在里面切出一小塊給用戶。

為了解決虛擬化階段剩余的問題，于是有了分久必合的過程。這個過程我們可以形象的稱為池化，也就是說虛擬化已經將資源分的很細了，但是對于如此細粒度的資源靠Excel去管理，成本太高，能不能打成一個大的池，當需要資源的時候，幫助用戶自動的選擇，而非用戶指定。所以這個階段的關鍵點：調度器Scheduler。

于是vmware有了自己的vcloud。

于是基于Xen和KVM的私有云平臺CloudStack，后來Citrix將其收購后開源。

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

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

如果我們仔細觀察就會發現，私有云和公有云使用的是類似的技術，卻在產品設計上是完全不同的兩種生物。私有云廠商和公有云廠商也擁有類似的技術，卻在產品運營上呈現出完全不同的基因。

私有云廠商都是賣資源的，所以往往在賣私有云平臺的時候伴隨著賣計算，網絡，存儲設備。在產品設計上，私有云廠商往往強調又長又詳盡，但是客戶幾乎不會使用的計算，網絡，存儲的技術參數，因為這些參數可以用來和友商對標的過程中占盡優勢。私有云的廠商幾乎沒有自己的大規模應用，所以私有云廠商的平臺做出來是給別人用的，自己不會大規模使用，于是產品往往圍繞資源展開，而不會對應用的部署友好。

公有云的廠商往往都是有自己的大規模應用需要部署的，所以其產品的設計，可以將常見的應用部署所需要的模塊作為組件提供出來，用戶可以像拼積木一樣，拼接一個適用于自己應用的架構。公有云廠商不必要關心各種技術參數的PK，不必關心是否開源，是否兼容各種虛擬化平臺，兼容各種服務器設備，網絡設備，存儲設備。你管我用什么，客戶部署應用方便就好。

當然公有云的第一名AWS活的很爽，第二名Rackspace就不太爽了，沒錯，互聯網行業嘛，基本上就是一家獨大。第二名如何逆襲呢？開源是很好的辦法，讓整個行業大家一起為這個云平臺出力，兄弟們，大家一起上。于是Rackspace與美國航空航天局（NASA）合作創始了開源云平臺OpenStack。OpenStack現在發展的和AWS有點像了，所以從OpenStack的模塊組成，可以看到云計算池化的方法。

OpenStack包含哪些組件呢？

計算池化模塊Nova：OpenStack的計算虛擬化主要使用KVM，然而到底在哪個物理機上開虛擬機呢，這要靠nova-scheduler。
網絡池化模塊Neutron：OpenStack的網絡虛擬化主要使用Openvswitch，然而對于每一個Openvswitch的虛擬網絡，虛擬網卡，VLAN，帶寬的配置，不需要登錄到集群上配置，Neutron可以通過SDN的方式進行配置。
存儲池化模塊Cinder：OpenStack的存儲虛擬化，如果使用本地盤，則基于LVM，使用哪個LVM上分配的盤，也是用過scheduler來的。后來就有了將多臺機器的硬盤打成一個池的方式Ceph，而調度的過程，則在Ceph層完成。
有了OpenStack，所有的私有云廠商都瘋了，原來VMware在私有云市場實在賺的太多了，眼巴巴的看著，沒有對應的平臺可以和他抗衡。現在有了現成的框架，再加上自己的硬件設備，你可以想象到的所有的IT廠商的巨頭，全部加入到社區里面來，將OpenStack開發為自己的產品，連同硬件設備一起，殺入私有云市場。

網易當然也沒有錯過這次風口，上線了自己的OpenStack集群，網易蜂巢基于OpenStack自主研發了IaaS服務，在計算虛擬化方面，通過裁剪KVM鏡像，優化虛擬機啟動流程等改進，實現了虛擬機的秒級別啟動。在網絡虛擬化方面，通過SDN和Openvswitch技術，實現了虛擬機之間的高性能互訪。在存儲虛擬化方面，通過優化Ceph存儲，實現高性能云盤。

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

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

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

其實PaaS主要用于管理應用層的，我總結兩部分：一部分是你自己的應用應當自動部署，比如Puppet, Chef, Ansible, Cloud Foundry等，可以通過腳本幫你部署，一部分是你覺得復雜的通用應用不用部署，比如數據庫，緩存，大數據平臺，可以在云平臺上一點即得。

要么就是自動部署，要么不用部署，總的來說就是應用層您也少操心，就是PaaS的作用。當然最好是都不用部署，一鍵可得，所以公有云平臺將通用的服務都做成了PaaS平臺。另一些應用，是您自己開發的，除了你自己，其他人都不知道，所以您可以用工具變成自動部署。

有了PaaS最大的優點，就是可以實現應用層的彈性伸縮。比如雙十一來了，10個節點要變成100個節點，如果使用物理設備，再買90臺機器固然來不及，僅僅只有IaaS實現資源的彈性是不夠的，再創建90臺虛擬機，也是空的啊，還是需要運維人員一臺一臺的部署。所以有了PaaS就好了，一臺虛擬機啟動后，馬上運行自動部署腳本，進行應用的安裝，90臺機器自動安裝好了應用，才是真正的彈性伸縮。

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

于是容器應運而生。容器是Container，Container另一個意思是集裝箱，其實容器的思想就是要變成軟件交付的集裝箱。集裝箱的特點，一是打包，二是標準。設想沒有集裝箱的時代，如果從A將貨物運到B，中間要經過三個碼頭，換三次船的話，每次貨物都要卸下船來，擺的七零八落，然后再換船的時候，需要重新整齊擺好，所以沒有集裝箱的時候，船員們都得在岸上待幾天再走。然而有了集裝箱，所有的貨物都打包在一起了，并且集裝箱的尺寸全部一致，所以每次換船的時候，整體一個箱子搬過去就可以了，小時級別就能完成，船員再也不能上岸長時間休息了。所以設想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用戶，都可能導致程序的運行失敗。

容器如何對應用打包呢？還是要學習集裝箱，首先要有個封閉的環境，將貨物封裝起來，讓貨物之間互不干擾，互相隔離，這樣裝貨卸貨才方便。好在ubuntu中的lxc技術早就能做到這一點，這里主要使用了兩種技術，一種是看起來是隔離的技術，稱為namespace，也即每個namespace中的應用看到的是不同的IP地址，用戶空間，進程號等。另一種是用起來是隔離的，稱為cgroup，也即明明整臺機器有很多的CPU，內存，而一個應用只能用其中的一部分。

有了這兩項技術，集裝箱的鐵盒子我們是焊好了，接下來是決定往里面放什么的時候了。最簡單粗暴的方法，就是將上面列表中所有的都放到集裝箱里面。但是這樣太大了，因為虛擬機的鏡像就是這樣的，動輒幾十G，即使你安裝一個干干靜靜的ubuntu操作系統，什么都不裝，就很大了。這其實相當于把船也放到了集裝箱里面，答案當然是NO.

所以撇下第一項操作系統，剩下的所有加起來，也就幾百M，就輕便多了。所以一臺服務器上的容器是共享操作系統內核的，容器在不同機器之間的遷移不帶內核，這也是很多人聲稱容器是輕量級的虛擬機的原因。輕不白輕，自然隔離性就差了，一個集裝箱把船壓漏水了，所有的集裝箱一起沉。

另一個需要撇下的就是隨著應用的運行而產生并保存在本地的數據，多以文件的形式存在，例如數據庫文件，文本文件。這些文件會隨著應用的運行，越來越大，如果這些數據也放在容器里面，會讓容器變得很大，影響容器在不同環境的遷移。而且這些數據在開發，測試，線上環境之間的遷移是沒有意義的，生產環境不可能用測試環境的文件，所以往往這些數據也是保存在容器外面的存儲設備上。也是為什么人們稱容器是無狀態的。

至此集裝箱焊好了，貨物也裝進去了，接下來就是如何將這個集裝箱標準化，從而在哪艘船上都能運輸。這里的標準一個是鏡像，一個是容器的運行環境。所謂的鏡像，就是將你焊好集裝箱的那個時刻，將集裝箱的狀態保存下來，就像孫悟空說定，集裝箱里面就定在了那一刻，然后將這一刻的狀態保存成一系列文件。這些文件的格式是標準的，誰看到這些文件，都能還原當時定住的那個時刻。將鏡像還原成運行時的過程，就是讀取鏡像文件，還原那個時刻的過程，也就是容器的運行的過程。除了大名鼎鼎的Docker，還有其他的容器，例如AppC，Mesos Container，都能運行容器鏡像。所以說容器并不等于Docker。

總而言之，容器是輕量級的，隔離差的，適用于無狀態的，基于鏡像標準實現跨主機，跨環境的隨意遷移。

有了容器，使得PaaS層對于用戶自身應用的自動部署變得快速而優雅。容器快，快在了兩方面，第一是虛擬機啟動的時候要先啟動操作系統，容器不用啟動操作系統，因為是共享內核的。第二是虛擬機啟動后使用腳本安裝應用，容器不用安裝應用，因為已經打包在鏡像里面了。所以最終虛擬機的啟動是分鐘級別，而容器的啟動是秒級。容器咋這么神奇。其實一點都不神奇，第一是偷懶少干活了，第二是提前把活干好了。

因為容器的啟動快，人們往往不會創建一個個小的虛擬機來運行剛剛部署的應用，因為這樣太費時間了，而是創建一個大的虛擬機，然后在大的虛擬機里面再劃分容器，而不同的用戶不共享大的虛擬機，可以實現操作系統內核的隔離。

這又是一次合久必分的過程。由IaaS層的虛擬機池，劃分為更細粒度的容器池。

容器的粒度更加細，管理起來更難管，甚至是手動操作難以應對的。假設你有100臺物理機，其實規模不是太大，用Excel人工管理是沒問題的，但是一臺上面開10臺虛擬機，虛擬機的個數就是1000臺，人工管理就很困難了，但是一臺虛擬機里面開10個容器，就是10000個容器，你是不是已經徹底放棄人工運維的想法了。

所以容器層面的管理平臺是一個新的挑戰，關鍵字就是自動化：

自發現：容器與容器之間的相互配置還能像虛擬機一樣，記住IP地址，然后互相配置嗎？這么多容器，你怎么記得住。一旦一臺虛擬機掛了重啟，IP改變，應該改哪些配置，列表長度至少萬行級別的啊。所以容器之間的配置通過名稱來的，無論容器跑到哪臺機器上，名稱不變，就能訪問到。
自修復：容器掛了，或是進程宕機了，能像虛擬機那樣，登陸上去查看一下進程狀態，如果不正常重啟一下么？你得登陸萬臺docker了。所以容器的進程掛了，容器就自動掛掉了，然后自動重啟。
彈性自伸縮 Auto Scaling：當容器的性能不足的時候，需要手動伸縮，手動部署么？當然也要自動來。

如果有了容器的管理平臺，又是一次分久必合。

當前火熱的容器管理平臺有三大流派：

一個是Kubernetes，我們稱為段譽型。段譽(Kubernetes)的父親(Borg)武功高強，出身皇族(Google)，管理過偌大的一個大理國(Borg是Google數據中心的容器管理平臺)。作為大理段式后裔，段譽的武功基因良好(Kubernetes的理念設計比較完善)，周圍的高手云集，習武環境也好(Kubernetes生態活躍，熱度高)，雖然剛剛出道的段譽武功不及其父親，但是只要跟著周圍的高手不斷切磋，武功即可以飛速提升。
一個是Mesos，我們稱為喬峰型。喬峰(Mesos)的主要功夫降龍十八掌(Mesos的調度功能)獨步武林，為其他幫派所無。而且喬峰也管理過人數眾多的丐幫(Mesos管理過Tweeter的容器集群)。后來喬峰從丐幫出來，在江湖中特例獨行(Mesos的創始人成立了公司Mesosphere)。喬峰的優勢在于，喬峰的降龍十八掌(Mesos)就是在丐幫中使用的降龍十八掌，相比與段譽初學其父的武功來說，要成熟很多。但是缺點是，降龍十八掌只掌握在少數的幾個丐幫幫主手中(Mesos社區還是以Mesosphere為主導)，其他丐幫兄弟只能遠遠崇拜喬峰，而無法相互切磋(社區熱度不足)。
一個是Swarm，我們稱為慕容型。慕容家族(Swarm是Docker家族的集群管理軟件)的個人功夫是非常棒的(Docker可以稱為容器的事實標準)，但是看到段譽和喬峰能夠管理的組織規模越來越大，有一統江湖的趨勢，著實眼紅了，于是開始想創建自己的慕容鮮卑帝國(推出Swarm容器集群管理軟件)。但是個人功夫好，并不代表著組織能力強(Swarm的集群管理能力)，好在慕容家族可以借鑒段譽和喬峰的組織管理經驗，學習各家公司，以彼之道，還施彼身，使得慕容公子的組織能力(Swarm借鑒了很多前面的集群管理思想)也在逐漸的成熟中。

---------------------?
作者：popsuper1982?
來源：CSDN?
原文：https://blog.csdn.net/popsuper1982/article/details/53912607?
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！

總結

以上是生活随笔為你收集整理的史上最容易懂的云计算的前世今生的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。