《PaaS程式設計》一2.3 PaaS：綜合兩種方式的最佳方案

本節書摘來自華章出版社《paas程式設計》一書中的第2章，第2.3節，作者 lucas carlson，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視

對于開發者來說，通常會以共享主機的方式起步。很快，就會經曆需要更強的功能和控制的階段，于是，就會轉向獨立主機托管。在完全擁有了控制權之後，你可能會感到很惬意，也會很興奮，因為你可以對伺服器進行調整和優化，讓它們運作得更快，網站可以更快地的被加載，并且可以處理更多的使用者請求。

然後，随着時間的流逝，興奮感很快就會煙消雲散，因為日複一日維護伺服器所增加的負擔，會讓人筋疲力盡。獨立伺服器可以提供更強的功能和控制，但是很容易就會遭受攻擊，而作為開發者，你必須自己解決這些問題。在資料庫被破壞了的時候，還得自己去使用備份資料進行恢複。

而且，還有更多問題！而不僅僅是需要花費時間和精力來管理這些機器。如果伺服器在淩晨4點當機（通常會在這些非常不友善的時間發生），你必須完全負責去修複它。即使你在吃晚飯、在參加婚禮或者在度假，你也得去修複機器。這就是尋呼機存在的理由—為了找到醫生和系統管理者。

簡而言之，對于開發者來說，共享web主機很容易，但是無法提供足夠的控制和功能；而獨立主機雖然功能強大，但是也帶來了很多麻煩和不必要的負擔。在平台即服務出現之前，沒有任何折中的方案可以選擇。

于是，結合獨立主機托管的強大功能和共享主機的易用性，我們便得到了平台即服務。

讓我們簡單回顧一下這個例子，由于新增的電視節目，導緻網絡流量地爆發增長。采用專用伺服器托管時，就必須從1台伺服器增加到100台伺服器。這将是一個夢魇，因為我們可能需要雇傭一個團隊來管理這些伺服器。但是采用平台即服務的方案，則隻需要将滾動條從左邊移動到右邊，數秒鐘之内就可以将伺服器增加到100台。

就像我們所看到的那樣，平台即服務提供了專用主機所擁有的強大的能力、速度、可靠性以及可擴充性，同時也如同共享主機那樣簡單易用。是以，我們可以說，平台即服務是開發者的可擴充性和可靠性的聖杯。

同時這一增強的可靠性也帶來了另外一項好處，那就是作為可擴充架構的關鍵原則之一，應用于現代web開發領域的n層架構。

采用n層應用架構，我們就不需要将應用的邏輯與資料庫伺服器，或者緩存伺服器或者負載均衡伺服器放置在一起。因為，可以采用不同層次的伺服器來獨立地處理應用程式的不同的方面。

這樣就實作了垂直方向的擴充，進而可以通過增加更多某種類型的伺服器來增加運算能力， 這些伺服器并行運作，并通過軟體的配置實作負載的分發。于是，我們就從原來的單一伺服器，到現在擁有了至少三層或者四層的伺服器，或者層次。在每一層中，我們都得以複制失效恢複和高可用性。

而在采用專用伺服器的時候，通常需要東拼西湊才最終得以實作類似的架構。每一個平台即服務的方案都從開始就擁有内置的n個層次。這些層次被打包成産品，并在剛開始的時候就成為一種事實上的标準，将專用web主機與一種簡單的部署應用代碼政策組合成一種最佳方法。

有多種不同的方法來實作平台即服務。一些供應商專注于某種單一的程式設計語言，就是說，開發者被限制于應用特定的語言。比如java、php、python或者node.js。

也有些供應商提供多種不同的語言以供選擇。一方面來看，多語言供應商可以提供一站式服務的好處，而另外一個方面，單語言的平台即服務供應商則常常可以提供高度優化的系統環境。總的來說，應用最廣泛的paas系統通常都是多語言的。

作為開發者，大家還需要注意供應商鎖定問題。某些平台即服務供應商要求應用系統程式設計的時候，使用他們的應用程式設計接口（api），是以，一旦将代碼綁定到他們的api之後，就很難移植到其他的平台了。如果這隻是簡單的在資料庫服務的層面上，應用的代碼還可以保持不錯的可移植性。但是，如果使用了供應商定制的庫或者定制的應用程式設計接口，就很難将這些內建點切分成相對獨立的點，是以，難以将應用程式移植到其他paas平台。

幾乎所有的平台即服務供應商總會讓人免費嘗試。通常，我們可以至少免費地建立一些應用程式。對于開發者來說，這通常是非常有用的，因為可以通過嘗試熟悉平台即服務。在準備部署産品應用的時候，我們就會有很多不同的選擇，這些定價模型通常依據所選擇的不同平台有很大的不同。paas部署産品應用的價格可能從每月隻有20美元到每月上萬美元。

