一次惨痛的线下机房上云的经历

背景

所有的应用都在本地机房部署

有大概应用在20个左右，其中微服务应用各种组件和服务在8个左右，其他的都是老系统留下来的应用

准备

服务类型	阿里云ECS规格	内存	CPU	机械硬盘	固态硬盘	外网IP和带宽	数量
nginx代理转发	计算网络增强型 sn1ne	8G	4核	300G	无	带宽10M（根据实际使用情况调整）	1
tomcat类后端服务器	通用型g6	8G	2核	300G	无	无	10
redis缓存队列	通用型g6	8G	2核	300G	100G	无	3
redis（可选配置）	内存网络增强型 se1ne	16G	2核	300G	100G	无
redis（可选配置）	内存型（原独享）se1	16G	2核	300G	100G	无
数据库	通用型g6	16G	4核	500G	300G	无	4
数据库（可选配置）	内存型（原独享）se1	32G	4核	500G	300G	无
数据库（可选配置）	内存网络增强型 se1ne	32G	4核	500G	300G	无

部署迁移

        我们的运维小哥哥从6月2号开始进行部署和迁移，三天之后也就是6月5号的时候完成整体的迁移工作，因为我们还在进行项目的迭代工作，所以我们的测试周期啦的比较长。到6月18号左右才完成测试工作。

       6月20号，全员休息，对我们来说是一个好日子，奋斗开始了我和我们的运维小哥哥，测试小哥哥一大早开始来到公司，挂起维护页面。然后就开始干起来了：

       第一步：数据同步，这是一个漫长的等待时间，当然这个主要是运维小哥哥在操作。

       第二步：配置更新，对于微服务来说比较轻松，更改nacos上的配置文件就好了。

      预期规划如下：

	数据库	redis
微服务应用	一主多从	哨兵模式
老应用	多写分离加多数据源	哨兵模式

      对于的老的应用来说，用git做的配置中心，脚本拉取替换（WAR包，JAR包就别想了）的方式，其实更改起来也比较OK。所以配置更新也是相当顺利

        第三步：更新所有的应用到最新的版本，这个就是jenkins上操作即可，无问题。

测试与当天问题发现

     问题1：与第三方应用通讯需要外网的问题。

     解决方式：弹性公网IP

     问题2：文件共享问题

     解决方式：因为本地机房应用是没有专门的文件服务器的，所以采用的软连等相关操作，阿里云上采用的共享和挂载操作

     问题3：第三方推送地址更换问题

    解决方式：联系第三方更改推送地址

    问题4：访问白名单问题

    解决方式：针对443端口开放所有的访问权限。

其他相关功能没有什么问题，基本上到这来说理论上这次迁移是很成功的，虽然忙活了一天但是还是心满意足的下班了。

悲剧的第二天

       第二天，怀着很忐忑的心情，早早的就起来坐到电脑旁边了。8点开始没什么问题，貌似很稳定的情况，8点50左右，我的同事们都开始上班上系统干活了，这个时候悲剧开始了。

      第一个炸弹：大量的同事都是第一次通过外网的域名访问系统，所以大量的并发导致需要拉取大量的静态资源。瞬间带宽超了。这个其实好理解，只是瞬时的，而且后面访问基本趋于平稳状态，10M的带宽基本上能满足需求。OK，这个可以过了。

      第二个炸弹：所有的同事都说卡，访问系统超级慢。然后就是整个钉钉群，微信群就炸了。

开始排查：

     排查一：redis毫无压力，是不是redis没起作用？

     因为redis没有开放外网端口，登录服务器查看。

./redis-cli -a 'pwd'

     使用命令查看所有的key

