淘寶架構師談Java應用運維
編者按：本文作者BlueDavy是淘寶架構師，專注Java、OSGi模塊化等技術。
對于互聯(lián)網(wǎng)產品或長期運行的產品而言，運維工作非常重要，尤其是在產品復雜了以后，在這篇blog中就來說下Java應用的運維工作（ps：雖然看起來各種語言做的系統(tǒng)的運維工作都差不多，但細節(jié)上還是會有很多不同，so本文還是只講Java的）。
苦逼的碼農按照需求開發(fā)好了一個全新的Java Web應用，該發(fā)布上線給用戶用了，要把一個Java Web應用發(fā)布上線，首先需要搭建運行的環(huán)境，運行的環(huán)境需要有JDK、APPServer，在已經裝好了os的機器上裝上JDK和APPServer，開發(fā)好的Java Web應用可以用maven直接打成war或ear，將這個打好的包scp或其他方式到目標機器上，準備妥當，就差啟動了。
通常APPServer都帶有啟動腳本，在做好了上述準備后，直接運行啟動腳本，通常就OK了（maybe需要修改appserver的一些配置文件，例如修改監(jiān)聽端口等）。
應用啟動后，有一個問題需要解決，就是如何確認應用啟動后成功與否，對于Java web應用通常可以放一個jsp文件，在這個文件里做一些必要的檢查，以確保應用啟動是正常的，例如通常Java web應用會基于spring之類的框架來寫，為了確保spring的BeanFactory初始成功，可以在jsp文件里去獲取下spring里的bean調用下。
應用完成了啟動后，這個階段的工作就算完成了，這個階段完成后積累了一個應用啟動的腳本，用來啟動應用服務器以及在啟動完畢了后檢驗應用是否啟動成功。
只要不是一個一次性的應用，就必然會涉及修改的問題，修改完了后就得重新發(fā)布，對于Java Web應用，在修改完了后重新打應用的包，然后scp覆蓋到目標機器上，重啟，就可完成修改，但顯然，每次修改完代碼后都這么操作實在是痛苦不堪，于是喜歡“偷懶”的同學會專門搞臺發(fā)布用的機器（或者就是運行應用的那臺機器），然后寫個腳本，每次需要發(fā)布時就通過腳本自動的將發(fā)布需要做的所有事情自動做好，:)，這下以后發(fā)布爽多了。
相應的這個時候通常還要支持回滾，即應用發(fā)布失敗后自動的回滾到前一版本的功能，也可以折騰到腳本里。
但如果只是為了修改個頁面，就得這么折騰，顯然還是麻煩了點（主要是經常重啟，用戶受不了），于是需要支持僅更新頁面的發(fā)布方式，為了支持這種方式，通常就要求打出的war/ear是解開了的，這樣才比較方便直接覆蓋頁面，繼續(xù)“偷懶”的本性，寫些腳本，支持將需要發(fā)布的頁面文件從svn或git下載，然后打成一個tgz或其他壓縮包，scp到目標服務器，解包覆蓋完成頁面的更新（當然，對于編譯jsp的運行方式這種發(fā)布方法就沒法玩了）。
經過這個階段的折騰，就積累了兩個腳本，一個用來發(fā)布應用包，一個用來發(fā)布頁面。
每次發(fā)布應用包的時候都會有短暫的不可用，這樣總折騰下去用戶受不了（如果哪天這唯一的一臺服務器掛掉的話，就更糟糕了），于是就把應用的機器數(shù)從一臺變成兩臺，通常這里對應用是有些技術要求的，這篇blog中只談運維，通常情況下從部署在一臺變成兩臺后，要做這些事：
1、可能會增加一臺機器用來部署nginx/apache來做負載均衡，這個規(guī)模的情況下應該很少有會采用lb設備或lvs的（某些國企除外…），于是就得折騰下這臺機器的環(huán)境等了；
2、增加了一臺應用的機器后，就得又來搭建一次應用的運行環(huán)境了，通常這個時候“偷懶”的本性會發(fā)作，干脆折騰個腳本吧，來支持從另外一臺運行的應用機器clone運行環(huán)境，做的更好點的話，就會把應用的運行環(huán)境記錄在某個地方、然后把應用運行需要的軟件也放在某個地方（例如yum），這樣，當要搭建應用的運行環(huán)境時，就可通過記錄的信息以及yum源等直接完成運行環(huán)境的搭建。
3、但這樣還沒完，為了避免發(fā)布的時候應用完全不能用，除了技術上要做的那點事外，在發(fā)布應用時就會多加一步，就是要先發(fā)一臺，再發(fā)另外一臺，由于之前有發(fā)布腳本，通常這也不是問題，:)。
經過這個階段，就又積累了兩個腳本，一個用來管理負載均衡的那臺機器，另一個腳本用來搭建應用的運行環(huán)境。
隨著應用越來越受歡迎，通常應用的機器就得繼續(xù)加了，這個時候對運維工作又會帶來新的挑戰(zhàn)，主要還是在發(fā)布上，這個時候應用部署在了一堆的機器上了，每次發(fā)布的時候手工輸入一堆的機器地址來發(fā)布顯然很麻煩，于是需要有個地方來記錄應用有哪些機器（還記得我們之前搞了個地方來記錄應用的運行環(huán)境信息吧，可以放一起），除了要解決這個問題外，還需要解決的一個問題是這個時候通常對應用的發(fā)布方式會有了多種要求，例如分批發(fā)布（先發(fā)5臺，再發(fā)10臺，再全部發(fā)，或一半一半發(fā)等），更高級的話會有beta發(fā)布、灰度發(fā)布等要求，這個具體可以見facebook的大牛@魏小亮 寫的《代碼和產品發(fā)布的幾種方式》，這個時候顯然，之前寫的那個簡單的發(fā)布腳本就無法支持了，于是得搞個更為復雜的腳本來支持這多種的發(fā)布方式（有些還需要應用架構上做配合改造才能實現(xiàn)），做的更好的就是提供一個web版本的發(fā)布系統(tǒng)，來更為方便的進行發(fā)布以及發(fā)布過程的管理。
經過這個階段后，通常可以折騰出一個web版的應用運維系統(tǒng)了，包括應用信息的登記（依賴的運行環(huán)境、運行的機器地址）、應用的發(fā)布、頁面的發(fā)布、增加應用的機器、下線應用的機器。
通常繼續(xù)發(fā)展下去，會出現(xiàn)一些新的狀況，主要是會開始多元化，有了很多個應用，這個時候原來的web版應用運維系統(tǒng)就要支持多應用了，這里主要會帶來的問題是為了降低運維的復雜性，需要做一些通用性的工作，例如通用的啟動腳本等，這個時候會產生一些要求，例如統(tǒng)一的應用名等，另外會帶來的問題就是開發(fā)、運維的人多了，這個時候權限上就需要有些控制了，例如某些賬號可以操作某些應用等，這個時候通常需要增加一套權限系統(tǒng)，集成到之前的運維系統(tǒng)。
應用多了后，還會帶來的問題是應用部署的規(guī)范性（同時也是為了降低運維的復雜性），因為每個應用可能都會有一些特殊的配置，這個時候***是能夠通過搭建運行環(huán)境以及權限控制來保證一個應用部署后的目錄控制。
經過上面的一些發(fā)展過程后，Java應用的運維工作基本就可以比較自動的去完成了，但通常其實應用運維除了上面的工作外，還有一件更重要的事，就是保障應用的穩(wěn)定，應用運維人員需要能夠排查大部分的應用故障問題，而不是交由后面的開發(fā)人員來解決，通常這個時候需要一套自動的故障處理系統(tǒng)，感興趣的同學可以參與下facebook的FBAR。
發(fā)展到更大后，還可能會碰到例如一個負載設備無法支撐整個網(wǎng)絡的請求，需要劃分vlan，這個時候在做應用機器的擴容時就需要考慮vlan因素了，還有可能會碰到機器利用率不夠高，需要引入虛擬機，更高級的就是引入彈性計算，這些對運維體系都會產生較大的沖擊，:)。
從上面對一個Java應用運維的演變描述可以看到，大方向上來說是朝自動化、web化、智能化發(fā)展，但最最重要的都是如何和現(xiàn)有運行體系無縫的結合，而且這里談到的還僅僅是Java應用運維的工作（還沒提到開發(fā)人員其實也要仔細考慮自己寫的產品的可運維性如何），而一個運維的體系還要包括機房、網(wǎng)絡、硬件、安全等，就更加的復雜和且需要體系化的考慮，。
原文：http://blog.bluedavy.com/?p=363
【編輯推薦】
