何為PaaS

地球人都知道PaaS就是Platform as a Service的縮寫，但到底什么是PaaS呢?

假如我們現在需要一個業務，提供一個很簡單的"hello world"服務，那么需要的資源有哪些呢，看下圖：

　　IaaS&PaaS覆蓋圖

從最底層的IDC、機房、網絡、服務器，到服務器上的操作系統，操作系統上的服務軟件(主要包括WebServices、數據庫、緩存等)，當然最終在WebServices里運行的是我們的業務代碼。如果我們生活在互聯網的初始階段，那么這些元素都是需要我們關心的，我們不得不為帶寬機架跟運營商打交道，為域名備案跟通管局打交道，為服務器跟服務器供應商打交道，最后還得雇傭管理一個運維團隊，幫助維護自己的IT資源。這會使人瘋掉!

現在幸福的事情，IaaS(Infrastructure as a Service)，來了，IaaS幫我們節省了紅線所涉及的部分，包括IDC、網絡、服務器、甚至包括部分操作系統，為什么說部分操作系統呢?因為我們還是要關心操作系統掛掉、機器宕機等因素，如果我們不關心，或者說我們從業務的架構上不考慮這些因素，是很難保證業務穩定的。

而PaaS呢?PaaS幫我們節省了藍色涉及的部分，也就是說除了IaaS節省的部分外，還節省了服務軟件和代碼的部分，換句話說，PaaS提供了一個完整的業務開發、運行環境，我們無需關心怎么安裝Apache、怎么配置緩存、怎么配置數據庫讀寫分離，所有這些已經以服務的方式(注意：不是以機器的方式)提供好了，我們需要做的，只是把業務代碼放上來就好了。

總之，IaaS提供的還是虛擬機資源，而PaaS提供的是實際業務的開發、運行環境，正如SAE對自己的定位：“Web應用/業務的分布式開發、運行平臺”。

PaaS和IaaS的區別

剛才說了IaaS主要是虛擬機資源，而PaaS提供的是業務的開發、運行環境，那么PaaS和IaaS的區別就是這些嗎?

云計算追求的就是通過共享從而降低成本，并且利用技術提供更好的服務。我們來看一個生活中的例子：

我們去飯店吃飯，菜很好吃，但有一個事比較煩心：“到底點多少菜”，點的多了怕浪費，點的少了怕不夠吃，快吃完了再點又怕上菜慢，現在我們利用云計算的思路解決這個問題=》

IaaS的辦法：將菜“虛擬化”，將一份菜切分為半份菜、1/3份菜，甚至1/4菜，用戶可以點小份。

這種辦法很有效，可以有效降低我們吃飯的成本，但仍不是特別方便，A，我們無法準確預估需要點多少份;B，吃著吃著飯，突然來了一個朋友，又要現點份菜，這需要上菜時間，耽誤工夫。

那么怎么才能做的更好呢?人類吃飯的單位都是一口，沒有人能吃“半口飯”，能不能按照口供應呢?我們來看：

PaaS的辦法：通過一種技術，將菜按口供應，每個顧客只要張嘴就可以吃菜，不張嘴就不吃了，停止計費，來了一個新朋友，也是通過同樣的方式，只要張嘴就有菜吃。

IaaS&PaaS解決問題對比

從這張圖可以看出，PaaS對比IaaS虛擬化的粒度更細，更貼近用戶的實際需要，因為用戶真正需要的并不是虛擬機，而是滿足業務運行需求。下面我們來仔細討論一下PaaS和IaaS的區別吧：

PaaS的計費粒度更細

從計費粒度上，PaaS比IaaS更細，IaaS普遍以 虛擬機的實例數*運行時間 計費，即使IaaS標榜他們的計費單元可以精確到秒級，但如果用戶業務某個時間段沒有任何請求，用戶仍然需要為這部分虛擬機使用時間付費，因為用戶無法預知下一次請求什么時候到來，所以用戶無法關閉所有虛擬機。

而PaaS是以請求消耗的資源為單元計費的。

這樣，如果用戶的業務暫時沒有任何請求，則用戶無需支付任何費用，做到了真正的“所付即所用”。

從SAE上用戶的實際使用情況來看，幾乎所有用戶對比之前的使用IaaS時都會有不同程度的成本節約，以某創業為例，日均15萬PV，

PaaS比IaaS更可靠

