goweb-部署與維護

部署與維護

到目前為止，我們前面已經介紹了如何開發程序、調試程序以及測試程序，正如人們常說的：開發最后的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應用需要考慮那些問題，你應該已經有了全面的了解。本章內容將有助於你在實際環境中管理前面各章介紹開發的代碼。

好刺激呀這一塊

鏈接