腾讯游戏基于 DeepFlow 的零侵扰可观测性进阶实战

腾讯不仅致力于开发广受欢迎的自研游戏，还与世界各地的知名游戏开发商合作，负责将这些游戏推向市场，让更多玩家享受游戏的乐趣。这些合作伙伴来自全球各地，使用多种多样的技术栈，这为游戏的稳定性维护提出了复杂的挑战。本文旨在探讨腾讯互娱如何利用 DeepFlow 的 eBPF 技术实现无侵入式的可观测性，这一策略不仅确保了游戏渐进式发布过程中的流畅用户体验，还加快了问题的诊断与解决，有效预防了潜在的性能问题。

01

游戏背景介绍

《某游戏》是一款由海外开发商开发、腾讯公司负责发行的游戏。该游戏采用了 Scala、Zio、Istio、CockroachDB 等技术栈，这些技术栈为游戏的上线和运维带来了额外的复杂性和挑战。而且随着项目上线日期的临近，调整代码以增强应用的可观测性变得不切实际，因此开发团队迫切需要一种无需修改游戏业务代码的可观测性解决方案。

在此背景下，团队发现 eBPF 技术能够提供所需的非侵入式解决方案。eBPF 不依赖于特定的技术栈，能够自动生成服务调用图，计算请求、错误、延迟（RED）指标，记录调用的详细信息，并自动生成分布式追踪链路。基于此，游戏发行团队与蓝鲸监控团队联手，开始探索如何快速部署 eBPF 技术，实现游戏业务的无感知、开箱即用的应用可观测性能力，从而确保游戏的顺利上线和高效运维。

腾讯游戏

02

保障渐进式发布时的用户体验

《某游戏》的正式上线采取了一种精心设计的渐进式发布策略，这种策略允许我们在不同的阶段逐渐增加推送新版本的用户比例，一般分为 10%、50%、80% 和 100% 四个阶段。渐进式的发布策略能有效地控制风险，确保新版本能够平稳上线，最终提供给所有用户一个更稳定、更优质的游戏体验。

在渐进式发布策略中，RED 指标（请求速率 Request rate、错误率 Error rate、请求持续时间 Duration）提供了一个实时、直观的窗口，使运维团队能够及时观察到新版本上线对服务性能的具体影响。通过这些指标，团队可以作出数据驱动的决策，比如是否继续扩大用户群、是否需要进行性能优化、或者是否回滚至旧版本。这种精细化的控制，最终目的是为了保障用户获得最佳的游戏体验，同时保护业务的稳定性和连续性。

目前《某游戏》每次发版以后，对比新旧版本 POD 的 RED 指标差异已经融入到发布过程中的检测清单中，如果指标量差异不大，则说明此次更新并没有引入性能降级、严重性错误、以及负载不均衡等问题。再结合其他的业务特性指标，则可以有信心决策继续执行全服更新。

RED 指标

在渐进式发布过程中，如发现异常，可通过调用详情快速定位请求的 API、参数、响应时间、返回状态码等信息。帮助运维人员迅速分析问题所在，进行故障排除和问题解决。

调用详情

同时可借助全自动分布式追踪能力，发现潜在的性能瓶颈，以帮助进行性能调优，持续提升系统的响应速度和稳定性。

分布式追踪

03

实战：消除新版本 CPU 飙升隐患

在《某游戏》上线后的几次在线更新中（集中在早上 5:00-6:00 之间），发现每次有新的配置表发布时，整个集群服务器的 CPU 使用率都会飙升，看起来就像是客户端对服务器发起了 DDoS 攻击一样。

CPU 飙升

从《某游戏》的运行特点来说，服务器的 CPU 不需要处理过多的计算逻辑，主要消耗应该只随客户端请求量或者在线玩家而增加。从下图的在线玩家数量曲线可以看到，发布期间并没有明显的突增，因此可以认为业务没有受到影响。

在线玩家数

另一方面，由于这些疑似 DDoS 的流量都是正常客户端发起的请求，安全团队的 DDoS 防护系统会认为这是正常的流量，也不会予以处理。以往，这类基础设施 CPU 指标的异常通常会到此无疾而终，时不时会有同学尝试去分析升级阶段的应用日志，但由于体量实在太大，也没有明显的进展，只能姑且认为程序启动时确实处理了更多业务逻辑从而消耗了更多 CPU。

分析思路对比图

在上线了 eBPF 可观测性之后，这类问题一下变得简单直接了：

Step 0 - 持续监控：升级过程中持续监控集群 QPS 趋势，此时利用基于 eBPF 自动获取的 Ingress 网关 Request Rate 指标量来进行分析，发现 QPS 有将近10倍的突增。已经基本可以断定此前发现的 CPU 上涨是由于 QPS 突增导致的。

Request Rate

Step 1 - 下钻分析：接下来继续基于 eBPF 自动获取的调用详情分析，通过分析 URI 占比图，发现有将近 70% 是来自某个客户端的 SDK。

URI 占比图

Step 2 - 定位根因：我们可以基于 eBPF 的明细 Request Log 或者业务日志进一步分析，不管哪种方法，需要分析的日志数量都已经被大大减少了。我们在业务日志中查找 URI 对应的日志，发现是因为此客户端 SDK 在发送 gRPC 请求时携带的版本与服务端不一致，导致请求一直被服务端拒绝，拒绝后客户端又高频的重试，造成了对服务端的 DDoS 攻击。研发确认此问题后，立马进行了修复。修复上线后持续监控，已确认在配置表更新后集群 QPS 突增的现象不存在了，CPU 也表现正常了，成功消除了一个重大隐患。

除此之外，蓝鲸团队与 DeepFlow 社区联合在新版支持了自定义获取 gRPC Header 字段，我们已经将表示客户端版本号的 metadata 提取至调用日志中，进一步避免未来再发生类似问题。

metadata 提取

总结：利用 eBPF 提供的业务无感知的 Request Rate 快速的确定集群 QPS 突增，再利用调用详情精准的定位 URI 异常，只需简单几步，即可让新版本性能隐患及早发现，成功避免了可能发生的严重线上故障。

04

案例总结

本文通过《某游戏》的上线和运维过程，深入展示了腾讯互娱如何利用 eBPF 技术有效应对复杂技术栈所带来的挑战。通过引入 DeepFlow 基于 eBPF 的零侵扰可观测性能力，我们不仅加速了问题的排查和解决过程，还显著提升了游戏的稳定性和用户体验。

通过采用渐进式发布策略，我们得以在各个发布阶段细致监控性能指标，从而确保每一次更新都能带给玩家更加流畅和稳定的游戏体验。实际案例表明，eBPF 技术使我们能够迅速响应性能变化，有效识别并解决潜在问题，从而保障游戏的连续运营和服务质量。

最终，通过这些技术的应用，我们不仅成功地提升了《某游戏》的性能和稳定性，还为未来的游戏运维设立了新的标杆。这些成果证明了基于 eBPF 技术的可观测性能力，在应对复杂技术环境和提升用户体验方面的巨大潜力。

我们期待在未来继续探索和分享更多技术创新和成功实践，为用户带来更优质的游戏体验，并为行业提供有价值的见解和解决方案。