部署與維護
到目前為止,我們前面已經介紹了如何開發程式、除錯程式以及測驗程式,正如人們常說的:開發最后的10%需要花費90%的時間,所以這我們將強調這最后的10%部分,要真正成為讓人信任并使用的優秀應用,需要考慮到一些細節,以上所說的10%就是指這些小細節,
應用日志
我們期望開發的Web應用程式能夠把整個程式運行程序中出現的各種事件一一記錄下來,Go語言中提供了一個簡易的log包,我們使用該包可以方便的實作日志記錄的功能,這些日志都是基于fmt包的列印再結合panic之類的函式來進行一般的列印、拋出錯誤處理,Go目前標準包只是包含了簡單的功能,如果我們想把我們的應用日志保存到檔案,然后又能夠結合日志實作很多復雜的功能(撰寫過Java或者C++的讀者應該都使用過log4j和log4cpp之類的日志工具),可以使用第三方開發的日志系統:logrus和seelog,它們實作了很強大的日志功能,可以結合自己專案選擇,
logrus介紹
logrus是用Go語言實作的一個日志系統,與標準庫log完全兼容并且核心API很穩定,是Go語言目前最活躍的日志庫
seelog介紹
seelog是用Go語言實作的一個日志系統,它提供了一些簡單的函式來實作復雜的日志分配、過濾和格式化,主要有如下特性:
XML的動態配置,可以不用重新編譯程式而動態的加載配置資訊
支持熱更新,能夠動態改變配置而不需要重啟應用
支持多輸出流,能夠同時把日志輸出到多種流中、例如檔案流、網路流等
支持不同的日志輸出
- 命令列輸出
- 檔案輸出
- 快取輸出
- 支持log rotate
- SMTP郵件 上面只列舉了部分特性,seelog是一個特別強大的日志處理系統,詳細的內容請參看官方wiki,
使用應用日志
對于應用日志,每個人的應用場景可能會各不相同,有些人利用應用日志來做資料分析,有些人利用應用日志來做性能分析,有些人來做用戶行為分析,還有些就是純粹的記錄,以方便應用出現問題的時候輔助查找問題,
舉一個例子,我們需要跟蹤用戶嘗試登陸系統的操作,這里會把成功與不成功的嘗試都記錄下來,記錄成功的使用"Info"日志級別,而不成功的使用"warn"級別,如果想查找所有不成功的登陸,我們可以利用linux的grep之類的命令工具,如下:
# cat /data/logs/roll.log | grep "failed login"
2012-12-11 11:12:00 WARN : failed login attempt from 11.22.33.44 username password
通過這種方式我們就可以很方便的查找相應的資訊,這樣有利于我們針對應用日志做一些統計和分析,另外我們還需要考慮日志的大小,對于一個高流量的Web應用來說,日志的增長是相當可怕的,所以我們在seelog的組態檔里面設定了logrotate,這樣就能保證日志檔案不會因為不斷變大而導致我們的磁盤空間不夠引起問題,
通過上面對seelog系統及如何基于它進行自定義日志系統的學習,現在我們可以很輕松的隨需構建一個合適的功能強大的日志處理系統了,日志處理系統為資料分析提供了可靠的資料源,比如通過對日志的分析,我們可以進一步優化系統,或者應用出現問題時方便查找定位問題,另外seelog也提供了日志分級功能,通過對minlevel的配置,我們可以很方便的設定測驗或發布版本的輸出訊息級別,
網站錯誤處理
我們的Web應用一旦上線之后,那么各種錯誤出現的概率都有,Web應用日常運行中可能出現多種錯誤,具體如下所示:
資料庫錯誤:指與訪問資料庫服務器或資料相關的錯誤,例如,以下可能出現的一些資料庫錯誤,
連接錯誤:這一類錯誤可能是資料庫服務器網路斷開、用戶名密碼不正確、或者資料庫不存在,
查詢錯誤:使用的SQL非法導致錯誤,這樣子SQL錯誤如果程式經過嚴格的測驗應該可以避免,
資料錯誤:資料庫中的約束沖突,例如一個唯一欄位中插入一條重復主鍵的值就會報錯,但是如果你的應用程式在上線之前經過了嚴格的測驗也是可以避免這類問題,
應用運行時錯誤:這類錯誤范圍很廣,涵蓋了代碼中出現的幾乎所有錯誤,可能的應用錯誤的情況如下:
檔案系統和權限:應用讀取不存在的檔案,或者讀取沒有權限的檔案、或者寫入一個不允許寫入的檔案,這些都會導致一個錯誤,應用讀取的檔案如果格式不正確也會報錯,例如組態檔應該是ini 的配置格式,而設定成了json格式就會報錯,
第三方應用:如果我們的應用程式耦合了其他第三方介面程式,例如應用程式發表文章之后自動呼叫接發微博的介面,所以這個介面必須正常運行才能完成我們發表一篇文章的功能,
HTTP錯誤:這些錯誤是根據用戶的請求出現的錯誤,最常見的就是404錯誤,雖然可能會出現很多不同的錯誤,但其中比較常見的錯誤還有401未授權錯誤(需要認證才能訪問的資源)、403禁止錯誤(不允許用戶訪問的資源)和503錯誤(程式內部出錯),
作業系統出錯:這類錯誤都是由于應用程式上的作業系統出現錯誤引起的,主要有作業系統的資源被分配完了,導致死機,還有作業系統的磁盤滿了,導致無法寫入,這樣就會引起很多錯誤,
網路出錯:指兩方面的錯誤,一方面是用戶請求應用程式的時候出現網路斷開,這樣就導致連接中斷,這種錯誤不會造成應用程式的崩潰,但是會影響用戶訪問的效果;另一方面是應用程式讀取其他網路上的資料,其他網路斷開會導致讀取失敗,這種需要對應用程式做有效的測驗,能夠避免這類問題出現的情況下程式崩潰,
錯誤處理的目標
在實作錯誤處理之前,我們必須明確錯誤處理想要達到的目標是什么,錯誤處理系統應該完成以下作業:
- 通知訪問用戶出現錯誤了:不論出現的是一個系統錯誤還是用戶錯誤,用戶都應當知道Web應用出了問題,用戶的這次請求無法正確的完成了,例如,對于用戶的錯誤請求,我們顯示一個統一的錯誤頁面(404.html),出現系統錯誤時,我們通過自定義的錯誤頁面顯示系統暫時不可用之類的錯誤頁面(error.html),
- 記錄錯誤:系統出現錯誤,一般就是我們呼叫函式的時候回傳err不為nil的情況,可以使用前面小節介紹的日志系統記錄到日志檔案,如果是一些致命錯誤,則通過郵件通知系統管理員,一般404之類的錯誤不需要發送郵件,只需要記錄到日志系統,
- 回滾當前的請求操作:如果一個用戶請求程序中出現了一個服務器錯誤,那么已完成的操作需要回滾,下面來看一個例子:一個系統將用戶遞交的表單保存到資料庫,并將這個資料遞交到一個第三方服務器,但是第三方服務器掛了,這就導致一個錯誤,那么先前存盤到資料庫的表單資料應該洗掉(應告知無效),而且應該通知用戶系統出現錯誤了,
- 保證現有程式可運行可服務:我們知道沒有人能保證程式一定能夠一直正常的運行著,萬一哪一天程式崩潰了,那么我們就需要記錄錯誤,然后立刻讓程式重新運行起來,讓程式繼續提供服務,然后再通知系統管理員,通過日志等找出問題,
如何處理例外
我們知道在很多其他語言中有try...catch關鍵詞,用來捕獲例外情況,但是其實很多錯誤都是可以預期發生的,而不需要例外處理,應該當做錯誤來處理,這也是為什么Go語言采用了函式回傳錯誤的設計,這些函式不會panic,例如如果一個檔案找不到,os.Open回傳一個錯誤,它不會panic;如果你向一個中斷的網路連接寫資料,net.Conn系列型別的Write函式回傳一個錯誤,它們不會panic,這些狀態在這樣的程式里都是可以預期的,你知道這些操作可能會失敗,因為設計者已經用回傳錯誤清楚地表明了這一點,這就是上面所講的可以預期發生的錯誤,
但是還有一種情況,有一些操作幾乎不可能失敗,而且在一些特定的情況下也沒有辦法回傳錯誤,也無法繼續執行,這樣情況就應該panic,舉個例子:如果一個程式計算x[j],但是j越界了,這部分代碼就會導致panic,像這樣的一個不可預期嚴重錯誤就會引起panic,在默認情況下它會殺掉行程,它允許一個正在運行這部分代碼的goroutine從發生錯誤的panic中恢復運行,發生panic之后,這部分代碼后面的函式和代碼都不會繼續執行,這是Go特意這樣設計的,因為要區別于錯誤和例外,panic其實就是例外處理,
規則很簡單:如果你定義的函式有可能失敗,它就應該回傳一個錯誤,當我呼叫其他package的函式時,如果這個函式實作的很好,我不需要擔心它會panic,除非有真正的例外情況發生,即使那樣也不應該是我去處理它,而panic和recover是針對自己開發package里面實作的邏輯,針對一些特殊情況來設計,
應用部署
程式開發完畢之后,我們現在要部署Web應用程式了,但是我們如何來部署這些應用程式呢?因為Go程式編譯之后是一個可執行檔案,撰寫過C程式的讀者一定知道采用daemon就可以完美的實作程式后臺持續運行,但是目前Go還無法完美的實作daemon,因此,針對Go的應用程式部署,我們可以利用第三方工具來管理,第三方的工具有很多,例如Supervisord、upstart、daemontools等,
daemon
目前Go程式還不能實作daemon,詳細的見這個Go語言的bug:http://code.google.com/p/go/issues/detail?id=227,大概的意思說很難從現有的使用的執行緒中fork一個出來,因為沒有一種簡單的方法來確保所有已經使用的執行緒的狀態一致性問題,
備份和恢復
應用備份
在大多數集群環境下,Web應用程式基本不需要備份,因為這個其實就是一個代碼副本,我們在本地開發環境中,或者版本控制系統中已經保持這些代碼,但是很多時候,一些開發的站點需要用戶來上傳檔案,那么我們需要對這些用戶上傳的檔案進行備份,目前其實有一種合適的做法就是把和網站相關的需要存盤的檔案存盤到云儲存,這樣即使系統崩潰,只要我們的檔案還在云存盤上,至少資料不會丟失,
如果我們沒有采用云儲存的情況下,如何做到網站的備份呢?這里我們介紹一個檔案同步工具rsync:rsync能夠實作網站的備份,不同系統的檔案的同步,如果是windows的話,需要windows版本cwrsync,
MySQL備份
應用資料庫目前還是MySQL為主流,目前MySQL的備份有兩種方式:熱備份和冷備份,熱備份目前主要是采用master/slave方式(master/slave方式的同步目前主要用于資料庫讀寫分離,也可以用于熱備份資料),關于如何配置這方面的資料,大家可以找到很多,冷備份的話就是資料有一定的延遲,但是可以保證該時間段之前的資料完整,例如有些時候可能我們的誤操作引起了資料的丟失,那么master/slave模式是無法找回丟失資料的,但是通過冷備份可以部分恢復資料,
冷備份一般使用shell腳本來實作定時備份資料庫,然后通過上面的rsync同步非本地機房的一臺服務器,
MySQL恢復
前面介紹MySQL備份分為熱備份和冷備份,熱備份主要的目的是為了能夠實時的恢復,例如應用服務器出現了硬碟故障,那么我們可以通過修改組態檔把資料庫的讀取和寫入改成slave,這樣就可以盡量少時間的中斷服務,
但是有時候我們需要通過冷備份的SQL來進行資料恢復,既然有了資料庫的備份,就可以通過命令匯入:
mysql -u username -p databse < backup.sql
可以看到,匯出和匯入資料庫資料都是相當簡單,不過如果還需要管理權限,或者其他的一些字符集的設定的話,可能會稍微復雜一些,但是這些都是可以通過一些命令來完成的,
redis備份
redis是目前我們使用最多的NoSQL,它的備份也分為兩種:熱備份和冷備份,redis也支持master/slave模式,所以我們的熱備份可以通過這種方式實作,相應的配置大家可以參考官方的檔案配置,相當的簡單,我們這里介紹冷備份的方式:redis其實會定時的把記憶體里面的快取資料保存到資料庫檔案里面,我們備份只要備份相應的檔案就可以,就是利用前面介紹的rsync備份到非本地機房就可以實作,
redis恢復
redis的恢復分為熱備份恢復和冷備份恢復,熱備份恢復的目的和方法同MySQL的恢復一樣,只要修改應用的相應的資料庫連接即可,
但是有時候我們需要根據冷備份來恢復資料,redis的冷備份恢復其實就是只要把保存的資料庫檔案copy到redis的作業目錄,然后啟動redis就可以了,redis在啟動的時候會自動加載資料庫檔案到記憶體中,啟動的速度根據資料庫的檔案大小來決定,
看到這我明白了我對資料庫了解的還是太少o(╥﹏╥)o
最后的小結
本章討論了如何部署和維護我們開發的Web應用相關的一些話題,這些內容非常重要,要創建一個能夠基于最小維護平滑運行的應用,必須考慮這些問題,
具體而言,本章討論的內容包括:
- 創建一個強健的日志系統,可以在出現問題時記錄錯誤并且通知系統管理員
- 處理運行時可能出現的錯誤,包括記錄日志,并如何友好的顯示給用戶系統出現了問題
- 處理404錯誤,告訴用戶請求的頁面找不到
- 將應用部署到一個生產環境中(包括如何部署更新)
- 如何讓部署的應用程式具有高可用
- 備份和恢復檔案以及資料庫 讀完本章內容后,對于從頭開始開發一個Web應用需要考慮那些問題,你應該已經有了全面的了解,本章內容將有助于你在實際環境中管理前面各章介紹開發的代碼,
好刺激呀這一塊
鏈接
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/47175.html
標籤:Go
上一篇:排序演算法總結