IaaS用戶容易高估自己的服務可靠性，這里面有兩個原因：

- IaaS服務廠商往往夸大自己的服務可靠性，實際從目前看任何一個IaaS廠商都時不時有重大故障報出來

- IaaS用戶迷信廠商提供的SLA，自己不進行高可靠架構部署

我見過在IaaS只用2臺虛擬機，然后標榜自己的服務可靠性有多高的用戶，殊不知當物理機宕機時，虛擬機一定會收到影響，目前IaaS服務商能提供熱遷移的只是少數，即使能提供也是需要提前準備的，無法做到故障時實時切換

PaaS隱藏了服務器、虛擬機的概念，把一切功能服務化，而這些服務都是基于高可靠架構的，以SAE提供的Cron定時服務為例，這套Cron服務是基于分布式環境，任何一臺機器宕機都不會影響定時任務的準確觸發。

PaaS是真正的“高可擴展”

要明白這個問題，我們先來看什么叫“可擴展”，可擴展有兩個層面：

1，用戶可以自行擴展資源，通過手工的方式(包括頁面點擊、API調用等)

2，隨著用戶的業務擴張，自動擴展

幾乎所有的IaaS廠商都可以實現層面1，但層面1的問題是，用戶不知道什么時候擴展。用戶真正需要的是層面2的擴展，即隨著業務增長，資源自動擴展，整個過程用戶可以完全不感知，目前這種層面的“高可擴展”沒有任何一家IaaS廠商提供。

而SAE恰恰提供這種層面2的高可擴展，SAE會自動判斷用戶的業務是否存在等待隊列，一旦請求出現等待，將自動將請求分配新的計算節點，通過這種機制，用戶從PV 100/天漲到PV 1億/天，可以做到瞬間實現而無需用戶做任何操作。

PaaS是免運維的云計算

“免運維”是PaaS的最大魅力，因為用戶把代碼放上來，就可以完全不管了，無論業務凋零還是業務暴漲，都無需人工干預，當然SAE提供完整的圖表展現用戶的各種請求曲線，了解業務情況還是必須的。在SAE上的很多用戶團隊里都是0運維，也就是一個運維人員都沒有，這在傳統業務團隊中是不可想象的。

PaaS的缺點

雖然PaaS有免運維、高可靠、自動擴展、更加節約成本等優點，但是PaaS也有缺點，PaaS的最大缺點就是因為用戶無法看見服務器，感受不到虛擬機，這樣限制了用戶的自主性和靈活性，比如用戶想部署一個自己的C程序，或者用戶想直接開一個FTP管理文件，這些需求都無法在PaaS中滿足，因為PaaS 提供的是一個業務的開發、運行環境，而不是用戶能夠登陸的云主機。

那么既然PaaS有優點也有缺點，那么什么情況適合使用PaaS呢?

PaaS的適用場景

其實，PaaS和IaaS各有各的適用場景，主要由以下一些規律：

非HTTP業務(如游戲服務端、數據分析服務)適合用IaaS，HTTP業務(網站、RESTfulAPI服務端)適合用PaaS;

大型團隊(擁有豐富的系統、網絡、運維能力和經驗)適合用IaaS，創業團隊/小型團隊(團隊規模小，全部聚焦在業務)適合用PaaS;

技術團隊(喜歡定制化、喜歡掌控一切)適合用IaaS，產品團隊(聚焦在產品開發)適合用PaaS;

資金充裕(能夠雇傭昂貴的系統工程師、能夠支付沒有流量的虛機費用)的團隊適合用IaaS，資金緊張(對成本比較care的用戶)的適合用PaaS;

PaaS是真正的云計算平臺

總之，在桌面時代，我們需要的不是IBM ThinkPad、甚至不是Windows，而是上面成千上萬的應用、游戲;到了云時代，我們需要的既不是幾core的虛擬機、也不是什么EBS存儲，而是一個能讓我們的業務穩定可靠省心運行的環境，如果有這樣的環境，除了技術Geek，我想沒有人想管服務器。。。

PaaS盡管有種種問題，但它確實是從誕生就想提供給用戶一個省心、穩定的業務運行環境，用戶一旦部署，不需要關心擴容，不需要關心架構，不需要關心宕機，不需要關心配置，不需要關心優化，就可以隨著業務的發展時時滿足各種需要，所以PaaS是真正的云計算平臺。