导航菜单
路很长,又很短
博主信息
昵   称:Cocodroid ->关于我
Q     Q:2531075716
博文数:356
阅读量:1663697
访问量:207481
至今:
×
云标签 标签球>>
云标签 - Su的技术博客
Tags : 闲鱼,应用迁移,实践发表时间: 2021-10-27 14:01:37

背景

idlecenter是闲鱼服务端元老级应用,在2013年6月idlecenter写下了第一行代码,随后陪伴闲鱼走过了8年的时间。

随着闲鱼业务规模的不断庞大,业务复杂度的不断增加,idlecenter逐渐暴露出一些问题:

  • 应用的垂直业务边界划分和架构分层不清晰,不同领域的业务代码都在idlecenter上迭代,业务代码深度耦合

  • 新的业务不断叠加,老的业务不能及时清理下线,应用规模不断膨胀

直接引发的影响是研发效率:多个团队几十个研发共同维护上百个业务,每次发布都会有十几个分支,每增加一个分支,都会面临代码冲突的风险。据统计一次应用发布构建加部署需要半个小时,分支冲突解决需要二十分钟,严重影响开发效率。

长远影响:

  • 稳定性:业务不能隔离,核心业务与非核心业务都在一个应用上,相互干扰,稳定性不能保障。例如一个非核心业务把资源池打满,就会导致核心服务不能提供服务,引发线上故障

  • 业务垂直化冲突:闲鱼在业务规模快速发展的过程也会进行人员与组织架构的调整。而idlecenter作为一个单体应用,应用架构和人员结构不同态。导致权限不能收口,规范不能拉齐。随着没有规范的业务代码不断迭代,应用的维护成本指数级的增加。

为了解决idlecenter的各种问题,我们从7月份开始对idlecenter进行拆分迁移。到目前我们idlecenter整体迁移进度过半,人力投入成本不到20d,迁移零故障。

本文把我们这次迁移的思路和实践经验沉淀下来,希望能为做应用迁移的同学提供一些思路。

迁移总体分为两个部分:

  • 开发期的代码迁移

  • 运行期的流量迁移

代码迁移

在开发期的代码迁移环节,我们需要思考的问题是:

  • 代码哪些要迁?

  • 怎么迁?

这里我们沉淀了关于代码迁移的普适性原则:

图片

  • 明确迁移的边界,这里的边界包含两个部分:迁移方案的局限性、迁移粒度

    • 明确迁移方案的局限性,明确支持迁移的服务与不支持迁移的服务。例如在我们这次迁移过程中,明确了对消费端服务RPC框架版本的要求,明确了不支持消息的迁移。在做迁移服务梳理的时候,我们就需要初步识别并择出这部分边界外的服务,在代码迁移过程中,也要留意是否有遗漏的没有排除干净的服务。

    • 明确迁移粒度,固定迁移的粒度后能够将应用垂直进行拆解,合理规划应用拆分后的边界。例如在我们方案中,迁移明确的以RPC服务为粒度,做迁移梳理时每个迁移模块的都是一个垂直的RPC服务,每个RPC服务的归属领域清晰,同时迁移方案调研时能明确的从RPC服务出发,来输出一个横向解决所有RPC服务迁移的解决方案。

  • 关注拆分本身,迁移过程保持新老应用代码的一致性,需要做到:

    • 不做代码重构。代码迁移过程也是一次代码review过程,中间或许会发现以前写的代码不优雅不简洁,或有设计缺陷,这时我们应该做的是保持代码的一致性。线上运行的代码往往有QA的测试用例与回归验证覆盖,保证风险收敛在可控的范围内。而迁移过程的每一行代码变更,都有可能成为逃逸在测试用例与回归验证外的“地雷”。

    • 不夹带私货。这与不做代码重构略有重叠,说的是代码迁移过程要干净,杜绝在代码迁移过程中顺带实现额外的业务逻辑,做“功能拓展”。

  • 要迁的干净,代码迁移不仅包含应用内的代码,还需要关注应用外的与应用绑定的配置与逻辑:

    • 中间件相关配置:例如应用上的RPC框架配置,数据库中间件配置,开关配置,配置中心的配置等都需要关注是否和应用绑定,在代码迁移的时候也要将相关配置迁出

    • 中台相关配置:例如闲鱼可能依赖了关键词过滤中台,将代码迁移过程,也需要迁移中台相关配置,为新应用配置中台权限。

流量迁移

在运行期的流量迁移环节,我们主要考虑的两个问题是:

  • 迁移成本:idlecenter中的服务依赖拓扑复杂。推动一个服务迁移可能牵涉到多个上游消费端服务,需要多个团队人员的配合,需要极高的时间与人力成本。如何减少迁移的成本。

  • 稳定性:流量迁移就是高速公路上边跑边换引擎,我们需要如何保障流量迁移过程的稳定性。

