現在很多企業都在搭建自己的私有PAAS平臺，當然也有很多大型網際網路公司搭建共有PAAS平臺（例如SAE/BAE/JAE(jae.jd.com)）。那麼使用PAAS平臺來部署SAAS應用有哪些好處呢？除了大家都知道方便部署管理，節約資源和成本，今天我主要給大家介紹另一個好處就是讓部署在PAAS平臺上的應用很容易做到7×24小時不伺服器執行（哪怕需要重新部署和更新應用），這個對於一般的企業和普通開發者來說是很難辦到的。當然如果要在PAAS平臺做到其實也不是那麼簡單的，需要很強的技術力量。下面就主要介紹一下在PAAS平臺怎樣實現讓部署在PAAS平臺上的應用達到7×24小時執行的方案。

在介紹方案設計之前需要強調一下，這個前提是PAAS平臺本身是7×24小時高可靠的。

本方案設計主要涉及下面幾方面的改進：

（1）應用執行排程模組：能夠將應用的多個例項排程到不同的伺服器和機架上進行執行;

（2）應用執行狀態的監控模組：對應用的執行狀況進行監控;

（3）優雅重啟應用模組：能夠在應用重新部署和升級時不停服務;

一，首先我們來看看排程模組

排程模組應該是PAAS平臺（不管是私有還是共有的）標配，只是不同的PAAS平臺有自己特色的排程方法和策略，例如根據伺服器資源使用來排程（這個裡面有涉及到各種資源的排程，例如根據CPU或者記憶體等），或者根據部署的應用個數來排程。當然好的排程策略絕對不只使用一種評判標準來作為排程的策略，肯定是結合各種情況考慮。因為今天主要介紹的是應用的高可靠性，所以主要介紹怎樣通過排程演算法保證應用的高可靠性。假如應用為了提高自己的服務能力和可靠性運行了3個例項，那麼怎麼的排程演算法是最佳的（僅僅針對高可靠性這一點來說的）？我們都知道設計一個高可靠性系統都會考慮到伺服器出問題和網路（交換機）出問題，所以排程模組為了保證這個應用的高可靠性應該需要保證這三個例項應用不在同一個伺服器上執行，同時保證三個例項不應該在同一個機架下執行，當然如果有條件的PAAS平臺可以考慮跨資料中心排程（不過應該沒有幾個PAAS平臺能夠做到跨資料中心部署PAAS平臺上的應用）。

要做到上面說的排程結果，排程模組應該能夠知道所有部署應用的伺服器的部署情況，或者至少能夠通過某種方法查詢到。我相信所有的PAAS都應該有資源管理模組（或者叫做PAAS平臺的伺服器監控模組）能夠提供這些資訊。除了知道伺服器的部署情況，排程模組應該還需要能夠知道或者查詢到某一個應用例項執行在哪一臺伺服器上，因為只有這樣排程模組才能夠保證不會把後面的例項排程到同一個伺服器上。例如應用啟動三個例項，已經啟動2個例項了，還需要啟動第三個例項，那麼排程模組啟動第三個例項之前需要知道其他連個例項執行的伺服器和機架，這樣才能保證把第三個例項排程到其他機架上去執行。同樣如果應用執行的三個例項，突然某個時候其中一個例項掛掉了，那麼需要把第三個例項重新執行起來，還是需要使用排程模組來完成不同伺服器和不同機架的排程。至於排程模組怎麼知道掛掉了一個例項，這個不是排程模組關心的事情，下面介紹的應用執行狀態監控模組會很好的解決這個問題。

二，應用執行狀態的監控模組

打造7×24小時高可用的應用，如果連應用執行的狀態都不知道，還怎麼談做到7×24小時的執行。說的簡單一點，應用執行狀態的監控模組就是實時的監控應用各個例項的執行狀態（存活還是掛掉了），然後根據監控的結果進行後續處理。監控模組需要達到的結果很簡單：就是應用的執行狀態和使用者期望的執行狀態是否一致。例如使用者期望這個應用是執行的，但是此時執行狀態卻是掛掉的，肯定是不合理的，又例如使用者期望此時不想對外提供服務了，希望應用是停止執行的，但是如果應用還是在執行也是不合理的，再例如使用者期望應用目前應該是需要執行三個例項的，但是隻有兩個例項執行，也是沒有滿足使用者需求的。監控模組就是發現這些和使用者期望不一致的情況，並處理。

那麼怎樣做？下面我就結合開源PAAS平臺cloudfoundry的解決方案來介紹應用執行狀況的監控模組的方案設計，cloudfoundry目前為止已經將原來的ruby版單程序單點監控模組改造成了go版高可靠多程序的監控模組。預知詳情請到官方網站查詢相關資料，今天主要結合最新版本的監控模組來介紹怎麼設計監控模組：

