> 本文作者：邵东风 ![](https://p9-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/438cf4591b7346a4a6d86282525468ee~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg572R5piT5LqR6Z-z5LmQ5oqA5pyv5Zui6Zif:q75.awebp?rk3s=f64ab15b&x-expires=1774886301&x-signature=ANEYdUDxnlvTCSINpgkqvSaXepg%3D) ## 一、背景 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. 最终分批方案基于以上原则，最终分批方案如下所示 ![贵州机房迁移分批概览.png](https://p9-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/c942956db4484d42aab390552c3df28d~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg572R5piT5LqR6Z-z5LmQ5oqA5pyv5Zui6Zif:q75.awebp?rk3s=f64ab15b&x-expires=1774886301&x-signature=d%2FuBlKZCo9rdThmRECSFLiZWsL8%3D) * 大数据、算法、技术中心串行搬迁。 * 心遇因强依赖云信IM服务，与云信服务独立搬迁 * 技术中心应用基本一批次全部搬迁完成。 * 技术中心的转码、公技侧后台、质量侧系统在第二批次搬迁完成。 ## 五、切流方案 ### 1. 切流的原则 #### 1.1 可灰度能够按照用户ID、设备ID、IP、流量标几个维度逐步灰度切流。 * 利于预热。在服务启动后，缓存、连接池需要随请求逐步预热，若流量直接全部打过来，可能会将服务打垮。 * 利于测试。能够灰度测试整体功能，避免大面积异常。 #### 1.2 可回滚尽管做了各种稳定性保障来避免回滚，但是如遇到极端情况，仍有整体回滚的可能性。因此搬迁方案必须可回滚。 #### 1.3 控制长传带宽在切流过程中，杭州和贵州之间会有大量的服务访问、数据传输，从而可能突破长传带宽200Gbps的限制。因此切流方案中必须减少不必要的跨区域流量。 ### 2. 切流方案 #### 2.1 切流点选择 ![贵州机房迁移切流点选择.png](https://p9-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/dc391fdc98e2482e91cadeac2bbab334~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg572R5piT5LqR6Z-z5LmQ5oqA5pyv5Zui6Zif:q75.awebp?rk3s=f64ab15b&x-expires=1774886301&x-signature=M%2BOJmaRP1atTFF9GZdtx2TXL2f8%3D) 服务端整体通用架构简化后，如上图所示，因此有如下几个切入点： * 客户端切流。客户端通过动态切换域名配置，可实现流量的切换。切流算法可以与网关使用保持一致，我们在贵州迁移中就采用了此方案，从而大幅降低贵州与杭州的长传带宽。 * DNS切换。因DNS存在缓存过期，不适合作为流量控制的主要手段。在贵州迁移中，我们主要用其作为长尾流量的切换的手段。 * 四层LB切流、Nginx切流。主要由SA侧负责，因自动化和操作复杂度等因素，在贵州迁移中，四层LB切流只用于辅助切流手段，Nginx因过高的人工操作复杂度，不用于切流。 * 网关切流。网关作为服务端广泛接触的首要流量入口，其系统建设相对完善、自动化程度较高，因此作为主要切流手段。在此次迁移中，网关支持按用户ID、设备ID、IP进行按比例切流。 * 定时任务、MQ切换。主要用于定时任务、MQ的流量切换。 * RPC流量控制。RPC流量路由策略与网关保持一致，依据切流比例，进行RPC流量调用。从而避免跨机房RT的不可控。 * 存储层切换。主要负责存储的切换。 #### 2.2 存储层迁移策略云音乐业务场景较多，不同场景下对数据一致性的要求也不一样，例如：营收下的订单类场景需要数据强一致性，而点赞需要数据最终一致性即可。在涉及不同的存储时，也有着多种多样的迁移策略。对此，中间件以及各存储层支持了不同的迁移策略选择，各个业务基于不同的场景，选择正确的策略。迁移策略主要如下： | 类型 | 迁移策略 | | --------- | -------------------------- | | DB | 读本地写远程、读远程写远程、读本地写本地、禁写 | | Redis | 读写远程+需要禁写、读本地写远程+需要禁写、读写本地 | | Memcached | 异步双写、同步双写、不同步 | #### 2.3 切流步骤对以上切入点再次进行分类，可再次简化为流量层切流、存储层切换。在正式切流时，我们按照如下步骤进行切流。 ![贵州机房迁移-切流步骤.png](https://p9-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/80e1920d5f374c4488be17dece77ad38~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg572R5piT5LqR6Z-z5LmQ5oqA5pyv5Zui6Zif:q75.awebp?rk3s=f64ab15b&x-expires=1774886301&x-signature=zpkxgAERogu6CKuW4gt%2BCzOSfXs%3D) ### 3. 回滚方案先存储层按序切换，然后流量层按序切换。 ![贵州机房迁移-回滚步骤.png](https://p9-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/75a20a733b6946948368bc9d4e37f713~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg572R5piT5LqR6Z-z5LmQ5oqA5pyv5Zui6Zif:q75.awebp?rk3s=f64ab15b&x-expires=1774886301&x-signature=7%2FWwo24qnB3ym5zi1gCVyQJJ0Ww%3D) ## 六、稳定性保障&治理 ### 1. 全域的稳定性风险 * 全域的稳定性风险。我们在做一般的活动稳定性保障时，一般从活动的主链路出发，再梳理相关依赖，从而整理出稳定性保障&治理的重点。而这种方法确不适用于贵州机房迁移，从前面的分批概览图可得知：此次贵州机房迁移带来全域的稳定性风险。 * 墨菲定律："如果一件事情有出错的可能性,那么它最终一定会出错。" * 业界没有类似的经验可参考因此整个项目组也在摸着石头过河，在此过程中，既有大的方案的设计，也有细枝末节的问题发现和推进处理。总结起来，我们总共从以下几个方面着手进行稳定性保障： * 信息梳理&摸查 * 新增风险发现&处理 * 历史技术债务处理 * 标准化接入 * 监控告警增强 * 应急预案保障 * 业务侧技术方案保障 * 杭州集群下线保障 ### 2. 信息梳理&摸查盘点梳理机器资源情况、网络带宽、迁移期间服务可用性要求等全局限制条件，从而确定分批方案、迁移思路。 #### 2.1 机器资源盘点主要盘点核数、内存。在此过程中，也推进了资源利用率优化、废弃服务下线等事宜。通过如下公式计算机器资源缺口：*搬迁机器缺口 = 搬迁所需数量 -（可用数量+可优化数量）* #### 2.2 长传带宽盘点需要控制云音乐的长传带宽总量 <= 相对安全的带宽量 *相对安全的带宽量 = (长传带宽总量 / 2 x 0.8) - 已被占用带宽量* #### 2.3 迁移期间服务可用性要求若业务允许全站停服迁移、或仅保障少量核心服务不挂，那么整体迁移方案会简单很多。因此业务对迁移期间的可用性要求，关乎着搬迁方案如何设计。最终讨论后确定，需要：迁移不产生P2及以上事故 #### 2.4 服务间跨区域调用RT摸查基于Trace链路，预测分批情况下RT增长情况。 ### 3. 新增系统性风险此次贵州迁移主要带来的新增系统性风险是： * 因公网质量问题，带来迁移后用户体验差的风险。 * 因跨机房延迟30ms ，带来的业务侧应用雪崩风险。 * 因跨机房传输网络不稳定，带来的整体系统性风险。 * 因杭州和贵州机房同时部署，带来的服务节点数量、API数量、RPC数量翻倍风险 * 因大规模数据变更，带来的系统性能风险。 * 因新机房建设、搬迁，带来的底层基础设施风险。 * 因全域团队协作、大范围配置变更&发布，带来的人因操作、协作风险。 #### 3.1 因公网质量问题，带来迁移后用户体验差的风险贵州公网质量如何？迁移至贵州之后是否会因公网质量问题，导致用户体验差？由于云音乐用户基数大，且注重用户体验，这个是必须提前摸清的问题。若公网质量真的存在较大问题，云音乐可能会停止贵州迁移项目。对此，我们通过如下方式进行了公网质量验证和保障： 1. 通过客户端预埋逻辑，抽样检测同时请求杭州和贵州机房的RT差异。 2. 通过RT的差异，再下钻分析杭州和贵州机房的差异点。 3. 解决或排除机房、客户端、域名配置等差异，最终得出公网质量的差异。 4. 在正式切流前，解决完成客户端、机房等差异，保障整体网络请求质量。 5. 通过QA侧的整体测试。 #### 3.2 因跨机房延迟30ms ，带来的业务侧应用雪崩风险云音乐C端服务当前的RT普遍在5\~70ms之间，若增加30ms，可能会导致请求堆积、线程池打爆等风险。为避免此风险，我们从如下几个方面入手： * 尽可能同一批次搬迁，避免长期跨机房调用。 * 同一批次应用，基于用户ID、设备ID、IP进行Hash，实现同机房调用优先。 * 无法同一批次搬迁的应用。 * 确保会只跨一次，避免因循环调用等原因导致的多次跨机房。 * 需提供降级方案，对服务弱依赖。 * 服务需通过QA侧的测试。 #### 3.3 因跨机房传输网络不稳定，带来的整体系统性风险跨机房网络的现状和参考数据： * 共计2条线，单条带宽为：100Gbps，但建议保持单条利用率在80%及以下。 * 参考网易北京与杭州的长传带宽质量。 * 可能会出现单条中断的情况，在网络侧的表现为网络抖动。若单条线中断，那么发生故障的请求会重连至另一条线。 * 极低概率出现2条线全部中断的情况。基于以上现状，需要重点考虑并解决： * 各中间件、存储在切流期间，长传网络出现问题时的表现、应对和兜底措施。例如ZK重连、重连失败后的重连风暴问题。 * 各服务在切流完成后，若仍长期使用长传网络，若长传网络出现问题的表现、应对和兜底措施。在贵州迁移项目中，我们对以上重点问题进行了梳理和解决，并制定了各种应急预案和极端情况下的回滚方案。 #### 3.4 因杭州和贵州机房同时部署，带来的服务节点数量、API数量、RPC数量翻倍风险因杭州和贵州机房同时部署，带来的服务节点数量、API数量、RPC数量翻倍风险在服务节点数量、API数量、RPC数量翻倍后，主要对底层依赖带来连接、重连上的冲击，以及原有连接数上限的冲击。在我们实际搬迁中，也因遗漏了这一点，导致线上ZK出现瓶颈，进而ZK挂掉的问题。其主要表现为在网关场景下存在数据推送瓶颈。最终通过网关侧的ZK拆分解决该问题。除此之外，DB、Memcached、Redis、MQ等资源的连接数也可能会超过原先设定的上限，需要评估后进行调整。 #### 3.5 因大规模数据变更，带来的系统性能风险大规模数据变更的场景包含但不限于： * 批量调整配置中心值，因达到配置中心的性能瓶颈，导致配置变更时间过长，或服务挂掉。 * 批量的服务部署、重启，因达到K8S、构建机的性能瓶颈，导致部署、重启时间过长，或服务挂掉。 * 对迁移当晚核心路径上的服务进行集中访问、操作，因达到服务的性能瓶颈，导致访问超时、白屏、数据延迟、或服务挂掉的问题。针对以上风险，我们重点对配置中心、K8S、贵州迁移管控平台等系统进行了性能优化，以支撑整体迁移。 #### 3.6 因新机房建设、搬迁带来的底层基础设施风险。因新机房建设、搬迁带来的底层基础设施风险包含但不限于： * 同城双活能力的缺失。为应对此风险，我们在逻辑上继续保留同城双活的能力，并暂时通过机房不同楼层的部署架构，来尽可能弥补同城双活能力的缺失。 * 机器上架、环境搭建、网络传输等需确保达到验收标准。为应对此风险，运维侧提供相关方案保障整体环境，并最终通过业务侧QA验收。 #### 3.7 因全域团队协作、大范围变更&发布，带来的人因操作、协作风险在贵州迁移前，已经有多次发生因配置变更错误带来的事故。而此项目带来从未有过的全域迁移，全域协作，大范围变更&发布，风险不可谓不高。在此过程中，通过了许多方式来保障事项的落地，其中比较关键的点，也是项目成功的关键点包括： * 各部门领导与同事的支持。 * 分工明确。在战略、战术、细节、事项推进等多个点均有相关人员把控，各司其职。 * 各项信息的细化梳理&定位。 * 定期的沟通协作会议，通过敏捷式项目管理，进行滚动式问题发现。 * 问题发现、治理、验证必须闭环。 * 尽可能中心系统化、自动化处理。无法自动化的，则提供标准化实施手册。 * 重点问题，case by case，one by one。 ### 4. 历史技术债务处理在贵州迁移项目中，比较突出的历史债务处理有： * ZK强依赖问题 * 在线业务Kafka迁移Nydus。 * 配置硬编码 * 服务间依赖改造 * 资源优化&控制 * 心遇依赖拆分 * 元信息不准确 * 组件版本过于陈旧问题 * 测试环境自动化部署成功率低 * 租户多集群拆分为多应用 #### 4.1 ZK强依赖问题 ZK的不稳定已导致云音乐最高出现P1级事故，在贵州迁移项目中，因网络环境、机房环境、迁移复杂度等因素，ZK服务挂掉的概率极大，因此必须不能对其强依赖。最终中间件侧对其改造，支持ZK发生故障时，其注册信息降级到本地内存读取。并推进相关依赖方进行升级改造。 #### 4.2 在线业务Kafka迁移Nydus。 Nydus作为云音乐主力MQ产品，相较开源Kafka有更好的监控、运维等能力，Kafka在云音乐在线业务中已不再推荐使用。在贵州迁移中，MQ也需要进行两地切换/切流。主要收益： * 在线业务稳定性 * Kafka机器资源回收 * MQ切流特性&历史债务收敛在推进层面： * 第一里程碑：生产者完成双写 * 第二里程碑：消费者完成双消费 * 第三里程碑：完成废弃TOPIC下线、代码下线等收尾工作 #### 4.3 配置硬编码在贵州迁移项目中，需要做大量的配置迁移、变更。其主要为：机房名、集群名、机器IP、机器Ingress域名的变化。而这些在配置中心、代码、自动化脚本、JVM参数中均有存在，此外，IP黑白名单还可能涉及到外部厂商的改造变更。在具体推进上，采用自动化扫描+人工梳理结合，并辅以标准化改造指引文档。 * 自动化扫描：通过代码扫描、配置中心扫描、JVM参数扫描、连接扫描等方式进行问题发现。 * 人工梳理：外部厂商、不受Git管控的脚本、以及运维侧的配置（例如：存储层访问权限的黑白名单等）、以及自动化扫描可能的遗漏，由各研发、运维人员再次自行梳理。 #### 4.4 服务间依赖改造核心应对杭州与贵州跨机房30ms RT和长传网络不稳定的风险。对循环调用、不合理依赖、强依赖进行改造。 * 减少不必要依赖。 * 必须不能出现服务跨机房强依赖。 * 不能因循环调用导致跨机房RT飙升。 #### 4.5 资源优化&控制因贵州需要与杭州同等容量部署，可能存在资源不足的情况。对此需要： * 统一服务的资源利用率标准，推进资源利用率改造 * 对部分服务进行合并、下线、缩容处理。 #### 4.6 心遇依赖拆分因心遇强依赖云信，且云信IM为心遇核心业务功能，最终确定心遇为独立批次搬迁。因此心遇依赖的中台服务、存储、算法&大数据相关任务，均需拆分出来，不能与云音乐耦合，否则会产生跨机房调用，影响服务稳定性。 #### 4.7 元信息不准确在此次迁移中，存在较多的元信息不准确的问题，例如： | 不足项 | 解释 | | -------------------- | ------------------------------------------------------------- | | 应用的元信息需要补充、更新 | 1. 应用归属的团队信息不准确
2. 应用的废弃、待废弃状态未知
3. 测试应用、非业务应用信息偏杂乱 | | 应用团队归属信息多处维护，未统一 | 应用在多个平台均有维护，且均存在维护不准确的问题 | | 应用的各项依赖信息不全 | 应用依赖的db、redis、memcached资源，以及在配置中心的key无法全面准确拉取 | | 应用的各项依赖信息可视化、系统化建设不足 | 1. 应用依赖的组件版本、依赖的存储资源等，缺乏友好的可视化查询能力。
2. 各项信息之间的关联性建设不足 | | 底层中间件、存储元信息不全 | 1. 不同的ZK集群的用处缺乏统一维护。
2. 各项元信息反查调用源IP、集群、应用、团队、负责人的能力不足 | 以上问题在迁移中，通过脚本、1对1沟通确认、手动梳理等多种方式进行了临时处理，在贵州迁移后，仍需再全面的系统性规划。 #### 4.8 组件版本过于陈旧问题有较多的应用长期不升级，与最新版本跨度较大，存在较多的兼容性问题，需要人工进行升级处理。升级流程大致如下： ![人工升级流程.png](https://p9-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/4c4e964af9494856ab54186dcfd196b4~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg572R5piT5LqR6Z-z5LmQ5oqA5pyv5Zui6Zif:q75.awebp?rk3s=f64ab15b&x-expires=1774886301&x-signature=Q95gVfA4CAhwFZ7txt9OI2RpHww%3D) 在迁移中期，我们进行了自动升级平台建设，基本支持以上升级流程自动化。 #### 4.9 测试环境自动部署成功率低因此次迁移涉及全部的应用在不同环境的部署，全部人工操作的效率过低，因此我们在非线上环境均由脚本自动化部署，而测试环境由于维护不足，部署成功率较低。 #### 4.10 租户多集群拆分为多应用当前贵州迁移时整体会按照应用维度进行迁移、切流到贵州。因此对于中台租户型应用、多地域注册类型的应用需要拆分。 ### 5. 标准化接入除了以上提到的历史技术债务处理和新增系统性风险，公共技术侧大都提供了标准化的接入、改造治理方式。例如： * 贵州迁移中间件方案汇总。涵盖所有涉及中间件的迁移、切流、迁移策略、接入等指导方案。 * 贵州迁移升级指导。涵盖自动升级与手动升级、脚手架应用与非脚手架应用的升级方案。 * 贵州迁移线上部署指导。涵盖贵州线上部署前的各项必要准备事项，以及特殊应用的注意事项。 * 贵州迁移监控大盘观测指导。涵盖各类迁移监控的观测指导。 * 中台、多地域注册拆分指导。涵盖中台租户、多地域注册类型应用的拆分指导方案，以及整体的拆分流程、验证要点等。 * ddb、redis、memcached、KSchedule等非标治理。涵盖各中间件、存储的非标风险列表、处理办法等。 * 杭州集群下线指导。涵盖杭州集群如何观察、缩容、下线、机器回收的指导方案。 ### 6. 监控告警在监控告警层面，主要提供了： * 贵州迁移整体大盘监控。提供了迁移相关全局比例，异常流量，异常比例，能够区分是迁移导致的还是本身杭州服务就有问题导致。同时集成资源层相关指标，判断是单个资源有问题还是全部资源有问题。 * 贵州迁移应用监控。提供了单个应用的贵州迁移监控，应用贵州杭州流量比例，异常流量，异常比例，能够区分是贵州还是杭州的问题。同时有资源相关的指标。 * 杭州集群与贵州集群的哨兵监控对比分析。提供指定应用的杭州和贵州集群在CPU利用率、线程池满、异常比例、RT超时等维度的对比。 * 全局/应用的SLO监控。提供核心指标受损监控。 * 应用层面的系统监控。研发可通过哨兵、APM来查看定位具体的问题。 ### 7. 应急预案在贵州迁移期间，基于以上风险，主要准备如下应急预案： * 客户端截流。在开启后，客户端将访问本地或CDN缓存，不再向服务端发送请求。 * 全站服务QPS限流至安全阈值。在开启后，全站的后端服务将限流调整至较低的安全阈值上，在极端情况下，避免因跨机房RT、跨机房传输、跨机房访问等因素的性能瓶颈引起服务端雪崩。 * 长传带宽监控&限流。在开启后，部分离线数据传输任务将会被限流。保障在线业务的带宽在安全水位下。 * 回滚方案。当出现重大问题，且无法快速解决时，逐步将存储、流量切回杭州。 * 外网逃生通道。当出现长传网络完全中断，需要回滚至杭州。通过外网逃生通道实现配置、核心数据的回滚。 * 业务领域内的应急预案。各业务领域内，需要考虑切流前的主动降级预案、切流中的应急预案。 * 批量重启。当出现局部服务必须通过重启才能解决的问题时，将会启用批量重启脚本实现快速重启。当出现全局服务必须通过重启才能解决问题时，需要当场评估问题从而选择全量重启或全量回滚至杭州。 ### 8. 业务技术侧方案业务技术侧方案重点包含但不限于： * 应用搬迁范围、搬迁批次梳理明确。当上下游依赖的应用处于不同批次时，需要跨团队沟通协调。 * 明确业务影响，从而确定各应用的中间件、存储迁移策略。 * 历史技术债务处理 * 标准化接入 * 核心场景稳定性保障方案 * 核心指标监控建设完善。 * 切流SOP。包括切流前（前2天、前1天、前5分钟）、切流中、切流后各阶段的执行事项。 * 切流降级方案、应急预案 * 切流停止标准 ### 9. 杭州集群下线在服务迁移至贵州后，若杭州仍有流量调用，需排查流量来源，并推进流量下线或转移至贵州。先缩容观察，无正常流量、CDN回源等之后，再做集群下线。 ## 七、测试&演练此次贵州迁移，在各应用标准化治理之后，通过系统批量工具完成贵州各项环境的搭建、测试环境的批量部署。 ### 1. 测试环境演练 #### 1.1 准备事项在测试演练开始前，我们重点做了如下准备： * 贵州测试环境批量创建。通过迁移工具，实现贵州测试集群的批量创建、配置批量迁移等。 * 应用自动化升级。通过自动升级平台，实现大规模应用的批量升级，支持了各组件、各应用的多次快速验证、快速升级。 * 测试环境自动化部署。通过自动化部署脚本，为支持测试环境能够多次、高效演练。 * SOP梳理&平台建设。通过SOP平台，将SOP文档沉淀为系统能力，实现各SOP能力的系统化。 * 迁移监控大盘建设。通过细化梳理监控指标，构建监控大盘，掌握各应用、各组件在切流期间的表现。 #### 1.2 执行步骤 ![贵州机房迁移测试环境演练执行步骤.png](https://p9-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/f3a608944f5b47839617b624fe3b2a63~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg572R5piT5LqR6Z-z5LmQ5oqA5pyv5Zui6Zif:q75.awebp?rk3s=f64ab15b&x-expires=1774886301&x-signature=aAzbDjAkQqfpCNCcgvG3FYbOFoU%3D) 在测试环境演练，总体思路是逐步扩大验证范围，最终达到全局基本功能基本验证通过。以下为主要演练顺序，每一步视执行结果，再选择是否重复执行。 | 顺序 | 验证事项 | | -- | ------------------------------------------------------------------------------------- | | 1 | 验证中间件内部逻辑是否正确：
1. 网关、RPC、存储层路由策略是否正确。
2.验证监控大盘是否正确
3.验证SOP平台是否正确
4.... | | 2 | 验证存储层切换是否正确 | | 3 | 逐一对各业务团队进行演练：
1.加深各团队对切流能力的感知。
2.验证收集中间件、存储在各领域的表现。
3.验证各团队、各领域迁移策略的合理性 | | 4 | 对BFF、FaaS等特殊应用类型进行演练 | ### 2. 线上环境演练因测试环境和线上环境仍存在较大的差异，需要摸清线上真实情况，在演练原则和演练目标上均较测试环境演练有更严格、细致的要求。 #### 2.1 演练原则 * 不对线上数据产生污染； * 不产生线上 P2 以上事故。 #### 2.2 演练目标 | 分类 | 目标内容 | | ------ | ---------------------------------------------------------------------------------- | | 公技演练目标 | 1. 切流验证，网关，rpc，贵州迁移大盘监控
2.网关切流比例、快慢，数据库 ddb 贵州跨机房建连对业务影响
3.端上切流，网关切流验证 | | 业务演练目标 | 1.流量切换，贵州跨机房对业务影响
2.业务指标和SLO
3.业务预案有效性验证
4.RT变化情况 | | 存储演练目标 | 1.ddb 复制延迟，连接数(由于跨机房创建DDB连接非常慢, 主要观察流量到贵州后新建连接对应用和数据库影响及恢复情况)
2.redis数据同步、整体表现 | | 网络演练目标 | 1.跨机房延迟情况
2.跨机房带宽实际占用
3.网络带宽占用监控 | #### 2.3 演练终止条件 * P0、P1 核心场景 SLO 95%以下； * 用户舆情增长波动明显； * 跨机房网络大规模异常； * 大量业务指标或者数据异常； * 贵州流量达到预定 90%。 ### 3. 独立App迁移验证在云音乐主站正式切流前，先对云音乐旗下独立App进行了线上搬迁验证，保障云音乐迁移时的稳定性。 ## 八、系统沉淀 ### 1. SOP平台 SOP即标准作业程序（Standard Operating Procedure），源自传统工业领域，强调将某项操作以标准化、流程化的方式固化下来。 SOP平台将标准化、流程化的操作进行系统化呈现，并对接各中间件平台，实现操作效率的提升。在贵州迁移过程中，能够实现多部门信息同步、信息检查，并显著降低批量操作的出错概率、执行效率，降低人因风险。同时也可为后续其他大型项目提供基础支撑。 ### 2. 自动升级平台自动升级平台串联代码升级变更、测试部署、测试验证、线上发布、线上检测，实现升级生命周期重要节点的自动化。在贵州迁移过程中，显著提升整体升级、验证、部署效率。同时可为后续的大规模组件升级、组件风险治理、组件兼容性摸查、Sidecar式升级提供基础支撑。 ## 九、不足反思 ### 1. 元信息建设仍然不足精准筛选出每项事宜涉及的范围，是顺利进行各项风险治理的前提条件。在此次贵州机房迁移中也暴露出元信息建设不足的问题。 | 不足项 | 解释 | | -------------------- | ------------------------------------------------------------- | | 应用的元信息需要补充、更新 | 1. 应用归属的团队信息不准确
2. 应用的废弃、待废弃状态未知
3. 测试应用、非业务应用信息偏杂乱 | | 应用团队归属信息多处维护，未统一 | 应用在多个平台均有维护，且均存在维护不准确的问题 | | 应用的各项依赖信息不全 | 应用依赖的db、redis、memcached资源，以及在配置中心的key无法全面准确拉取 | | 应用的各项依赖信息可视化、系统化建设不足 | 1. 应用依赖的组件版本、依赖的存储资源等，缺乏友好的可视化查询能力。
2. 各项信息之间的关联性建设不足 | | 底层中间件、存储元信息不全 | 1. 不同的ZK集群的用处缺乏统一维护。
2. 各项元信息反查调用源IP、集群、应用、团队、负责人的能力不足 | ### 2. 各项元信息的创建、更新、销毁标准化、系统化在贵州迁移过程中，做了历史技术债务处理、标准化接入方式，后续可针对各项元信息的创建、更新、销毁进行标准化、系统化建设。例如： * 应用、集群的创建和销毁需要前置校验、审批。以及后期的架构治理扫描。 * 借助组件升级平台，实现组件发布、升级的标准化、系统化。 * DB、Redis、Memcached、ZK的申请、使用、接入等标准化、防劣化。 ### 3. 应用配置标准化目前应用可做配置的入口有：配置中心、properties文件、props文件、JVM参数、硬编码。不同的中间件提供出的配置方式也各有不同，所以各应用的配置比较五花八门。因此可做如下改进： * 明确各种配置入口的使用标准。比如：什么时候建议用配置中心？什么时候建议用JVM参数？ * 在组件提供侧、应用研发侧均有一定的宣贯、提示。避免配置方式过于杂乱。 * 提供配置统一上报的能力。助力元信息的建设。 ### 4. 批处理能力需再进一步增强在贵州机房迁移中，除了SOP平台和自动升级平台的系统沉淀外，业务中间件、Horizon部署平台都提供了一定的工具支撑，从而在一定程度上提升了整体迁移的效率。在之后，随着对效率、系统间融合的要求的提高。需要继续在功能、性能、稳定性等多个层面，继续对批处理、系统间融合进行系统化建设。例如： * 批量拉取、筛选指定条件的应用以及相关依赖信息。 * 基于指定的环境、团队、应用、集群等维度，进行服务的批量重启、部署。此处需要进一步提升测试环境部署成功率 * 基于指定的应用、集群等维度，进行批量的服务复制、配置复制。 ### 5. ZK稳定性、可维护性优化在贵州迁移中，ZK的问题相对突出，对此也投入了比较多的人力去排查、解决以及推进风险治理。后续仍需要在ZK的稳定性、可维护性上探讨进一步优化的可能性： * ZK元信息的维护和使用标准。明确各ZK集群的用处、各ZK Path的用处，ZK集群间隔离、复用的标准，并推进相关标准化治理。 * ZK故障时，因开启降级至内存，业务无法重启服务。若故障期间叠加其他事故，则会导致其他事故被放大。 * 其他稳定性、可维护性梳理 ### 6. 公技侧稳定性保障长效机制和系统化建设尽管在贵州机房迁移中，做了大量的稳定性保障措施，但依赖每个研发对各自负责领域的理解、运维能力。是否能在团队管理、设施管理、服务管理、稳定性管理、架构设计等多方面，探索出一套可持续的长效保障机制？并进行一定的稳定性系统化建设？从而避免点状问题随机发生。 ### 7. 组件生产、发布、治理能力增强贵州迁移中涉及大量的组件变更与发布，以及业务侧组件升级与治理。组件可以从生产侧和使用侧进行分析，而组件生命周期主要由2条主线贯穿： * 组件生产发布线：组件的生产、测试验证、发布。 * 组件风险治理线：风险定义、风险发现、升级推进、升级验证 ![组件治理.png](https://p9-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/7e90f30e216e46e7ba50d2b37698bbaf~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg572R5piT5LqR6Z-z5LmQ5oqA5pyv5Zui6Zif:q75.awebp?rk3s=f64ab15b&x-expires=1774886301&x-signature=mNUHtmCHmDwIwBF17lgu2qZD3Ns%3D) 依据此分类，服务端的组件管理仍有较多可提升空间。 ## 最后 ![](https://p9-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/95d0200e5f484ec2b3f0b246efaece54~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg572R5piT5LqR6Z-z5LmQ5oqA5pyv5Zui6Zif:q75.awebp?rk3s=f64ab15b&x-expires=1774886301&x-signature=4OWR%2FZaIsXbdhjfTs5HY8GDgFNk%3D) 更多岗位，可进入网易招聘[官网查看](https://hr.163.com/)