談談個人windows服務器運維管理

咱們開發的頁遊General War(http://gw.gamebox.com)上線運營也有半年多了，服務器的開發到運維基本都由我一手包辦，在服務器上線以後咱們又招了一個程序員接手後續功能的開發，而我則主要轉到後臺工具開發和服務器運維上。說到服務器的運維，個人所有經驗就是維護過幾臺小型企業的域控，在linux上部署過幾個web服務，之前作遊戲的時候運維都是交給運營方去打點，而此次我是主動承擔了這部分的工做。

因爲咱們的遊戲服務器框架(EasyGame)是基於.net技術開發的，因此選擇windows服務器來部署是比較天然的事情，雖然藉助mono也能夠在linux上部署，但畢竟不如windows的成熟。而一說到windows服務器，不少人會跟我說windows如何低效運維如何麻煩如何的不專業，我我的認爲這只是觀念問題罷了。因爲linux的學習曲線比windows的高，過濾掉了一大批小白用戶，因此給人感受linux的運維更加高效更加專業。但實際上，不論是linux仍是windows重要的仍是看你如何去用。我我的是不太喜歡命令行方式的，由於使用命令行會帶來記憶的負擔，要記住那麼多命令和參數實在是一件麻煩事，命令行的輸出信息缺少有效的組織和排版，閱讀起來也是低效的。可是windows的圖形管理界面也是讓我想吐槽的地方，大部分系統設置的界面都沒有通過良好的組織和設計從而變得極其難用並且低效（好比註冊表，組策略，服務管理等等），windows的配置修改就像魔法通常的存在，常常讓人摸不着頭腦。所以我本身開發了一套自動化運維部署工具來幫助我管理服務器。

個人部署工具的設計目標是這樣的：

1. 支持分佈式的服務部署和管理，可以動態的管理多臺宿主服務器
2. 不用登錄服務器來進行管理，全部對服務器的操做能夠在GUI控制檯程序上完成
3. 用GUI來下降使用難度，用友好的圖表來組織服務器log數據和監控數據，便於閱讀
4. 儘量的下降配置的複雜度
5. 使用腳原本靈活的擴展工具以適應不一樣的需求

咱們的服務器程序自己是分佈式的，須要可以部署在多臺服務器上，所以部署工具自己也是分佈式的，咱們有一個主控服務(ServiceManager)用於管理全部的宿主機以及宿主機上運行的服務，每臺宿主機上有一個宿主機守護進程(ServiceHost)來對宿主機進行管理並向ServiceManager註冊，從而組成一個服務器集羣，而後用戶經過一個GUI控制程序鏈接到ServiceManager上就能夠管理和操做了。對於服務的配置，我採用的原則是約定優於配置，能不配置的東西儘量作到免配置，對常常修改的配置和不太須要改動的配置分開處理，分紅靜態配置和動態配置。好比後端服務常常須要配置服務端口來暴露他的服務，端口的配置是至關麻煩的，搞很差就會出現端口占用衝突，因此這一塊咱們就使用動態端口來進行免配置，服務在ServiceManager上註冊本身所開的端口，別的服務就能夠獲得服務端口。分佈式服務會有多種服務類型，服務之間的互連，動態擴容等若是都經過配置文件來作也會很是麻煩，由於這一塊咱們使用服務名字約定來實現免配置，每一種服務使用一套名字約定來命名，好比前端代理服務器(AgentServer)就使用Agent.id來命名，當一個AgentServer在ServiceManager上註冊以後就會廣播給後端服務，後端服務在獲得這個消息後決定是否要鏈接Agent來提供對外服務，一個後端服務在啓動以後也能夠查看當前集羣中有哪些服務，而後決定是否要去創建鏈接。這樣整個集羣上的服務之間的鏈接就作到了免配置、啓動順序無關而且能夠動態擴容。

對於GUI控制程序來講，GUI是對用戶友好的，但缺點是開發成本較高並且不容易擴展，而命令行是自然的程序接口，對於程序自己十分友好，所以個人目標是要結合2者的優勢，實現一個即容易使用又容易擴展的GUI程序。個人設計是這樣的：首先，每一個服務程序使用標準輸入來接收運行命令，實現服務的啓動、設置、管理和關閉，使用標準輸出來輸出格式化的log數據，這樣的好處就是個人服務自己不依賴於服務容器，能夠在命令行裏能夠看成一個普通的程序來運行和調試，整個設計是非侵入式的並且十分的KISS。而後，由ServiceHost做爲服務容器來運行服務，ServiceHost接管服務的輸入輸出流，這樣控制檯程序就能夠向服務發送命令了。每一個服務所支持的命令及參數都是由服務本身決定的，在控制檯程序上咱們能夠經過一個配置文件來告訴控制檯程序這個服務支持哪些命令和參數，而後控制檯程序會根據配置自動生成出對應的圖形命令按鈕和參數輸入面板。經過配置就能夠生成不一樣服務的管理控制界面，使得GUI有了很好的靈活性。最後，使用按鈕雖然下降了使用難度，可是不利於批量操做，若是我一次有不少服務須要管理，那麼經過點擊按鈕就是低效的，因此我集成了JavaScript來支持自動化腳本，這樣就能夠實現自動化的批量操做。

對於服務的更新，我集成了svn來實現資源文件的上傳和分發，對小規模的集羣來講，svn分發速度不是問題。若是是大規模集羣的話，用svn做爲資源分發源就有點捉襟見肘了，能夠考慮集成p2p服務來實現資源的分發。服務自己支持多版本管理，在服務發佈的時候能夠選擇不一樣的服務版本，來實現AB測試和灰度發佈。

最後，整套部署工具的開發只用了不到8000行代碼，2周的時間開發完成。目前咱們架設了5臺物理服務器來運行近40組遊戲服，2臺linux服務器裝mysql作存儲，2臺作遊戲應用服務器，1臺作web資源下載和後臺遊戲管理工具。有了這套部署工具後，停服更新重啓40組服務，最快只須要不到10分鐘，運行也十分穩定，沒有出現過crash事故。遊戲從上線到如今，咱們基本保持每週發佈一個新版本的頻率，這樣高頻率的版本更新致使遊戲邏輯上不免存在不少bug，好在有部署工具的幫助使得查詢log很是方便，對咱們快速的定位和分析bug起到了很大的幫助。

整體而言，windows服務器的運維管理其實也不難作，懶惰的程序員會讓運維變成一項適合懶人的工做。