网易云音乐宕机,原因曝光!7月份刚迁移完机房，传和降本增效有关。

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

二、项目难点

• 迁移规模大
• 此次需要云音乐以及旗下独立App的服务均整体迁移至贵州。涉及2000+应用、100w+QPS的稳定迁移，同时涉及中间件、存储、机房、三方依赖服务等整体的搬迁，搬迁规模大。
• 业务复杂度高
• 场景复杂。迁移规模大，带来更广的业务场景覆盖。而不同的场景对数据一致性要求不同、延迟敏感度不同。迁移方案需要考虑各种场景带来的问题，并提供标准化的解决方案。
• 服务间依赖复杂。此次带来约2000+应用的搬迁，各服务间的调用和依赖情况复杂，在分批迁移方案中需要协调，以及解决迁移期间跨机房30msRT上升带来的问题。
• 历史积弊多
• 贵州迁移前，存在诸多历史技术积弊，影响着全站整体的稳定性。
• 新增风险大
• 贵州迁移带来诸多新增风险，且风险大、解决难度高。
• 部分场景无法做到真实环境全流程预演。
• 在基础技术建设上，也有一些不足的情况，影响整体搬迁执行效率、迁移准确性。
• 限制条件严苛
• 云音乐有着大量的用户基数，此次搬迁要求：不停机迁移、不产生P2及以上事故。除此之外还有机器、网络带宽、网络稳定性、网络RT、迁移方案等限制条件。
• 事项推进&协调难度大
• 此次搬迁规模大，同样，参与人员规模大，整体协调难度大
• 此外带来较多的人因风险。可能因极小的细节未执行到位，就会造成全局事故。

三、重点限制&要求

• 尽可能少采购或不采购额外的机器，贵州和杭州无法完全对等部署。
• 杭州与贵州的长传带宽控制在200Gbps以内，且存在闪断的可能性，各迁移方案需要重点考虑闪断带来的影响。
• 贵州机房与杭州机房之间网络延迟约30ms，各方迁移方案需重点考虑机房延迟带来的影响。
• 业务可用性要求：不影响核心重点业务场景的可用性，不出现P2及以上事故。
• 控制迁移方案对业务代码的侵入。

四、分批方案

1. 分批的原则

1.1 团队/领域间解耦

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

• 可以将问题拆分、领域清晰。
• 大数据、算法、云音乐技术中心串行搬迁，可以实现机器资源池共享，降低机器采购成本。
• 降低单一团队/领域切流时问题处理复杂度。

1.2 服务端流量自闭环

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

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

1.3 C端优先

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

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

• B端服务搬迁后，腾挪的机器有限。
• B端服务与C端服务相差较大，即使B端服务先行搬迁无问题，也不足以证明C端服务就一定没问题。

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

1.4 在可用资源范围内

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

• 机器资源
• 贵州&杭州的长传带宽资源

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

2. 最终分批方案

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

• 大数据、算法、技术中心串行搬迁。
• 心遇因强依赖云信IM服务，与云信服务独立搬迁
• 技术中心应用基本一批次全部搬迁完成。
• 技术中心的转码、公技侧后台、质量侧系统在第二批次搬迁完成。
• 依据此分类，服务端的组件管理仍有较多可提升空间。