闲鱼应用迁移实践

发表于 3年以前 | 总阅读数：384 次

背景

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介入对服务进行回归验证。平迁服务我们关注的是新老服务提供的代码逻辑是否是一致的。为此我们接入了集团内的凤凰回归平台，凤凰能够录制线上流量，并在指定的灰度机器上回放，能快速验证新老应用服务逻辑是否保持一致。

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