最新版本的cloudfoundry的應用執行狀態監控模組又劃分為很多的子模組，每一個子模組都可以執行一個主程序和多個備程序進行高可靠部署（這些程序可以部署在不同的伺服器和機架上，只要網路能夠通）。

首先需要獲取每一個應用的使用者期望狀態，那麼我們就需要單獨一個模組來獲取這些使用者的期望狀況，並且把這些狀態儲存在某一個地方（共享儲存，cloudfoundry使用的etcd）以便其他模組使用。當然使用者期望的狀態通常存放在資料庫當中，這個使用者期望狀態的獲取模組可以通過直接讀取資料庫或者通過其他服務模組得到。這個模組對應cloudfoundry的hm9000中的fetch_desired模組。

使用者期望的執行狀態有了，那麼就還需要應用真實的執行狀態，那麼這個狀態怎麼來獲取了，這個模組就叫做應用真實狀態獲取模組，同樣將獲取的資料存放到共享儲存上。有兩種方案可以獲取，一種是主動去獲取所有應用的執行狀態，通常就是去訪問應用提供的一個服務，第二種方案就是所有應用定時上報心跳，如果沒有即使上報就認為應用執行狀態有問題了。cloudfoundry採用的第二種方案，不過它不是應用自己上報，而是管理一臺伺服器上所有應用的元件（dea）統一上報這臺伺服器所有應用的心跳。這個模組對應cloudfoundry的hm9000中的listen模組。

使用者期望的狀態和應用真實狀態都有了，那麼我們就可以開始分析了，到底哪些應用的執行狀態和使用者期望的執行狀態不一致了。然後將分析的結果同樣存放在共享儲存上，後面其他模組會使用這個分析結果的資料。這個模組對應cloudfoundry的hm9000中的analyze模組。

我們都知道了哪些應用的狀態和使用者期望的狀態不一致，那麼我們就可以把這些不一致的應用讓他們一直，這就需要一個模組專門來給排程模組傳送排程命令。例如使用者期望應用是執行的，但是真實的狀態是這個應用掛掉了，那麼這個模組就可以傳送一個排程命令讓排程模組把這個應用啟動起來。同樣如果使用者期望停止，如果應用是執行的那麼就傳送排程命令讓這個應用停止掉。還有執行例項少了就在多排程一個起來，執行例項多了就停止掉多餘的例項。這個模組對應cloudfoundry的hm9000中的send模組。

通過上面的4個模組基本上完成了應用執行狀態監控模組，並且維護了應用執行狀態不一致的應用。當然cloudfoundry的hm9000還提供了其他工具模組，感興趣可以自己去深入研究。

三，最後一個模組就是優雅重啟模組

為什麼需要這一個模組呢？因為任何一個應用都不可能不更新，除非廢掉的應用。那麼更新這個應用的時間可大可小，那麼由於更新期間導致應用不可用時間也服務估計。當然更加達不到題目所說的打造7×24小時的高可用應用了。

其實這個模組是最簡單的，但是達到的效果也是最明顯的，不過也正是PAAS平臺的特性才容易完成。因為PAAS平臺的應用更新和執行是兩個分離的任務，我們完全可以一邊更新應用一邊繼續讓應用提供服務，並且在新更新應用沒有完全能夠提供服務以前一直讓老服務繼續提供服務，完全不影響應用對外提供的服務。

這個模組實現還需要通過排程模組來完成，在應用更新期間，我們一直讓以前執行的例項繼續執行，一直到更新的應用已經正常運行了，才停止掉老的執行例項。這些啟動或者停止動作都交給排程模組完成，這個模組主要就是控制邏輯就可以了。

上面介紹的模組有一個缺點就是在新應用啟動成功並對外提供服務以後去停止老例項的時候，使用者可能感受到不一致的服務狀態。因為在老例項還沒有完全停止掉以前可能還有請求達到例項，但是又可能偶爾到新例項，因為新老例項可能同時存在一個很小的時間段，不過這對大部分應用應該是可以忽略的。

如果你完全不能忍受這短暫的不一致狀態，那麼還可以在路由那一塊做，保證使用者請求到達要麼全部到老例項要麼全部到新例項，具體做法就是新例項和老例項的路由地址不會同時存在路由程式的路由表裡面。

第四，總結

通過上面的三種模組的設計基本上能夠打造7×24小時的應用了，雖然方案設計完成了，但是真正的實施了還會遇到很多意料不到的情況，要正在打造7×24小時的應用執行環境還需要很多其他方面的考慮，比如說每一個模組執行的穩定性，如果應用執行狀態監控模組都掛掉了還怎麼啟動掛掉的應用。所以好的方案還需要好的實踐，通過實踐調整方案。