Posted in

2000+应用、100w+QPS:超大规模贵州机房迁移历程回顾_AI阅读总结 — 包阅AI

包阅导读总结

1. 关键词:贵州机房迁移、稳定性风险、技术债务、监控告警、应急预案

2. 总结:本文回顾了超大规模的贵州机房迁移历程,指出其带来全域稳定性风险,介绍了从信息梳理等方面进行稳定性保障的措施,包括新增风险处理、历史技术债务解决、监控告警增强、应急预案准备及业务技术侧方案等。

3. 主要内容:

– 贵州机房迁移带来全域稳定性风险,项目组摸索进行保障

– 稳定性保障着手方面

– 信息梳理与摸查

– 新增风险发现与处理

– 历史技术债务处理

– 标准化接入

– 监控告警增强

– 应急预案保障

– 新增系统性风险

– 公网质量导致用户体验差风险

– 跨机房延迟带来应用雪崩风险

– 跨机房传输网络不稳定风险

– 机房同时部署带来数量翻倍风险

– 大规模数据变更带来系统性能风险

– 新机房建设搬迁带来基础设施风险

– 全域团队协作带来人因操作协作风险

– 历史技术债务处理

– ZK 强依赖问题

– 在线业务 Kafka 迁移 Nydus

– 配置硬编码

– 服务间依赖改造

– 资源优化与控制

– 心遇依赖拆分

– 元信息不准确

– 组件版本陈旧

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

– 租户多集群拆分为多应用

– 提供标准化接入、改造治理方式及监控告警

– 准备应急预案

– 业务技术侧方案重点

思维导图:

文章地址:https://mp.weixin.qq.com/s/f8PhqEdgI2j_Zdwp33amWw

文章来源:mp.weixin.qq.com

作者:邵东风

发布时间:2024/7/22 13:37

语言:中文

总字数:11039字

预计阅读时间:45分钟

评分:84分

标签:机房迁移,大规模迁移,稳定性保障,技术挑战,风险管理


以下为原文内容

本内容来源于用户推荐转载,旨在分享知识与观点,如有侵权请联系删除 联系邮箱 media@ilingban.com

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

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

  • 信息梳理&摸查

  • 新增风险发现&处理

  • 历史技术债务处理

  • 标准化接入

  • 监控告警增强

  • 应急预案保障

  • 业务侧技术方案保障

  • 杭州集群下线保障

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

1)机器资源盘点

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

2)长传带宽盘点

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

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

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

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

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

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

  • 因公网质量问题,带来迁移后用户体验差的风险。

  • 因跨机房延迟30ms ,带来的业务侧应用雪崩风险。

  • 因跨机房传输网络不稳定,带来的整体系统性风险。

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

  • 因大规模数据变更,带来的系统性能风险。

  • 因新机房建设、搬迁,带来的底层基础设施风险。

  • 因全域团队协作、大范围配置变更&发布,带来的人因操作、协作风险。

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

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

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

  • 通过客户端预埋逻辑,抽样检测同时请求杭州和贵州机房的RT差异。

  • 通过RT的差异,再下钻分析杭州和贵州机房的差异点。

  • 解决或排除机房、客户端、域名配置等差异,最终得出公网质量的差异。

  • 在正式切流前,解决完成客户端、机房等差异,保障整体网络请求质量。

  • 通过QA侧的整体测试。

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、构建机的性能瓶颈,导致部署、重启时间过长,或服务挂掉。

  • 对迁移当晚核心路径上的服务进行集中访问、操作,因达到服务的性能瓶颈,导致访问超时、白屏、数据延迟、或服务挂掉的问题。

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

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

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

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

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

  • 各部门领导与同事的支持。

  • 分工明确。在战略、战术、细节、事项推进等多个点均有相关人员把控,各司其职。

  • 各项信息的细化梳理&定位。

  • 定期的沟通协作会议,通过敏捷式项目管理,进行滚动式问题发现。

  • 问题发现、治理、验证必须闭环。

  • 尽可能中心系统化、自动化处理。无法自动化的,则提供标准化实施手册。

  • 重点问题,case by case,one by one。

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

  • ZK强依赖问题

  • 在线业务Kafka迁移Nydus。

  • 配置硬编码

  • 服务间依赖改造

  • 资源优化&控制

  • 心遇依赖拆分

  • 元信息不准确

  • 组件版本过于陈旧问题

  • 测试环境自动化部署成功率低

  • 租户多集群拆分为多应用

1)ZK强依赖问题

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

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

2)在线业务Kafka迁移Nydus

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

主要收益:

  • 在线业务稳定性

  • Kafka机器资源回收

  • MQ切流特性&历史债务收敛