例如，采用某個業界領先的paas供應商的服務時，通常可以免費地部署應用。但是，當需要擴充應用，并增加更多執行個體的時候（讓應用進入産品準備階段），可能就得按照每個執行個體支付費用，每個執行個體大約每月30～40美元。如果還需要備份服務，就還需要每月增加30～40美元的費用。是以，對于某些平台即服務供應商來說，支付的成本可能随着應用的擴充而迅速增加。

其他的平台會采用不同的定價模型。有些按照實際使用的虛拟機數量收費，也有些按照某個資源消耗模型收費。采用appfog，開發者就擁有一定數量的ram，基于這些ram可以按照需要部署特定數量的應用，或者一定數量的執行個體以運作這些應用。按照每個月使用多少ram支付費用，而不是如何使用付費。docould也采用類似的模式。

這裡有好幾個問題。平台即服務是個新的概念嗎？或者它隻是基礎設施即服務的一種擴充？這一“偉大構想”是否是按需提供的伺服器加上api的概念組合？或者平台即服務是一個全新的，完全不同的思想？

有足夠的證據表明iaas和paas各不相同，而且平台即服務并不是基礎設施即服務的一個特性。歸根到底，問題是對于每種服務來說，什麼是重要的。

在iaas和paas背後的核心概念是什麼？換種方式說：什麼是它們的基礎單元？

基礎單元

一個基礎單元就是所研究實體的最小的不可分解的單元。什麼是最小的公共元素？什麼才是人們所關心的基礎的、不可分割的方面？數學上，就是數（或者更為基礎的集合）。實體上，就是方程。化學上，就是分子。而在生物學上，就是細胞。

這一概念也同樣适用于商業世界。對于麥當勞來說，就是漢堡。對于巴諾（barnes&nobel）書店，就是書。對于可口可樂，就是一聽可樂。這些就是一個公司最在乎的基礎單元。

搞清楚一個公司的基礎單元，既有一定的啟發意義，也有一定的限制性。啟發性在于它可以讓人更為專注，集中精力于所擅長的方面。而限制性在于很難銷售任何不在公司基礎單元之外的東西。很少有嘗試多個基礎單元的公司能夠成功。

基礎單元并不一定要如前面所述的那樣具體。例如，對于亞馬遜（amazon.com），其基礎單元就是任何可以被放置在倉庫中管理，并且可以被包裝在一個盒子中運輸的東西。對于netflix，就是多種形式的數字媒體。對于procter&gamble來說，就是居家用品。

在談到挑選基礎單元這個問題時，有很多令人困惑的地方。其中部分原因在于很多銷售着不同基礎單元的公司被組合到了一起。一種從根本上理清這個問題的途徑，就是從一般的層面上去了解每個公司的基礎單元。

iaas與paas的對比

對于基礎設施即服務，基礎單元就是資源。這裡的資源是指伺服器、磁盤、網絡以及ip位址。iaas所做的一切就是按照需要提供這些資源。例如，亞馬遜（amazon）的web服務，所有的工具都以資源為中心，所有的文檔都是關于資源的，所有的開發都是專注于資源，同時人們也因為需要這些資源而使用它。其他一些iaas的例子還包括rackspace、gogrid以及joyent。

對于平台即服務來說，基礎單元就是應用。那麼什麼是應用？就是一個系統。這就是代碼以及所有那些在任何時候都與這些代碼通訊的服務。這不僅僅是資源，事實上，一個應用是由很多單獨的資源綁定在一起組成的。将所有這些資源連接配接在一切所需要付出的工作量通常被低估了。這就是為什麼很多公司成立it部門，以及為什麼系統管理者總是非常受歡迎的原因。從一個單一地運作apache和mysql的伺服器轉移到一個擁有單獨的負載均衡伺服器、緩存伺服器、應用伺服器、資料庫伺服器以及備援的失效恢複的系統架構需要大量的工作，包括前期投入以及後期維護。

利用paas可以做的另外一件事情，就是從應用的角度來管理iaas。諸如cloud formation之類的工具是非常了不起的，但它們是通過資源的角度來管理iaas。從應用的角度來管理iaas與資源完全不同。

與資源不同，應用通常不會頻繁地上線下線。對于iaas來說，雖然按照實際需求每小時付費的定價模式非常有用，但通常沒有那麼重要，除非面對應用的爆發式增長或者在一個測試或開發場景中。

簡單地說，平台即服務供應商面對的是代碼和服務。這些供應商的職責就是管理和維護代碼、運作服務并且確定在任何時候，所有的一切能正常連接配接并正常工作。