PAAS平台7×24小時可用性應用設計

標籤：

如今非常多企業都在搭建自己的私人PAAS平台，當然也有非常多大型互連網公司搭建共同擁有PAAS平台（比如SAE/BAE/JAE(jae.jd.com)）。那麼使用PAAS平台來部署SAAS應用有哪些優點呢？除了大家都知道方便部署管理，節約資源和成本，今天我主要給大家介紹還有一個優點就是讓部署在PAAS平台上的應用非常easy做到7×24小時不server執行（哪怕須要又一次部署和更新應用），這個對於一般的企業和普通開發人員來說是非常難辦到的。當然假設要在PAAS平台做到事實上也不是那麼簡單的。須要非常強的技術力量。以下就主要介紹一下在PAAS平台如何?讓部署在PAAS平台上的應用達到7×24小時執行的方案。

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

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

（1）應用執行調度模組：能夠將應用的多個執行個體調度到不同的server和機架上進行執行;

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

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

一，首先我們來看看調度模組

調度模組應該是PAAS平台（無論是私人還是共同擁有的）標配，僅僅是不同的PAAS平台有自己特色的調度方法和策略，比如依據server資源使用來調度（這個裡面有涉及到各種資源的調度。比如依據CPU或者記憶體等），或者依據部署的應用個數來調度。

當然好的調度策略絕對不僅僅使用一種評判標準來作為調度的策略，肯定是結合各種情況考慮。由於今天主要介紹的是應用的高可靠性，所以主要介紹如何通過調度演算法保證應用的高可靠性。

假如應用為了提高自己的服務能力和可靠性執行了3個執行個體。那麼怎麼的調度演算法是最佳的（僅僅針對高可靠性這一點來說的）？我們都知道設計一個高可靠性系統都會考慮到server出問題和網路（交換器）出問題。所以調度模組為了保證這個應用的高可靠性應該須要保證這三個執行個體應用不在同一個server上執行，同一時候保證三個執行個體不應該在同一個機架下執行，當然假設有條件的PAAS平台能夠考慮跨資料中心調度（只是應該沒有幾個PAAS平台能夠做到跨資料中心部署PAAS平台上的應用）。

要做到上面說的調度結果。調度模組應該能夠知道全部部署應用的server的部署情況，或者至少能夠通過某種方法查詢到。我相信全部的PAAS都應該有資源管理模組（或者叫做PAAS平台的server監控模組）能夠提供這些資訊。除了知道server的部署情況，調度模組應該還須要能夠知道或者查詢到某一個應用執行個體執行在哪一台server上，由於僅僅有這樣調度模組才幹夠保證不會把後面的執行個體調度到同一個server上。比如應用啟動三個執行個體，已經啟動2個執行個體了。還須要啟動第三個執行個體。那麼調度模組啟動第三個執行個體之前須要知道其它連個執行個體執行的server和機架，這樣才幹保證把第三個執行個體調度到其它機架上去執行。相同假設應用執行的三個執行個體，突然某個時候其中一個執行個體掛掉了，那麼須要把第三個執行個體又一次執行起來，還是須要使用調度模組來完畢不同server和不同機架的調度。至於調度模組怎麼知道掛掉了一個執行個體。這個不是調度模組關心的事情。以下介紹的應用執行狀態監控模組會非常好的解決問題。

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

打造7×24小時高可用的應用，假設連應用執行的狀態都不知道，還怎麼談做到7×24小時的執行。說的簡單一點，應用執行狀態的監控模組就是即時的監控應用各個執行個體的執行狀態（存活還是掛掉了）。然後依據監控的結果進行興許處理。

監控模組須要達到的結果非常簡單：就是應用的執行狀態和使用者期望的執行狀態是否一致。

比如使用者期望這個應用是執行的，可是此時執行狀態卻是掛掉的。肯定是不合理的，又比如使用者期望此時不想對外提供服務了，希望應用是停止執行的，可是假設應用還是在執行也是不合理的。再比如使用者期望應用眼下應該是須要執行三個執行個體的。可是僅僅有兩個執行個體執行，也是沒有滿足使用者需求的。

監控模組就是發現這些和使用者期望不一致的情況。並處理。

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

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

首先須要擷取每個應用的使用者期望狀態。那麼我們就須要單獨一個模組來擷取這些使用者的期望狀況。而且把這些狀態儲存在某一個地方（共用儲存，cloudfoundry使用的etcd）以便其它模組使用。

