闲鱼的业务规模和复杂度增加使得idlecenter问题凸显。这不仅影响研发效率，更是关乎整个业务的推进，是个亟待解决的关键问题。
研发效率之困
多个团队众多研发人员维护诸多业务，每次发布分支众多。业务的复杂性让代码冲突频繁。如一次发布构建部署耗时半小时，解决分支冲突就要二十分钟。这样的效率严重拖慢节奏，研发人员苦不堪言，开发周期被大大延长，影响项目进度以及业务的迭代发展。但凡业务有点紧急需求，都可能因为这低下的研发效率而被迫延迟。
这种低效率研发状况，让大家意识到不改变现状不行。每增加一个分支都是一颗定时炸弹，不定何时就会因代码冲突而引发严重的连锁反应，造成更多时间和资源的浪费。
迁移计划开启
7月开始了对idlecenter的拆分迁移。到现在整体迁移进度过半，人力投入不到20天，还实现了迁移零故障。这表明已经取得了阶段性的成果，前期的规划和执行是有效的。
在进行迁移时，不是盲目进行，是有着明确的目标和规划的。整个团队对迁移充满信心，领导也积极推动保障资源供应，使得迁移工作稳步向前推进，向着解决业务问题的最终目标不断靠近。
代码迁移思考
开发期代码迁移环节，有诸多需要考虑的问题。代码迁移不能只关注应用内部分，还要重视应用外与应用绑定的配置和逻辑。要迁就要迁得干净彻底。
这一原则的确立，是大量实践经验的总结。之前就有部分代码迁移因未考虑全面，导致新老代码在运行衔接上出现问题。后续通过复盘找出问题关键，才得出这样的普适性原则，以避免类似错误再次发生。
流量迁移考量
运行期的流量迁移，首先要考虑成本问题。高昂的迁移成本会阻碍项目推进。在方案调研阶段，就要足够重视。通过复用HSF框架的服务调用路由规则能力，介入消费方选址逻辑。
这样做之后效果显著，在人力成本方面，一个人一个星期就能完成一个服务的迁移上线。降低成本的同时也保证了流量迁移的进行，避免因成本过高使项目无法推动情况的发生。
稳定性的保障
迁移中稳定性是最重要的。借复用内部的安全生产方法论，利用可灰度、可观测、可回滚来保障。可灰度验证HSF平迁方案的灰度能力，确保流量分布。可回滚能力也进行验证。
在测试环境做POC验证，并输出可行性报告。可观测性建设分为两部分。通过这些操作保证了迁移零故障，为整个迁移过程保驾护航，不然倘若稳定性出现问题，会对业务造成难以估计的损失。
checklist的重要性
做好应用迁移，checklist是非常关键的。每次放量前评估影响面，上线前在测试环境演练流程。这其实是一种规范操作。有了checklist，能及时发现潜在风险。
之前就有迁移因为忽略了这一步骤，上线时出现意外状况，后来吸取教训在后续迁移中才加入checklist操作，确保流程顺利进行。
你觉得做好迁移最需要把控的是哪一个环节？希望大家点赞、分享并在评论区讨论。
