在企業內部時常有服務啓停的需求,有時是由於在進行故障排除時須要對某些服務進行啓停;有時是由於這些服務在線時間長了容易發生異常,須要按期進行啓停;有時是由於須要進行更新包的投產發佈,須要進行服務的啓停。shell
無論怎樣,企業中的運維工做中離不開服務啓停,而每次進行服務啓停若是都要手工登錄目標服務進行操做的話,不但繁瑣低效,並且容易出現錯誤操做。服務器
在遠程鏈接的時候特別容易操做錯誤,好比經過遠程桌面或者是ssh鏈接,原本想要重啓A服務器上的服務,不當心把B服務器上的服務重啓了。因此,咱們能夠藉助自動化運維平臺,來開發一個用於批量、自動執行服務啓停的SaaS。框架
本文就對服務啓停SaaS的設計進行一些討論。下面咱們就分類進行討論要完成一個服務啓停動做要包含的要素。運維
要進行服務啓停,首先咱們要知道通常在企業內部對應用進行運維的過程當中,都須要對應用服務執行什麼操做。常見的操做有【啓動服務】、【中止服務】和【重啓服務】,另外還有若是按常規方法中止服務後,服務不響應請求時,須要一個【強制殺進程】的操做。ssh
在執行完上面的操做後,一般咱們還須要進行一下檢查這個操做是否成功。【啓動服務】後,咱們須要檢查服務是否啓動成功;【中止服務】後,咱們須要檢查服務是否中止成功等。spa
那麼咱們就要設計出針對這些動做的檢查動做了,通常的檢查動做有:.net
而對於檢查進程運行和端口偵聽,咱們能夠結合成一個動做,因此這裏須要設計兩個檢查動做:【端口檢測】和【應用狀態檢測】。設計
綜上所述,對於服務啓停來講,咱們能夠設計出以下幾個動做(固然,根據須要啓停的服務的特殊性,也能夠有針對性地設計不一樣的動做):對象
啓停的流程比較簡單,根據企業實際的運維場景去設計就行了,下面以兩種場景爲例:blog
1.因故障排除等緣由須要臨時性地進行服務啓停
2.週期性地進行服務啓停
其中提交申請和審批的動做是在外部完成,因爲是週期的執行,是有計劃的,因此一些企業須要要求進行工單申請,待審批後才能執行,而且是須要建立一個啓停任務來執行,以便於更好地進行任務管控和審計。
對於臨時性地進行服務啓停(如故障排查時),啓停模式比較簡單,只須要提供用戶主動執行的啓停按鈕便可,用戶在有須要的時候進行點擊執行,配合被動的檢查動做便可基本知足需求。
而對於計劃性地服務啓停,則有點不同,因爲是週期性或計劃性地啓停,必然不會只啓停單一的一個服務,一般是針對整個應用下的集羣的服務進行啓停,可能涉及十幾乃至幾十上百個節點上的服務的啓停,若是還只提供那幾個單純的啓停按鈕的話,那用戶可能會點鼠標點到手抽筋。因此咱們必須設計批量的方式,針對多個服務同時進行啓停。
另外還有考慮批量啓停的狀況下進行分批啓停,也就是第一批服務的啓停執行完後,緊接着執行第二批的啓停。由於通常在啓停整個集羣下的服務時,爲了避免讓應用出現中斷服務的狀況,須要先啓停其中一部分服務,啓停成功且正常提供服務後,再啓停剩餘部分。如圖示:
你設計的服務啓停能啓停哪些服務?這很重要,若是你針對Nginx啓停設計一套SaaS,那麼是否還要針對Weblogic的服務啓停再設計一套SaaS呢?Tomcat呢?啓停更多的服務呢?
因此,咱們須要考慮能儘可能知足多種服務的啓停的SaaS,可是每種服務的啓停方式不一致,其運行環境不一致,使用的命令也不一致,那怎麼辦呢?
額……把這個事情交給管理員去作吧,咱們提供一個通道入口就好了:咱們設計一個框架,支持管理員根據服務的實際啓停命令錄入相應的腳本或命令,咱們的SaaS來執行這些命令,以完成相應的啓停動做。
同時還要考慮目標對象對腳本的適應性,好比Windows上的服務支持使用bat腳本,Linux上的服務支持使用shell腳本等。
對於臨時性地啓停需求,管理員只需定位到相應的服務去執行啓停動做就能夠了,可是對於週期性、有計劃第執行批量啓停的時候,如何將這一批服務編排起來又是一個問題,難道我每次要啓停的時候,都須要一個一個服務去找到並進行編排嗎?那顯然是浪費時間和精力的。
在此咱們須要爲方便管理員針對固定的一批服務進行編排批量執行而進行設計,所以咱們能夠設計「模板」這個功能,把管理員須要常常啓停的比較固定的一批服務事先編排好放在哪裏,等到須要執行啓停的時候,直接把這個模板拿出來用就行了。
以上就服務啓停進行了簡單設計討論,通過如此設計後的服務啓停SaaS,應該比較能適用於通常企業對於服務啓停的需求了,供你們參考。
做者:何立
好文推薦