2023年确定要将云音乐整体服务搬迁至贵州机房，项目需要在各种限制条件下，保障2000+应用、100w+QPS的服务稳定迁移，是云音乐历史上规模最大、人员最多、难度最高的技术项目。在此过程中，解决了大量历史技术债务，同时化解了大量新增系统性风险。以下为总体方案回顾。

尽可能少采购或不采购额外的机器，贵州和杭州无法完全对等部署。

杭州与贵州的长传带宽控制在200Gbps以内，且存在闪断的可能性，各迁移方案需要重点考虑闪断带来的影响。

贵州机房与杭州机房之间网络延迟约30ms，各方迁移方案需重点考虑机房延迟带来的影响。

业务可用性要求：不影响核心重点业务场景的可用性，不出现P2及以上事故。

控制迁移方案对业务代码的侵入。

1）团队/领域间解耦

大团队/领域之间的迁移方案尽可能解耦，分不同批次搬迁。好处：

2）服务端流量自闭环

云音乐服务端需要将流量闭环在同一个机房，避免产生跨区域调用。

云音乐经过微服务之后，目前存在千+服务，各服务间依赖复杂。在贵州机房与杭州机房之间网络延迟约30ms的背景下，每产生一次跨区域调用，则RT上升30ms。

3）C端优先

优先迁移C端相关的应用及其资源，其次B端。

关于此处，会有同学认为优先B端可能会更稳，但优先采用B端优先，会有如下问题：

对于如何保障C端服务搬迁的稳定性，在文章后续章节展开。

4）在可用资源范围内

迁移期间，需要在贵州准备与杭州同等规模的机器资源，因此批次不可能不受到资源的限制。其主要受限制资源为：

因此，按照以上原则进行分批后，若资源仍不足，再根据团队/领域拆分出第二批

基于以上原则，最终分批方案如下所示

1）可灰度

能够按照用户ID、设备ID、IP、流量标几个维度逐步灰度切流。

2）可回滚

尽管做了各种稳定性保障来避免回滚，但是如遇到极端情况，仍有整体回滚的可能性。因此搬迁方案必须可回滚。

3）控制长传带宽

在切流过程中，杭州和贵州之间会有大量的服务访问、数据传输，从而可能突破长传带宽200Gbps的限制。因此切流方案中必须减少不必要的跨区域流量。

1）切流点选择

贵州机房迁移切流点选择

服务端整体通用架构简化后，如上图所示，因此有如下几个切入点：

2）存储层迁移策略

云音乐业务场景较多，不同场景下对数据一致性的要求也不一样，例如：营收下的订单类场景需要数据强一致性，而点赞需要数据最终一致性即可。

在涉及不同的存储时，也有着多种多样的迁移策略。对此，中间件以及各存储层支持了不同的迁移策略选择，各个业务基于不同的场景，选择正确的策略。迁移策略主要如下：

3）切流步骤

对以上切入点再次进行分类，可再次简化为流量层切流、存储层切换。在正式切流时，我们按照如下步骤进行切流。

先存储层按序切换，然后流量层按序切换。

全域的稳定性风险。我们在做一般的活动稳定性保障时，一般从活动的主链路出发，再梳理相关依赖，从而整理出稳定性保障&治理的重点。而这种方法确不适用于贵州机房迁移，从前面的分批概览图可得知：此次贵州机房迁移带来全域的稳定性风险。

因此整个项目组也在摸着石头过河，在此过程中，既有大的方案的设计，也有细枝末节的问题发现和推进处理。总结起来，我们总共从以下几个方面着手进行稳定性保障：

盘点梳理机器资源情况、网络带宽、迁移期间服务可用性要求等全局限制条件，从而确定分批方案、迁移思路。

1）机器资源盘点

主要盘点核数、内存。在此过程中，也推进了资源利用率优化、废弃服务下线等事宜。通过如下公式计算机器资源缺口：搬迁机器缺口 = 搬迁所需数量 -（可用数量+可优化数量）

2）长传带宽盘点

需要控制云音乐的长传带宽总量 <= 相对安全的带宽量相对安全的带宽量 = (长传带宽总量 / 2 x 0.8) - 已被占用带宽量

3）迁移期间服务可用性要求

若业务允许全站停服迁移、或仅保障少量核心服务不挂，那么整体迁移方案会简单很多。因此业务对迁移期间的可用性要求，关乎着搬迁方案如何设计。最终讨论后确定，需要：迁移不产生P2及以上事故

4）服务间跨区域调用RT摸查

基于Trace链路，预测分批情况下RT增长情况。

此次贵州迁移主要带来的新增系统性风险是：