當然使用者期望的狀態通常存放在資料庫其中，這個使用者期望狀態的擷取模組能夠通過直接讀取資料庫或者通過其它服務模組得到。

這個模組相應cloudfoundry的hm9000中的fetch_desired模組。

使用者期望的執行狀態有了，那麼就還須要應用真實的執行狀態，那麼這個狀態怎麼來擷取了。這個模組就叫做應用真實狀態擷取模組，相同將擷取的資料存放到共用儲存上。有兩種方案能夠擷取。一種是主動去擷取全部應用的執行狀態，通常就是去訪問應用提供的一個服務。另外一種方案就是全部應用定時上報心跳，假設沒有即使上報就覺得應用執行狀態有問題了。

cloudfoundry採用的另外一種方案，只是它不是應用自己上報。而是管理一台server上全部應用的組件（dea）統一上報這台server全部應用的心跳。

這個模組相應cloudfoundry的hm9000中的listen模組。

使用者期望的狀態和應用真實狀態都有了，那麼我們就能夠開始分析了，究竟哪些應用的執行狀態和使用者期望的執行狀態不一致了。

然後將分析的結果相同存放在共用儲存上，後面其它模組會使用這個分析結果的資料。這個模組相應cloudfoundry的hm9000中的analyze模組。

我們都知道了哪些應用的狀態和使用者期望的狀態不一致。那麼我們就能夠把這些不一致的應用讓他們一直。這就須要一個模組專門來給調度模組發送調度命令。比如使用者期望應用是執行的，可是真實的狀態是這個應用掛掉了，那麼這個模組就能夠發送一個調度命令讓調度模組把這個應用啟動起來。相同假設使用者期望停止，假設應用是執行的那麼就發送調度命令讓這個應用停止掉。還有執行執行個體少了就在多調度一個起來。執行執行個體多了就停止掉多餘的執行個體。這個模組相應cloudfoundry的hm9000中的send模組。

通過上面的4個模組基本上完畢了應用執行狀態監控模組，而且維護了應用執行狀態不一致的應用。

當然cloudfoundry的hm9000還提供了其它工具模組，感興趣能夠自己去深入研究。

三。最後一個模組就是優雅重新啟動模組

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

事實上這個模組是最簡單的，可是達到的效果也是最明顯的。只是也正是PAAS平台的特性才easy完畢。由於PAAS平台的應用程式更新和執行是兩個分離的任務。我們全然能夠一邊更新應用一邊繼續讓應用提供服務。而且在新更新應用沒有全然能夠提供服務曾經一直讓老服務繼續提供服務。全然不影響應用對外提供的服務。

這個模組實現還須要通過調度模組來完畢。在應用程式更新期間，我們一直讓曾經執行的執行個體繼續執行。一直到更新的應用已經正常執行了，才停止掉老的執行執行個體。這些啟動或者停止動作都交給調度模組完畢，這個模組主要就是控制邏輯就能夠了。

上面介紹的模組有一個缺點就是在新應用啟動成功並對外提供服務以後去停止老執行個體的時候，使用者可能感受到不一致的服務狀態。由於在老執行個體還沒有全然停止掉曾經可能還有請求達到執行個體，可是又可能偶爾到新執行個體，由於新老執行個體可能同一時候存在一個非常小的時間段，只是這對大部分應用應該是能夠忽略的。

假設你全然不能忍受這短暫的不一致狀態，那麼還能夠在路由那一塊做。保證使用者請求到達要麼全部到老執行個體要麼全部到新執行個體，詳細做法就是新執行個體和老執行個體的路由地址不會同一時候存在路由程式的路由表裡面。

 

第四，總結

通過上面的三種模組的設計基本上能夠打造7×24小時的應用了。儘管方案設計完畢了，可是真正的實施了還會遇到非常多意料不到的情況，要正在打造7×24小時的應用執行環境還須要非常多其它方面的考慮。比方說每個模組執行的穩定性，假設應用執行狀態監控模組都掛掛了還怎麼啟動應用程式。所以，好項目還需要好的做法，通過對調整方案的做法。

著作權聲明：本文部落格原創文章。部落格，未經同意，不得轉載。

PAAS平台7×24小時可用性應用設計