• 0

  • 479

闲鱼是这样高效稳定完成项目迁移的

黑猫

我不是黑客

6天前

作者:闲鱼技术——桥泥

1. 项目背景

笔者收到通知,有一个中心化项目需要迁移为部门自建。项目为微服务发布平台,包括闲鱼、淘宝、支付宝、天猫等许多部门的业务,都统一部署在此平台。由于中心化的部署方式有相应的运维和使用的不便,出于规避安全风险考虑,避免双十一期间多业务互相影响产生故障,平台方通知各业务方,进行微服务平台自建。

本项目时间紧急,到deadline总计16个工作日,大概三周时间。 通过对项目背景的梳理,基本的代码阅读,迁移文档的了解,面临的挑战主要有:

  • 项目代码复杂,依赖的中间件多,项目流程长。
  • 数据迁移,项目同时存在mysql和nosql,需要保障数据一致,且不能影响旧业务。
  • 功能验证复杂,除去基本的业务逻辑,还需要检查中间件的功能,且有多应用交互行为。
  • 稳定性保障,新旧项目需要完全隔离,互相不能影响。

相信大家在迁移项目的过程中都或多或少遇到类似的问题,接下来我们来结合实际的处理案例一起看下,笔者是快速安全的克服这些困难。

2. 克服困难

为了方便读者阅读,这里先简单介绍下要迁移项目的功能。 appflow

下面,结合具体的困难,一起看下迁移细节。

2.1 复杂的项目代码

一个要迁移的项目,一定是一个经年累月的老项目,有着庞大的体积,复杂的逻辑,和糟糕的代码味道。面对这样一个项目时,我们又该怎样去快速完成新项目的启动,拿下万里长征的第一步呢?

首先,写代码最快的方法就是粘贴别人的代码(并没有),我们先直接clone一份旧的代码库,git remote set-url origin {new repo}指向新的代码仓库。

接下来,新老项目依赖的配置,部署的方式,乃至运行的服务器,必然是不同的。那么,需要做一些基本的替换:

  • 项目名替换,旧项目名称全局替换
  • 配置替换(代码/中间件),申请新的中间件,在配置文件里替换
  • 域名替换,控制台带有前端页面,需要调整相应的域名
  • 代码包名替换,为了和旧服务完全区分,新的服务需要提供新的jar/war包。
  • dockerfile替换,dockerfile启动项会存在和项目相关的信息,也需要做统一的替换。

最后,进行本阶段验收:

  • 本地可以启动服务
  • 本地打包版本正确

在一系列替换操作下,我们不需要彻底理解老项目,也可以成功运行。这个过程势必会遭遇很多启动失败,我们也可以从失败中吸取经验,了解项目启动的必要条件。 这个过程从9.23开始,到9.27截止,总计经过4个工作日。

2.2 数据迁移

项目迁移的过程中,数据迁移是不可避免,也至关重要的一环。服务的本质是数据的流入和流出,服务的迁移必然涉及数据流的迁移。 一般而言,服务会依赖mysql做复杂数据的持久化存储,nosql做缓存或其他简单结构存储。持久化存储必然需要进行迁移;过期时间短的缓存一般是不需要做迁移的,因为会自动过期;其他存储在nosql的简单结构也需要迁移。 经过以上分析,为了解决数据迁移保障数据一致的问题,笔者进行了以下处理: datamove

迁移过程中有几个需要注意的点:

  • 新老项目数据库完全区分。避免写入脏数据
  • 库表结构一致性。避免上线后出现问题
  • 数据一致性定期校验,避免数据不同步带来的业务影响

通过简单的依赖梳理和迁移工具的运用,可以最小化工作成本和操作风险,迅速完成任务。笔者最终在2个工作日内处理完毕。

2.3 功能验证

本次要去中心化的项目为微服务平台,本身涉及的中间件众多,且涉及到和其他服务的交互,验证流程非常长。如果不做好回归测试的计划,很难保证功能的完整可用,也会为后续的使用带来安全隐患。 为顺利完成复杂的功能验证,在接手项目之初,我们就应该对项目的各种流程有一个清晰的认知,事先列举检查点,对可能的风险和问题有一个预估。 以本次迁移的项目为例,业务检查点主要有:

  1. 登录权限申请

check_login 2. 微服务列表展示 check_list 3. 微服务创建 check_create 4. 微服务发布 check_publish

技术检查点包括:

  • 数据库读写
  • 消息队列,发布/消费
  • 其他中间件使用
  • 网络配置

以上,笔者整理了项目业务/技术上的检查点。在项目启动成功后,一般需要经过测试 - 预发布 - 生产,三个环境的验证,在每个环境部署成功后,都需要对以上的检查点进行检查。

以消息队列迁移的验证为例: check_msg

这个过程中,笔者也遭遇过一些问题,比如因为消息未广播发送,发生消费成功但微服务无法全部更新的情况等。消息队列无法正常打通可能有多种多样的原因,生产、消息通路、消费都需要进行仔细的验证。

总结下,业务上,我们观察业务流程是否正常;技术上,我们通过技术手段检查:

  • 观察服务日志,中间件日志
  • debug工具观察代码执行,对于java开发,可以使用arthas工具,idea的远程调试等
  • 数据库读写数据验证,消息队列接发消息验证等。

在功能验证过程中,我们不可避免的会遭遇各种各样的问题,有心理预期,对症下药,迅速针对问题作出处理,可以有效的提升工作效率,加快迁移进程。 以上流程从9月29日开始,到10月13日截止,经历4个工作日。

2.4 稳定性保障

新项目迁移上线完毕后,还有非常重要的一个环节:稳定性保障。怎么保障新项目的服务稳定?怎么保障新项目的功能使用不会影响到老项目?怎么完成新老项目的交接替换?这些都是我们接下来要讨论的问题。

首先,我们先要保证新项目的稳定性,一般而言,需要对应用本身配置监控,包括但不限于:

  • 服务器基准监控
  • jvm监控
  • 服务接口监控
  • 服务中间件监控

然后,确认新老项目的隔离,一般而言,完全隔离开新老项目的数据库、消息队列等中间依赖,完全隔离部署服务器即可。 接下来,需要确定新老项目的交接替换方案,通常来说流程如下: checkout 几个需要注意的点:

  • 业务上交割时点确认后,需要保证新老项目的同时可用。
  • 发生问题时,可以用老项目做备用来完成业务功能。处理完新项目的问题,继续进行切流。
  • 整个项目上线后,需要一段时间的持续观察,确保观察期间没有意外的问题发生,才能正式结束迁移。

3. 总结

笔者迁移的微服务平台,上线后对其进行了两周的观察,进行了数次微服务发布等。确认应用完全去中心化,业务功能正常,且服务运行稳定。 完整的迁移工作流如下: moveflow 整个流程复盘下来,从项目部署,到项目启动,再到功能验证,最后的稳定观察,笔者都遭遇了各种各样的问题,但是,借助于完善的迁移计划,充足的准备工作,和多位同学的协助,迁移仍然在十个工作日内完成。复盘下来,要点有三:

  1. 拆分复杂问题,逐个突破
  2. 方案考虑周全,减少风险
  3. 充分理解项目,保障业务

迁移充满了安全风险,我们要勇敢的面对风险,包容风险,给出完整的解决方案,希望本文介绍的迁移经验能为读者带来些许的帮助,让迁移更加安全,更加高效。

免责声明:文章版权归原作者所有,其内容与观点不代表Unitimes立场,亦不构成任何投资意见或建议。

信息安全

479

相关文章推荐

未登录头像

暂无评论