作者：闲鱼技术——九七

1. 背景

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

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

• 应用的垂直业务边界划分和架构分层不清晰，不同领域的业务代码都在idlecenter上迭代，业务代码深度耦合
• 新的业务不断叠加，老的业务不能及时清理下线，应用规模不断膨胀

直接引发的影响有：

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

长远影响：

• 稳定性：业务不能隔离，核心业务与非核心业务都在一个应用上，相互干扰，稳定性不能保障。例如一个非核心业务把资源池打满，就会导致核心服务不能提供服务，引发线上故障
• 业务垂直化冲突：闲鱼在业务规模快速发展的过程也会进行人员与组织架构的调整。而idlecenter作为一个单体应用，应用架构和人员结构不同态。导致权限不能收口，规范不能拉齐。随着没有规范的业务代码不断迭代，应用的维护成本指数级的增加。

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

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

迁移总体分为两个部分：

• 开发期的代码迁移
• 运行期的流量迁移

2. 代码迁移

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

• 代码哪些要迁？
• 怎么迁？

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

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

  • 明确迁移方案的局限性，明确支持迁移的服务与不支持迁移的服务。例如在我们这次迁移过程中，明确了对消费端服务RPC框架版本的要求，明确了不支持消息的迁移。在做迁移服务梳理的时候，我们就需要初步识别并择出这部分边界外的服务，在代码迁移过程中，也要留意是否有遗漏的没有排除干净的服务。
  • 明确迁移粒度，固定迁移的粒度后能够将应用垂直进行拆解，合理规划应用拆分后的边界。例如在我们方案中，迁移明确的以RPC服务为粒度，做迁移梳理时每个迁移模块的都是一个垂直的RPC服务，每个RPC服务的归属领域清晰，同时迁移方案调研时能明确的从RPC服务出发，来输出一个横向解决所有RPC服务迁移的解决方案。

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

  • 不做代码重构。代码迁移过程也是一次代码review过程，中间或许会发现以前写的代码不优雅不简洁，或有设计缺陷，这时我们应该做的是保持代码的一致性。线上运行的代码往往有QA的测试用例与回归验证覆盖，保证风险收敛在可控的范围内。而迁移过程的每一行代码变更，都有可能成为逃逸在测试用例与回归验证外的“地雷”。
  • 不夹带私货。这与不做代码重构略有重叠，说的是代码迁移过程要干净，杜绝在代码迁移过程中顺带实现额外的业务逻辑，做“功能拓展”。

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

  • 中间件相关配置：例如应用上的RPC框架配置，数据库中间件配置，开关配置，配置中心的配置等都需要关注是否和应用绑定，在代码迁移的时候也要将相关配置迁出
  • 中台相关配置：例如闲鱼可能依赖了关键词过滤中台，将代码迁移过程，也需要迁移中台相关配置，为新应用配置中台权限。

3. 流量迁移

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

• 迁移成本：idlecenter中的服务依赖拓扑复杂。推动一个服务迁移可能牵涉到多个上游消费端服务，需要多个团队人员的配合，需要极高的时间与人力成本。如何减少迁移的成本。
• 稳定性：流量迁移就是高速公路上边跑边换引擎，我们需要如何保障流量迁移过程的稳定性。

3.1. 迁移方案

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

• 迁移过程流量可控，具备灰度切流的能力，这是流量迁移稳定性的基础
• 迁移不需要改造服务消费方代码。改造成本尽可能低
• 迁移过程能够对服务消费方透明，可以在服务消费方无感知的情况下完成平滑迁移

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

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

引用自hsf-guide文档

涉及核心组件：

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

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

基于HSF的平迁方案，我们实现了：

• 服务消费方零改造成本。
• 迁移过程对服务消费方透明。

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

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

3.2 稳定性建设

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

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

• 灰度能力：HSF平迁方案是否具备灰度能力
• 流量倾斜验证：HSF路由规则是否会导致流量倾斜。逻辑机房之间的流量，逻辑机房内机器的流量是否均匀分布。
• RT影响验证：HSF路由规则额外带来的路由选址环节，带来的RT影响有多少，是否在可接受范围内
• 切流流量无损验证：调整灰度权重过程中，是否能平滑，是否会导致流量损失

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

• 回滚能力：HSF平迁方案是否具备回滚能力
• 回滚生效时间：HSF平迁方案回滚生效时间

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

• 方案具备灰度能力、回滚能力
• RT影响在3ms以内，可以忽略不计
• 机房间，机房内流量均匀分布，不会带来切流流量损失或导致流量倾斜问题
• 路由回滚生效时间在1s以内

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

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

• 从监控告警出发，我们需要case by case梳理业务背景，针对性的配置监控告警，例如对于敏感词过滤服务，我们不仅需要关注它的调用成功率，也要关注服务的敏感词命中率。除了业务层面的监控，我们再配合配置资源层面的监控，例如流量分布、QPS、CPU内存使用率，来整体的把握服务健康状态
• 新服务发布上线后，我们需要QA介入对服务进行回归验证。平迁服务我们关注的是新老服务提供的代码逻辑是否是一致的。为此我们接入了集团内的凤凰回归平台，凤凰能够录制线上流量，并在指定的灰度机器上回放，能快速验证新老应用服务逻辑是否保持一致。

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

4. 最后

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

• 迁移确认

  • RPC框架版本、与路由规则互斥的其他规则
  • 中间件配置、中台配置迁出确认
  • 新应用权限确认

• 消费端服务消费场景

  • 消费场景、QPS量级
• 资源评估
• 监控告警配置
• 回归策略
• 应急预案

• 发布流程

  • 切流时间、切流权重
  • 影响请求量
  • 切流路由规则