部署的考慮

終於到達上線的這一天了。我要提醒各位看官的是，不管代碼多麼糟糕，到上線時也得上線。這說明部署也是一個逐漸摸索的過程。

 

準備數據庫

隨着開發的深刻，數據會常常變化。尤爲是對於MongoDB這樣的無模式數據庫，修改它的數據模式更是簡單。當Model層改變時，不可避免地要作數據遷移。通常來說，這是一個很繁瑣的工做，並且很容易出錯。

我在項目中使用一個名叫'mongoid_rails_migrations'的gem來處理MongoDB數據庫的數據遷移工做。它是與db:migration兼容的。它還有其餘的好處，【待摸索】。

 

數據庫的索引也是常常變化的。使用命令

bin/rake db:setup RAILS_ENV=production

能夠自動幫助創建索引，這些索引的創建是基於Model層的代碼裏的相關配置。另外，此命令還會爲數據庫作一些其餘的準備工做。

 

因爲數據庫常常變化，數據遷移常常出錯，因此作好數據庫備份就尤其重要了。【待補充】

 

集中配置項

配置項要集中在一個配置文件裏，或者config目錄下的若干配置文件下面，而不能分散在代碼各處。這樣才便於集體修改。還要爲開發環境和生產環境準備不一樣的配置文件。

 

線上運行監控

線上監控是必須的，不然就像盲人同樣摸不着方向，不能預判，也不能很快處理突發狀況。線上運行出現情況是必然的，重點是出現情況咱們要可以知道問題所在。

線上監控的範圍很寬泛，包括服務器性能監控，服務器異常監控等。

我目前只作了監控項目代碼中拋出的未知異常，作到這些是經過rescue_from頂層Exception對象，而後向前端拋出500錯誤並將當前異常情況寫入磁盤文件中。我想要判斷是否有異常發生，是經過查看磁盤上是否有錯誤日誌生成來肯定。

    rescue_from Exception do |ex|
      render status: 500, json: {message: '服務器內部錯誤'}

      now = Time.new.strftime '%y%m%d-%H%M%S'
      open "log/errors/#{now}.log", 'w' do |f|
        f.puts "#{request.method} #{request.fullpath} for #{request.remote_ip}"
        f.puts "Access-Token: #{request.headers['Access-Token']}" if request.headers.include? 'Access-Token'
        f.puts "#{request.parameters}"
        f.puts
        f.puts "#{ex.class}:"
        f.puts ex.message
        f.puts ex.backtrace
      end
    end

上面的異常捕獲代碼也可能會發生異常的。有如下可能：

1. render status: 500, json: {message: '服務器內部錯誤'} 以前已經被render過了，就會拋出AbstractController::DoubleRenderError

2. 讀寫文件的過程當中發生異常

3. 文件編碼默認是utf8，代碼 f.puts "#{request.method} #{request.fullpath} for #{request.remote_ip}" 寫入request.fullpath過程當中可能出現Encoding::UndefinedConversionError。這是由於URL路徑中出現了不能被轉化爲utf8編碼的字符。這是我亟待解決的問題，不能讓它出現。

若是上面的rescue Exception的異常捕獲代碼出現了異常，這時就會發郵件給我了。這是經過名爲exception_notification的gem來實現的。

 

實際上，監測異常是不夠的，並且個人實現方式不便於檢索。當異常出現狀況較少的時候是可取的，但常常出現異常，就極不可取了。一個能檢索、能分類的異常監測系統在項目變大時就很須要了。另外，當訪問量激增，數據量變大，項目變複雜，也須要性能監控系統。網上已經流行了一些監控工具，有些甚至是跨語言的。不過大部分收費，並且不能部署到本地，須要申請帳號鏈接到國外的網站，不方便。