1）因公网质量问题，带来迁移后用户体验差的风险

贵州公网质量如何？迁移至贵州之后是否会因公网质量问题，导致用户体验差？由于云音乐用户基数大，且注重用户体验，这个是必须提前摸清的问题。若公网质量真的存在较大问题，云音乐可能会停止贵州迁移项目。

对此，我们通过如下方式进行了公网质量验证和保障：

2）因跨机房延迟30ms ，带来的业务侧应用雪崩风险

云音乐C端服务当前的RT普遍在5~70ms之间，若增加30ms，可能会导致请求堆积、线程池打爆等风险。为避免此风险，我们从如下几个方面入手：

确保会只跨一次，避免因循环调用等原因导致的多次跨机房。

需提供降级方案，对服务弱依赖。

3）因跨机房传输网络不稳定，带来的整体系统性风险

跨机房网络的现状和参考数据：

共计2条线，单条带宽为：100Gbps，但建议保持单条利用率在80%及以下。

参考网易北京与杭州的长传带宽质量。

基于以上现状，需要重点考虑并解决：

在贵州迁移项目中，我们对以上重点问题进行了梳理和解决，并制定了各种应急预案和极端情况下的回滚方案。

4）因杭州和贵州机房同时部署，带来的服务节点数量、API数量、RPC数量翻倍风险

因杭州和贵州机房同时部署，带来的服务节点数量、API数量、RPC数量翻倍风险

在服务节点数量、API数量、RPC数量翻倍后，主要对底层依赖带来连接、重连上的冲击，以及原有连接数上限的冲击。

在我们实际搬迁中，也因遗漏了这一点，导致线上ZK出现瓶颈，进而ZK挂掉的问题。其主要表现为在网关场景下存在数据推送瓶颈。最终通过网关侧的ZK拆分解决该问题。

除此之外，DB、Memcached、Redis、MQ等资源的连接数也可能会超过原先设定的上限，需要评估后进行调整。

5）因大规模数据变更，带来的系统性能风险

大规模数据变更的场景包含但不限于：

针对以上风险，我们重点对配置中心、K8S、贵州迁移管控平台等系统进行了性能优化，以支撑整体迁移。

6）因新机房建设、搬迁带来的底层基础设施风险

因新机房建设、搬迁带来的底层基础设施风险包含但不限于：

7）因全域团队协作、大范围变更&发布，带来的人因操作、协作风险

在贵州迁移前，已经有多次发生因配置变更错误带来的事故。而此项目带来从未有过的全域迁移，全域协作，大范围变更&发布，风险不可谓不高。在此过程中，通过了许多方式来保障事项的落地，其中比较关键的点，也是项目成功的关键点包括：

在贵州迁移项目中，比较突出的历史债务处理有：

1）ZK强依赖问题

ZK的不稳定已导致云音乐最高出现P1级事故，在贵州迁移项目中，因网络环境、机房环境、迁移复杂度等因素，ZK服务挂掉的概率极大，因此必须不能对其强依赖。

最终中间件侧对其改造，支持ZK发生故障时，其注册信息降级到本地内存读取。并推进相关依赖方进行升级改造。

2）在线业务Kafka迁移Nydus

Nydus作为云音乐主力MQ产品，相较开源Kafka有更好的监控、运维等能力，Kafka在云音乐在线业务中已不再推荐使用。在贵州迁移中，MQ也需要进行两地切换/切流。

主要收益：

在推进层面：

3）配置硬编码

在贵州迁移项目中，需要做大量的配置迁移、变更。其主要为：机房名、集群名、机器IP、机器Ingress域名的变化。而这些在配置中心、代码、自动化脚本、JVM参数中均有存在，此外，IP黑白名单还可能涉及到外部厂商的改造变更。

在具体推进上，采用自动化扫描+人工梳理结合，并辅以标准化改造指引文档。

4）服务间依赖改造

核心应对杭州与贵州跨机房30ms RT和长传网络不稳定的风险。对循环调用、不合理依赖、强依赖进行改造。

5）资源优化&控制

因贵州需要与杭州同等容量部署，可能存在资源不足的情况。对此需要：

6）心遇依赖拆分

因心遇强依赖云信，且云信IM为心遇核心业务功能，最终确定心遇为独立批次搬迁。因此心遇依赖的中台服务、存储、算法&大数据相关任务，均需拆分出来，不能与云音乐耦合，否则会产生跨机房调用，影响服务稳定性。

7）元信息不准确

在此次迁移中，存在较多的元信息不准确的问题，例如：

以上问题在迁移中，通过脚本、1对1沟通确认、手动梳理等多种方式进行了临时处理，在贵州迁移后，仍需再全面的系统性规划。