在推进层面:

3)配置硬编码

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

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

4)服务间依赖改造

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

  • 减少不必要依赖。

  • 必须不能出现服务跨机房强依赖。

  • 不能因循环调用导致跨机房RT飙升。

5)资源优化&控制

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

  • 统一服务的资源利用率标准,推进资源利用率改造

  • 对部分服务进行合并、下线、缩容处理。

6)心遇依赖拆分

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

7)元信息不准确

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

不足项 解释
应用的元信息需要补充、更新 1. 应用归属的团队信息不准确
2. 应用的废弃、待废弃状态未知
3. 测试应用、非业务应用信息偏杂乱
应用团队归属信息多处维护,未统一 应用在多个平台均有维护,且均存在维护不准确的问题
应用的各项依赖信息不全 应用依赖的db、redis、memcached资源,以及在配置中心的key无法全面准确拉取
应用的各项依赖信息可视化、系统化建设不足 1. 应用依赖的组件版本、依赖的存储资源等,缺乏友好的可视化查询能力。
2. 各项信息之间的关联性建设不足
底层中间件、存储元信息不全 1. 不同的ZK集群的用处缺乏统一维护。
2. 各项元信息反查调用源IP、集群、应用、团队、负责人的能力不足


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

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

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

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

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

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

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

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

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

  • 贵州迁移中间件方案汇总。涵盖所有涉及中间件的迁移、切流、迁移策略、接入等指导方案。

  • 贵州迁移升级指导。涵盖自动升级与手动升级、脚手架应用与非脚手架应用的升级方案。

  • 贵州迁移线上部署指导。涵盖贵州线上部署前的各项必要准备事项,以及特殊应用的注意事项。

  • 贵州迁移监控大盘观测指导。涵盖各类迁移监控的观测指导。

  • 中台、多地域注册拆分指导。涵盖中台租户、多地域注册类型应用的拆分指导方案,以及整体的拆分流程、验证要点等。

  • ddb、redis、memcached、KSchedule等非标治理。涵盖各中间件、存储的非标风险列表、处理办法等。

  • 杭州集群下线指导。涵盖杭州集群如何观察、缩容、下线、机器回收的指导方案。

在监控告警层面,主要提供了:

  • 贵州迁移整体大盘监控。提供了迁移相关全局比例,异常流量,异常比例,能够区分是迁移导致的还是本身杭州服务就有问题导致。同时集成资源层相关指标,判断是单个资源有问题还是全部资源有问题。

  • 贵州迁移应用监控。提供了单个应用的贵州迁移监控,应用贵州杭州流量比例,异常流量,异常比例,能够区分是贵州还是杭州的问题。同时有资源相关的指标。

  • 杭州集群与贵州集群的哨兵监控对比分析。提供指定应用的杭州和贵州集群在CPU利用率、线程池满、异常比例、RT超时等维度的对比。

  • 全局/应用的SLO监控。提供核心指标受损监控。

  • 应用层面的系统监控。研发可通过哨兵、APM来查看定位具体的问题。

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

  • 客户端截流。在开启后,客户端将访问本地或CDN缓存,不再向服务端发送请求。

  • 全站服务QPS限流至安全阈值。在开启后,全站的后端服务将限流调整至较低的安全阈值上,在极端情况下,避免因跨机房RT、跨机房传输、跨机房访问等因素的性能瓶颈引起服务端雪崩。

  • 长传带宽监控&限流。在开启后,部分离线数据传输任务将会被限流。保障在线业务的带宽在安全水位下。

  • 回滚方案。当出现重大问题,且无法快速解决时,逐步将存储、流量切回杭州。

  • 外网逃生通道。当出现长传网络完全中断,需要回滚至杭州。通过外网逃生通道实现配置、核心数据的回滚。

  • 业务领域内的应急预案。各业务领域内,需要考虑切流前的主动降级预案、切流中的应急预案。

  • 批量重启。当出现局部服务必须通过重启才能解决的问题时,将会启用批量重启脚本实现快速重启。当出现全局服务必须通过重启才能解决问题时,需要当场评估问题从而选择全量重启或全量回滚至杭州。

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

  • 应用搬迁范围、搬迁批次梳理明确。当上下游依赖的应用处于不同批次时,需要跨团队沟通协调。

  • 明确业务影响,从而确定各应用的中间件、存储迁移策略。

  • 历史技术债务处理

  • 标准化接入

  • 核心场景稳定性保障方案

  • 核心指标监控建设完善。

  • 切流SOP。包括切流前(前2天、前1天、前5分钟)、切流中、切流后各阶段的执行事项。

  • 切流降级方案、应急预案

  • 切流停止标准

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