记20150430平台预迁移

    2015年的第一次通宵献给了公司，作为打杂的我与部门几十个同事留下来通宵测试平台预迁移之后的出现的问题，主要是为了记录下问题，以便接下来真正迁移的时候，可以提前把会出现的问题解决。

    为什么是平台迁移呢？因为，公司的老的业务平台积累了太多的用户和数据，肯定没办法直接停掉去使用新的，但是如果新、旧两套平台同事存在，等以后业务量大了，要做调整和维护的话，那个难度太过于大。再者另一个原因，公司的平台很大一部分是搜索引擎导向型，也就是非常依赖搜索引擎的收录以及排名的。我们私底下都曾经笑称，我们平台都不是面向用户的，是面对爬虫的。于是只能够采用，兼容老的URL是唯一的做法，所谓兼容老的URL，即对老的URL采用新的项目在后端进行响应，或者是采用重定向的方式。

    为什么是半夜迁移呢？...因为，根据前端访问日志可以看到从12点开始的爬虫的访问量开始降低...嘿嘿，夜深人静就开始干活了。

    那我们在平台迁移过程中会出现什么问题呢?

    1、样式等静态资源无法找到，因为前端nginx的配置题，直接将部分站点的一些静态资源请求还是到旧的后端去。

     2、域名生效时间太慢，一些新域名要绑定线上的服务器的，生效时间出乎了预计的。

     3、项目的版本控制没做好，一个比较重要的站点，上线了未发布的版本，导致部分接口无法调用。

     4、数据库压力过大，导致SOA对web项目的响应时间过长，长时间占用了jvm进程的工作线程，这个就导致了对应的web项目连静态资源都无法请求响应了，其实也是对项目太自信。虽然之前已经刷了大量的旧站点的缓存，但是仍然有30%的访问会压到后端，把旧数据大量迁移到新平台业务数据库之后，库的性能急剧下降，这些页面的响应是由新平台去响应的，结果直接卡死项目的响应了。

    其实很多在测试环境无法测试出来的问题，在线上环境并发访问较大的情况下，很容易就暴露出了很多问题。

    呵呵，预迁移结束，又是迁回旧平台，测试也告一段落。通宵后，回家休息了，第一试过这么早下班哈...早上6点~~~~~~