8）组件版本过于陈旧问题

有较多的应用长期不升级，与最新版本跨度较大，存在较多的兼容性问题，需要人工进行升级处理。升级流程大致如下：

在迁移中期，我们进行了自动升级平台建设，基本支持以上升级流程自动化。

9）测试环境自动部署成功率低

因此次迁移涉及全部的应用在不同环境的部署，全部人工操作的效率过低，因此我们在非线上环境均由脚本自动化部署，而测试环境由于维护不足，部署成功率较低。

10）租户多集群拆分为多应用

当前贵州迁移时整体会按照应用维度进行迁移、切流到贵州。因此对于中台租户型应用、多地域注册类型的应用需要拆分。

除了以上提到的历史技术债务处理和新增系统性风险，公共技术侧大都提供了标准化的接入、改造治理方式。例如：

在监控告警层面，主要提供了：

在贵州迁移期间，基于以上风险，主要准备如下应急预案：

业务技术侧方案重点包含但不限于：

在服务迁移至贵州后，若杭州仍有流量调用，需排查流量来源，并推进流量下线或转移至贵州。先缩容观察，无正常流量、CDN回源等之后，再做集群下线。

此次贵州迁移，在各应用标准化治理之后，通过系统批量工具完成贵州各项环境的搭建、测试环境的批量部署。

1）准备事项

在测试演练开始前，我们重点做了如下准备：

2）执行步骤

在测试环境演练，总体思路是逐步扩大验证范围，最终达到全局基本功能基本验证通过。以下为主要演练顺序，每一步视执行结果，再选择是否重复执行。

因测试环境和线上环境仍存在较大的差异，需要摸清线上真实情况，在演练原则和演练目标上均较测试环境演练有更严格、细致的要求。

1）演练原则

不对线上数据产生污染；

不产生线上 P2 以上事故。

2）演练目标

3）演练终止条件

P0、P1 核心场景 SLO 95%以下；

用户舆情增长波动明显；

跨机房网络大规模异常；

大量业务指标或者数据异常；

贵州流量达到预定 90%。

在云音乐主站正式切流前，先对云音乐旗下独立App进行了线上搬迁验证，保障云音乐迁移时的稳定性。

SOP即标准作业程序（Standard Operating Procedure），源自传统工业领域，强调将某项操作以标准化、流程化的方式固化下来。

SOP平台将标准化、流程化的操作进行系统化呈现，并对接各中间件平台，实现操作效率的提升。在贵州迁移过程中，能够实现多部门信息同步、信息检查，并显著降低批量操作的出错概率、执行效率，降低人因风险。同时也可为后续其他大型项目提供基础支撑。

自动升级平台串联代码升级变更、测试部署、测试验证、线上发布、线上检测，实现升级生命周期重要节点的自动化。在贵州迁移过程中，显著提升整体升级、验证、部署效率。同时可为后续的大规模组件升级、组件风险治理、组件兼容性摸查、Sidecar式升级提供基础支撑。

精准筛选出每项事宜涉及的范围，是顺利进行各项风险治理的前提条件。在此次贵州机房迁移中也暴露出元信息建设不足的问题。

在贵州迁移过程中，做了历史技术债务处理、标准化接入方式，后续可针对各项元信息的创建、更新、销毁进行标准化、系统化建设。例如：

目前应用可做配置的入口有：配置中心、properties文件、props文件、JVM参数、硬编码。不同的中间件提供出的配置方式也各有不同，所以各应用的配置比较五花八门。因此可做如下改进：

在贵州机房迁移中，除了SOP平台和自动升级平台的系统沉淀外，业务中间件、Horizon部署平台都提供了一定的工具支撑，从而在一定程度上提升了整体迁移的效率。在之后，随着对效率、系统间融合的要求的提高。需要继续在功能、性能、稳定性等多个层面，继续对批处理、系统间融合进行系统化建设。例如：

在贵州迁移中，ZK的问题相对突出，对此也投入了比较多的人力去排查、解决以及推进风险治理。后续仍需要在ZK的稳定性、可维护性上探讨进一步优化的可能性：

尽管在贵州机房迁移中，做了大量的稳定性保障措施，但依赖每个研发对各自负责领域的理解、运维能力。是否能在团队管理、设施管理、服务管理、稳定性管理、架构设计等多方面，探索出一套可持续的长效保障机制？并进行一定的稳定性系统化建设？从而避免点状问题随机发生。

贵州迁移中涉及大量的组件变更与发布，以及业务侧组件升级与治理。组件可以从生产侧和使用侧进行分析，而组件生命周期主要由2条主线贯穿：