博客

2024年4月8日，腾讯云的认证服务经历了一次重大故障，导致依赖登录认证的服务，包括控制台，无法使用。这不仅严重损害了腾讯云的声誉，也影响了许多人对国内公有云的信心。
幸运的是，腾讯昨天发布了《腾讯云4月8日事件回顾与报告》，详细说明了事件的原因和过程。这种透明度使得事件不再只是一个黑匣子，使我们能够从技术角度分析回顾报告，理解为什么即使是资源如此丰富的腾讯也会遇到这样的事件。
腾讯云的服务中断事后分析
首先，让我们检查腾讯云提供的事件时间线：
15:23：检测到故障并立即启动服务恢复，同时调查根本原因。
15:47：发现版本回滚未能完全恢复服务，需要进一步排查。
15:57：确定根本原因是错误的配置数据，并紧急设计了数据修复解决方案。
16:02：在所有区域启动数据恢复，API服务逐渐逐个区域恢复。
16:05：观察到除上海外所有区域的API服务恢复，需要集中排查上海。
16:25：发现上海技术组件中API循环依赖问题，决定将流量重定向到其他区域以恢复。
16:45：确认上海区域恢复，API和依赖的PaaS服务完全恢复，但控制台流量激增，需要扩展9倍容量。
16:50：请求量正常化，稳定运行，控制台服务完全恢复。
17:45：完成一小时观察期，未发现问题，结束紧急响应。
腾讯云的根本原因分析：
故障是由于新云API版本中缺乏向前兼容性考虑和配置数据的不足灰度发布机制造成的。
在API升级操作期间，新版本的接口协议变化导致后端部署后遗留前端数据传输的处理逻辑异常。这产生了错误的配置数据，由于灰度发布控制不足，迅速传播到所有区域，导致广泛的API故障。
故障后恢复尝试遵循标准回滚程序，同时将后端服务和配置数据回滚到先前版本，并重新启动API服务。然而，循环依赖出现了，因为承载API服务的容器平台本身需要API功能来进行调度能力，阻止了自动服务恢复。最终需要手动操作干预来重新启动API服务并完成恢复。
确定了两个关键问题：
后端版本升级而前端未相应更新，暴露了向后兼容性不足（腾讯云的文档提到了向前兼容性，但上下文表明是向后兼容性问题）。
由于循环依赖限制，回滚失败。
关键问题仍然存在：为什么腾讯云会遇到这些问题？公众评论经常质疑：“鉴于公有云平台在线灰度测试的固有优势，全球规模的中断怎么可能还会发生？”
深层次的技术和架构原因
由于官方事后分析缺乏详细细节，许多方面仍然难以得出结论性分析。然而，作为一个“云平台开发者”，我将根据我的经验分享一些潜在的根本原因：
由微服务爆炸引起的运营挑战
未充分分析的自动化带来的重大风险
请注意，我的观点可能因为我主要在企业软件而不是在线服务上工作而带有偏见，因此建议读者考虑多种观点。
由微服务爆炸引起的运营挑战
首先，我们来定义“微服务爆炸”。正如InfoQ翻译的文章《微服务——版本组合爆炸！》中解释的：
让我解释一下。假设我们的产品由10个微服务组成。现在假设每个微服务都有一个新版本（只有一个版本，听起来微不足道）。将产品作为一个整体来看，每个组件都有一个新版本，我们现在有2^10种组合——我们产品的1,024种排列。
由于没有普遍接受的“黄金法则”来分割微服务，开发人员和团队经常在粒度和边界上存在分歧。这导致大型系统中微服务过度增殖，每个服务都遵循独立的发布周期。尽管像Monorepo这样的解决方案旨在优化这一点，但调试和验证众多微服务仍然具有挑战性。
类似的情况发生在2022年底，当时埃隆·马斯克在推特上（现在是X，尽管仍通常被称为推特）的架构，指出“一个单一请求穿越1,200个微服务RPC”是延迟的原因。
埃隆·马斯克的帖子
虽然这是一个极端案例，但这反映了一个普遍现实：有丰富的微服务和治理措施，如断路器和降级、流量控制和优雅关闭——加上金丝雀发布——开发人员经常难以进行全面测试。自满情绪悄然而至，系统复杂性飙升，风险在失败发生之前不被注意到（尤其是当主动缓解提供的ROI有限时）。
回到这次事件：后端升级与未升级的前端导致与遗留数据结构的兼容性问题。这样的问题不会发生在单体应用中——例如，你永远不会遇到升级InnoDB而没有更新MySQL的解析器时的SQL错误，因为这些组件是一起升级和发布的。
这并不是说单体架构是优越的，而是要强调，随着微服务的过度，版本爆炸变得不可避免。传统的基于库的软件也面临“依赖爆炸”，但这种复杂性