工作总结 - 服务迁移备忘和总结

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/hry2015/article/details/80069933

最近刚刚完成一次服务迁移的工作,本人刚刚从离职同事的手中接手两个新的工程,立即要执行这么大的变动,对我也是巨大的挑战,现对迁移过程和碰到到问题进行记录。
因为业务的需要,需要将2台服务器上的服务迁移到新的2台服务上,主要需求如下:

  • 服务器A1,A2是要迁移的源服务器。服务器B1,B2是要迁移的目标服务器。
  • 服务器A1,A2上部署两个服务:lss和confService。这两个服务是java工程,以war包的形式部署在tomcat中使用jdk6启动。lss服务同时部署中A1和A2,在A1在部署ngnix,为A1和A2做负载,但是因为只部署1台ngnix所有也有单点的问题; confService只在A1上部署一台服务,也存在单点的问题。所有在迁移后,需要为这两个服务配置高可用。
  • 服务迁移过程,同时使用现有的公共服务(如esl服务、话单服务、mysql数据库、redis等)
  • 在服务的迁移过程中不能影响线上业务

整个服务架构图如下:
这里写图片描述
上图分析,原服务框内是我们已有的服务,新服务框内是我们迁移后的服务。当前服务调用的箭头看灰色箭头。完成服务迁移后,服务调用查看绿色箭头。在迁移中间过程中,新旧服务同时存在。

和之前相关的同事讨论梳理业务,服务的大概流通已经清楚。但是因为服务已经运行比较久再加上之前的开发者离职。服务的细节已经没有人知道,需要自己读代码进行理解。以下是操作的整个流程

第一步申请权限,申请登录服务器的ssh权限,登录其中一台服务器。初步判断,lss/confservice服务中新的服务器上运行应该不会影响线网业务,然后将这两个服务从服务器A1拷贝到服务器B1上,尝试进行启动,经历失败多次,分析失败的日志,主要有如下原因:没有访问数据库mysql权限、新的服务器B1,B2和esl服务网络不通、没有访问esl服务权限、confService服务需要暴露到公网上,供能力平台调用。
所有我这边要逐一解决这个问题:

  • 向运维申请mysql的访问权限
  • 申请打通新的服务器B1,B2和esl服务所有服务的网络连接
  • 通知esl服务的开发者将新服务器的IP加入到白名单
  • 申请在2个服务器confService上增加均衡负载并做一个虚地址,并为这个虚地址配置一个公网IP供外网服务调用。因为调用confService服务的IP是固定的,所以为这个公网增加IP白名单选项。另外同时为lss服务增加均衡负载并做一个虚地址,做个虚地址只被外网访问

第二步启动服务成功后,lss一切正常,但是confService却有一个定时任务在运行。我马上停止confService服务,立即查看源码。这个定时任务会定时从redis的一个列表结构的key中使用rpop命令获取记录,然后将这个记录推送到话单服务上,如果推送失败,还需要将这个记录放回redis的相同列表的末尾。分析后,即使confService启动多个,也不会相互影响,虚惊一场。这里也是本次迁移服务没有考虑到的地方,还好confService做的比较好,没有造成问题。所有即使我们事前考虑的很周全,风险点仍然不可以避免的。

第三步发现lss访问confService的地址是配置在mysql数据库,confService访问能力平台时送过去的自己的回调地址也是配置在数据库中,这两个服务重动时会从数据库中加载对应的地址并保存到内存供后续代码使用。这里就有问题,使用新服务器的lss访问confService的地址和confService的回调地址会各原来不一样,但是现在如lss启动时,其内存里保存的confService的地址是从数据库获取,且执行旧服务地址,同时confServic的回调地址也有这个问题。我是这样解决这个问题,在lss服务从数据库中加载配置代码后面加入如下逻辑:读取使用外部配置文件里的lss访问confService的地址,并覆盖内存中的地址。在这个位置增加逻辑是对现有的代码入侵最少的修改。另外我增加一个开关量,只有外部配置文件启动这个开关量,以上逻辑才生效,这个主要是为了,新服务完全替换旧服务后,数据库的配置修改为新的服务后,方便后续这段新的逻辑需要被拿掉,这样以后配置信息还需要从数据库获取。confService的回调地址也是类似的操作。

第四步在向运维人员申请在测试环境配置服务器环境,如果BL,ngnix等信息,通过后,将配置上线到生产环境。

第五步测试。使用测试帐号对这个业务进行测试,这里测试包括自测和调用方测试人员的测试。测试成功后,因为这个服务的访问量不是很大且业务简单,所有将生产环境直接切换到新服务器上。如果业务量大,则需要进行类似灰度测试。

第六步停止旧服务器,新服务运行一段时间后,如果没有问题,旧服务器就可以被回收了,整个服务迁移结束

猜你喜欢

转载自blog.csdn.net/hry2015/article/details/80069933