keys *

   redis正常缓存数据，没有问题。那么这个时候考虑是不是老系统不兼容哨兵配置，改回单机模式。并没有任何效果，redis正常读写没问题。排除

     排查二：数据库，是否是数据库压力过大。

     查看主库：没问题，兼职就是毫无压力

     查看从库：压力爆满，CPU完成超超负荷运行。那么问题来了，为什么会出现这种情况？

     解决方案1：分压，既然主库没有任何压力，那么先在某些应用的节点更改主库为从库，也就是主从一致。

     效果：瞬间主库压力上来，从库反而没有任何压力了。卡顿现象并没有解决。

     解决方案2：查看系统日志，发现某些节点的日志输出频率较慢。是不是因为某些服务器的配置的问题，重启相关服务器和从库。

     效果：依然没有解决我们的问题。

     此时时间已经走到了10点多了。但是经过这几轮的折腾，运维小哥哥突然记起来了，老的应用为了保持会话，是做了IP HASH的问题。以前使用的是内网环境，所以每一个的IP地址都不一样，现在用的外网环境，而公司统一的是专线固定IP，这样就变成了访问系统的IP变成了全一样的了。所以就全路由的一个服务节点上去了，其他的服务节点完全就没起作用了。

       解决方案3：去掉IP HASH策略。

      效果：去掉IP HASH会造成系统整个功能失常，所以基本上这个方案不可取。瞬间感觉好像走到死胡同了，连饭都不想吃了。

       解决方案4：运维小哥哥在拿外卖的时候突然告诉我，我们可以根据IP手动指定路由节点。虽然我们的出网带宽固定了，但是还是有区域划分的，每个区域的IP还是不一样的。

      效果：这个貌似解决了服务节点单一路由的问题。但是还是存在某些节点负载过大的情况，但是相比之前的情况，已经是好很多了。当然问题到这里只是万里长征走了第一步，完全没有实际的解决现在的系统的问题。

      随着一天的上班结束，查询系统数据的人越来越多，查询量增大。这里就得说一下我们的老系统的报表相关的功能了，全是大的SQL汇总起来，有时候一个SQL包含了各种计算，函数，汇总，分组统计等功能。基本上我这么一个程序员老司机都不愿意看这些SQL。

飞升的第三天

      解决方案5：增加数据库从库的CPU能力，升级数据库配置。

      效果：这个时候已经是第二天了，毕竟花钱还是有流程的，当然领导很给力，直接给特事特办了。升级数据库配置，在增加1个从库，这个效果是立竿见影的，速度马上就上来。这个过程本来是个很轻松的过程，但是由于挂载问题，nginx所在的服务器居然重启失败，导致外网IP失效。最后还是联系阿里云的售后解决的。

       这个时候基本上系统访问不存在的问题了，但是各位不要忘记了，IPHASH的问题我们还没有解决。

       这个时候我一直在想nginx的IP hash的这个事情，其实所谓的IP hash不就是通过客户的IP来计算hash值，来确认他的路由保持，那么我在想我们是不是可以找一个替代IP的东西来解决这个会话保持的问题呢。

      在我们的系统里面正好有这么一个东西对于客户来说是唯一的，那就是请求TOKEN，而且这个请求Token就在请求头里面。

      解决方案6：自定义HASH策略

      开启请求头检测

 underscores_in_headers on;

    定义2个路由规则：为什么是两个呢？因为我们有的请求是不需要登录就能获取的也就是没有token的，我们也希望随机轮询。

    upstream https_prod {
	hash $token;
	server 172.17.150.127:8080 ;
	server 172.17.150.128:8080 ;
	server 172.17.150.129:10080 ;
    }
    upstream https_prods {
	server 172.17.150.127:8080 ;
	server 172.17.150.128:8080 ;
	server 172.17.150.129:10080 ;
    }

   获取TOKEN，这里比较特殊的就是，websocket的连接的token我们放在的是Sec-WebSocket-Protocol上，这里注意了，在nginx配置文件中获取的时候，需要吧-换成_

set $token $http_Sec_WebSocket_Protocol;
        if ($http_Authorization != '') {
            set $token $http_Authorization;
        }

定义自动的路由规则

	set $group https_prod;
	set $groups https_prods;

   location ^~ /api/ {
            if ($token != '') {
                proxy_pass http://$group;
            }
            if ($token = '') {
                proxy_pass http://$groups;
            }
            #proxy_pass http://$group;
            proxy_redirect off;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $http_host;
            #WebScoket Support
            proxy_read_timeout 600s;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
	}

到这里，自定义路由规则就完成，重启nginx加载策略。

       效果：比较完美的解决了IP HASH的问题，理论上比IP HASH更加完美。这个时候系统访问速度的问题已经完全解决了

第三个炸弹：老系统的导出功能是，先在服务器上生产一个Excel文件，在吧连接返回给前端，前端通过a连打开下载的。因为a连请求是没有Token的，所以无法保持会话，所以有可能找不到这个文件。

        解决方法：临时，运维小哥哥做了一个共享。

                         最终：文件下载改成流式下载。

        三天已经过去，说实话，心里是贼几把累的，按一个正常程序员的心里，估计已经把前任骂的的飞起，但是其实我反而觉得这次的事情我自己应该有很多值得反思的事情。

• 服务器压力预估不足
• 未深入的去了解系统的功能
• IP HASH的替代方案应该能更快给出，对nginx等相关软件了解的还是不够深
• 定位问题的速度过慢，定位到IP的问题已经超出2个小时。

总结 

    借阿里的事故的一句话：敬畏每一行代码！在成长的过程中壮大自己！