部署的考虑

终于到达上线的这一天了。我要提醒各位看官的是，无论代码多么糟糕，到上线时也得上线。这说明部署也是一个逐渐摸索的过程。

准备数据库

随着开发的深入，数据会经常变化。尤其是对于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来实现的。

实际上，监测异常是不够的，而且我的实现方式不便于检索。当异常出现情况较少的时候是可取的，但经常出现异常，就极不可取了。一个能检索、能分类的异常监测系统在项目变大时就很需要了。另外，当访问量激增，数据量变大，项目变复杂，也需要性能监控系统。网上已经流行了一些监控工具，有些甚至是跨语言的。不过大部分收费，而且不能部署到本地，需要申请账号连接到国外的网站，不方便。