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