迁移方案

太高昂的迁移成本会为迁移项目的推进增加很多阻力,因此在方案调研阶段,需要关注迁移成本问题。我们在方案调研阶段明确了目标:

  • 迁移过程流量可控,具备灰度切流的能力,这是流量迁移稳定性的基础

  • 迁移不需要改造服务消费方代码。改造成本尽可能低

  • 迁移过程能够对服务消费方透明,可以在服务消费方无感知的情况下完成平滑迁移

最终我们设计了基于HSF路由功能的平迁方案。

HSF全称High-Speed Service Framework, 是一个集团内的RPC框架。直接对标的产品是Dubbo。其运行机制总体如下:

图片

引用自hsf-guide文档

涉及核心组件:

  • 注册中心:用于服务注册发现

  • 规则中心:可以配置和推送服务治理规则。应用开发人员可以在控制台编辑保存规则,规则中心中间件会推送到所有指定服务端。

我们方案复用了HSF框架中的服务调用路由规则能力。通过路由规则介入服务消费方的选址逻辑,完成服务提供方的流量迁移。

基于HSF的平迁方案,我们实现了:

  • 服务消费方零改造成本。

  • 迁移过程对服务消费方透明。

最终体现在人力成本上的结果是:迁移成本降到最低,一个人一个星期可以完成一个服务的迁移上线。

解决了迁移成本的问题后,我们需要解决迁移最重要的问题:稳定性保障。

稳定性建设

关于流量迁移过程的稳定性,我们的思路是复用集团内部沉淀的安全生产方法论——安全生产三板斧:可灰度、可观测、可回滚。围绕安全生产三板斧构建稳定性体系。

图片

可灰度实际就是对HSF平迁方案的灰度能力做验证,确保应用在平迁过程中流量分布能符合预期。我们需要考虑的问题有:

  • 灰度能力:HSF平迁方案是否具备灰度能力

  • 流量倾斜验证:HSF路由规则是否会导致流量倾斜。逻辑机房之间的流量,逻辑机房内机器的流量是否均匀分布。

  • RT影响验证:HSF路由规则额外带来的路由选址环节,带来的RT影响有多少,是否在可接受范围内

  • 切流流量无损验证:调整灰度权重过程中,是否能平滑,是否会导致流量损失

其次,我们需要验证HSF平迁方案的可回滚能力:

  • 回滚能力:HSF平迁方案是否具备回滚能力

  • 回滚生效时间:HSF平迁方案回滚生效时间

针对以上待验证点,我们在测试环境做方案POC验证,输出了《HSF平迁方案可行性报告》。简单总结验证结果:

  • 方案具备灰度能力、回滚能力

  • RT影响在3ms以内,可以忽略不计

  • 机房间、机房内流量均匀分布,不会带来切流流量损失或导致流量倾斜问题

  • 路由回滚生效时间在1s以内

可灰度与可回滚能力解决了发布过程中影响面可控的问题。而可观测性是我们稳定性保障的最后一道屏障。可观测性是否准确细致决定了我们灰度平迁过程能否平稳落地。

在我们实践中可观测性建设分为两个部分:

  • 从监控告警出发,我们需要case by case梳理业务背景,针对性的配置监控告警,例如对于敏感词过滤服务,我们不仅需要关注它的调用成功率,也要关注服务的敏感词命中率。除了业务层面的监控,我们再配合配置资源层面的监控,例如流量分布、QPS、CPU内存使用率,来整体的把握服务健康状态

  • 新服务发布上线后,我们需要QA介入对服务进行回归验证。平迁服务我们关注的是新老服务提供的代码逻辑是否是一致的。为此我们接入了集团内的凤凰回归平台,凤凰能够录制线上流量,并在指定的灰度机器上回放,能快速验证新老应用服务逻辑是否保持一致。

在稳定性体系的建设下,我们最终实现了迁移零故障的成绩。

写在最后

最后,要做好应用迁移还有非常重要的一点:做好checklist。提前制定好迁移步骤,切流放量节奏;每次放量时能对影响面有大概量级的评估,在上线前能在测试环境完整演练一遍流程。这里我列出我们程的checklist模板:

  • 迁移确认

    • RPC框架版本、与路由规则互斥的其他规则

    • 中间件配置、中台配置迁出确认

    • 新应用权限确认

  • 消费端服务消费场景

    • 消费场景、QPS量级

  • 资源评估

  • 监控告警配置

  • 回归策略

  • 应急预案

  • 发布流程

    • 切流时间、切流权重

    • 影响请求量

    • 切流路由规则

...阅读原文
推荐文章