Presentation: How Eve Online Leverages Head Based Sampling to Observe "Fun"

InfoQ：Eve Online如何利用基于头部的采样观察"乐趣"

InfoQ 主页 演示 How Eve Online Leverages Head Based Sampling to Observe "Fun"

架构与设计

从代币到特性：为AI辅助工程构建成本归因架构（10月29日网络研讨会）

Eve Online如何利用基于头部的采样观察"乐趣"

点赞

新下拉阅读列表

• 阅读列表

查看演示

• 垂直

• 水平

• 全屏

播放速度：

• 1x

• 1.25x

• 1.5x

• 2x

下载

• 演示文稿

41:10

概述

Nicholas Herring分享了EVE Online如何在20年历史的MMO架构中实现分布式追踪和可观测性。他讨论了如何利用基于头部的采样、动态指数移动平均（EMA）和确定性采样技术，在保持系统高保真度的同时控制遥测成本，并避免高吞吐实时游戏模拟导致的性能下降。

个人简介

拥有20多年军用和游戏技术经验的Nicholas Herring，曾构建过连接战术网络和游戏引擎的专利分布式系统。他领导过实时人类生物信息学的研发，并交付过多个云规模游戏作品。目前，他将实时模拟和架构方面的专长应用于CCP Games的EVE Online宇宙现代化改造。

关于会议

软件正在改变世界。QCon伦敦通过促进开发者社区中的知识和创新传播，赋能软件开发。作为以实践为导向的会议，QCon专为技术团队负责人、架构师、工程总监和项目经理设计，这些人群在团队中推动着创新。

INFOQ 会议

• 2026年10月29日，美国东部时间下午1点 从代币到特性：为AI辅助工程构建成本归因架构 主讲人：Martin Reynolds - Harness首席技术官，Barani Mohandoss - Trimble云治理、FinOps与E-工具总监

演讲实录

Nicholas Herring：今天我想分享我们如何将可观测性引入一个已有20年历史的系统，同时该系统下方还存在不断演进的新机制。我将探讨这种架构与传统应用开发相比在游戏开发领域的差异，并与金融科技领域做些对比，因为这两个领域存在一些相似之处。最终，我们将讨论我们的系统完全采用基于头部的采样，这会让很多人感到惊讶，因为我们没有使用尾部采样，这意味着我们承担了诸多权衡取舍。我们将探讨这些权衡的具体内容。通过融合动态和确定性采样技术，我们如何实现这一目标？动态采样中指数移动平均采样的"双刃剑"效应，我们将深入探讨这些核心技巧。最终，我们如何利用这些方法在保真度和成本之间找到平衡点。

在深入探讨之前，我们先来了解传统软件架构与视频游戏架构之间的一些差异。大多数传统软件为单个用户创建独特的体验。传统软件很少同时为多个用户构建共享体验。这种差异在我们构建和扩展这些系统的方式中显而易见——每个用户都有自己的网页，而不是所有人共享相同的网页。相比之下，多人在线游戏必须创建共享体验。要实现这种共享体验，意味着我们需要以与金融科技行业类似但截然不同的方式处理大量数据同步问题：数据必须具有事务性，且需要能够复制数据，让所有用户同时体验相同的共享场景。

与金融科技行业不同的是，视频游戏会处理许多系统本身并不需要关注的细节。例如在视频游戏中向他人挥手，只是玩家在虚拟世界中行为的一种表达。对于《EVE Online》我们也会探讨这些方面。游戏行业一直像那个开着改装车的有趣叔叔——虽然制造这些车很酷，带着它去杂货店也很有趣，但大多数人看到后会疑惑："你为什么要这么做？"这种现象的主要原因在于，游戏需要赋予玩家在虚拟世界中表达自我、以各种现实生活中难以实现的方式与他人交流的能力。

什么是EVE Online？

在深入讨论我们如何监控系统之前，我想了解一下在座各位有多少游戏玩家？在座有多少人听说过《EVE Online》？我将简要介绍《EVE Online》的基本情况及其当前发展状况。网络太空飞船是严肃的生意。最终，这款游戏因史诗级间谍故事而闻名。如果你没听说过《EVE Online》，可能通过媒体报道了解过——我认为我们获得的最大曝光是CNN曾报道过某玩家在游戏中盗取价值数十万美元的资产。需要特别说明的是，《EVE Online》是一款单服务器MMO游戏，这意味着我们没有北美服务器、亚太服务器或欧洲服务器。所有玩家都在同一个服务器上，同时体验相同的宇宙——这又回到了那个开着改装车去杂货店的叔叔的比喻。

为什么有人会故意这么做呢？这会引发各种技术难题。我对此有专门的演讲。另一个需要记住的要点是，这是一个由玩家驱动的生态系统。我们市场每天大约有50万笔交易，这代表了生态系统中约120亿件物品的流动。请注意，这还包括宇宙中每一颗子弹，这一点在我们讨论时需要牢记，因为我们也必须谈到追踪、生态系统中飞行的子弹、激光和导弹，以及我们如何处理这些问题，稍后我们会详细说明。为了让你了解EVE Online的规模及其运作方式，我们保持着几项吉尼斯世界纪录，其中最昂贵的一场战斗花费了近40万美元，持续时间最长的PvP战斗则有近9000名玩家参与。

此外，还有同时在线玩家数量最多的多人游戏PvP战斗，达到了6500名玩家。这6500名玩家在同一地点不断互相攻击，这让你对EVE Online的规模有了直观的认识，并将这种规模与你们在不同场景中交互和构建的系统联系起来，这些系统与传统的软件有所不同。当你们可以专注于用户的会话时，我们必须专注于所有体验该星系的玩家所处的星系状态。

20年的EVE开发

EVE Online的另一大特点是这是一个非常古老的项目。开发工作始于2000年之前，确切地说是20世纪90年代末。EVE Online的最初版本也在此时诞生。它拥有超过200万个真实的变更列表，我正在努力剔除其中的机器人生成内容。它包含约170万行C和C++代码。我还拥有Unreal引擎的代码量作为参考，将行数与之对比，可以很好地理解其规模。EVE Online的构建使用了大量Cat 5电缆和海量的SQL存储过程。我们还有260万行SQL代码，其中大部分是运行在MSSQL服务器中的所有遗留系统的主体部分。然后还有一个名为“script”的神奇文件夹，其中包含340万行Python代码。令人愉快的是，这部分代码使用的是无栈2.7版本的Python。

我们有一个更长期的项目目标是升级到Python 3。无栈2.7 Python的含义是，我们只能在一个逻辑处理器上运行，而不是一个核心或一个逻辑处理器。我们一次只能处理一件事。这一点在谈到采样时会变得重要。如果这没有让你感到困扰，那么宇宙的定义大约包含5300万行YAML代码。这是我组织中正在进行的个人重要任务之一，旨在显著降低这个数字。接下来我们将简要讨论这一演变过程。我也在GDC上做过相关演讲，讨论EVE Online后端技术的演进方向。它正在从我们之前列出的这些单体结构转向一个统称的框架，我们称之为Quasar。Quasar只是一个术语，用来指代Kube、Golang、gRPC、protobuf、RabbitMQ、NATS等所有这些在过去十年中大家广泛使用的技术。

这两个系统结合后，包括遗留系统和较新的Quasar生态系统，每秒可以处理大约30,000条消息。这里的“消息”可以是事件、请求、响应，以及我们称为“通知”的信息类型，即推送给客户端的信息。我们构建了这个消息总线生态系统，作为构建领域服务旅程的起点，因为我认为“微服务”这个词有些被过度使用了。这个概念已经存在了一段时间，但至今没有人能准确告诉我它的定义。我们在领域服务中工作，其中包含用户、飞船、太阳系等概念，这些是我们在该环境中运行的服务。我们也将这些概念用于功能层面，例如在EVE Online中，我们有一个相对新颖的系统，允许玩家为其他玩家创建任务和任务目标。这本身就是一个独立的服务和生态系统。

游戏内体验

让我们看看这些内容在纸面上是什么样子。这是大约一个月前发生的一场战斗。我从我们优秀的社区经理在Twitch上分享的内容中截取了这个画面。在这里，我们可以看到大约有300人参与战斗，两支不同舰队按照传统方式组织了界面，红色对蓝色。这展示了我们需要处理的玩家表达方式的复杂性。在如此大规模的场景下，玩家的表情很难被清晰辨认，细节会变得模糊。但如果你仔细观察其中一些玩家，就能看到他们如何通过自己的方式表达。游戏中有一个名为Skinner的系统（名字非常有创意），玩家可以使用完整的设计系统来创建飞船皮肤。

玩家利用这个系统表达不同的制服或情绪，例如为昂贵的飞船设计情绪环。我们曾测试过这个系统的性能，当时在本地测试服务器中有500人参与，大概有三台树莓派设备在运行。我们尝试让所有玩家尽可能快速地切换飞船皮肤，并关闭了所有限流机制。仅此一项操作就产生了与整个宇宙相同的消息量，即每秒约50,000条消息。我强调这一点，是因为它也体现了在虚拟环境中表达自我的重要性，以及我们需要解决的相关问题。这成为玩家之间不同于聊天或互相射击的另一种沟通方式，又为他们提供了另一种表达自我的渠道。我们还有其他形式的表达方式，例如当然还有太空烟花，以及其他各种元素。我认为在某些冬季庆典中，我们甚至还有雪球。

当我们在思考这个问题时，这正是所有乐趣和游戏的部分。这正是有趣的地方。我们开始讨论我们组织的座右铭，即“让虚拟游戏在现实生活中更有意义”。你可以从中领悟到这一点。这就是 EVE 的起源理念。EVE Online 最初的总体声明是“死亡是一件严肃的事情”。为了说明这一点，EVE 中有一个最大的舰船类型叫做泰坦（Titans）。这些舰船在游戏中大约有 16 公里长，每艘舰船的建造成本和装备、弹药等所有材料费用大约相当于 1000 欧元。如果将游戏内的货币换算成现实货币，每艘舰船的价值大约在 1000 欧元左右。这背后存在一种“重力”效应，因为如果这艘舰船被摧毁，它就永远消失了。

你无法再将其找回。没有方法可以恢复这些舰船。除非你向游戏管理员投诉并碰巧获得幸运，但这几乎不可能，因为管理员们经过高度训练，通常会忽略这些请求。现在屏幕上，我们能看到一个完整的气泡，里面大约有 40 艘这样的舰船，这代表了约 4 万美元的现实货币。现在你就能理解为什么我们最大的一场战斗成本大约是 38.7 万美元。因为在那场战斗的战场上，大约有 257 艘这样的巨型舰船。这就是我们所理解的真正风险所在。同时，也要理解我们如何让玩家在生态系统中表达自我。比如这个玩家，他带着价值 1000 美元的舰船出现在屏幕顶部，并决定用全粉色来展示自己。你可能还没注意到，但他就在屏幕顶部。最终，当我们回到我们今天要讨论的主题时，问题在于：我们如何区分这些真正重要的东西，比如价值 1000 美元的虚拟网络飞船，与屏幕上突然出现的粉色？我们如何追踪这些差异，又如何管理它们？

头部与尾部基准采样

第一部分讨论的是头部与尾部基准采样。简要来说，我们从一个 20 年的项目进入这个生态系统时做出的决定是，我们不想承担任何额外的维护负担。另一个重要因素是之前提到的能力限制。再次强调，我们只能在单个逻辑处理器上运行 Python。我甚至无法快速提取出足够的跨度数据来进行尾部基准采样，否则会严重影响模拟的其他部分。虽然我们有办法投资和优化这一点，但当时这并不在考虑范围内。因此，我们更倾向于使用头部基准采样，而非尾部基准采样。这也引导我们走上了以简单性替代复杂性的有趣道路。当我们这样做时，我们也考虑到了集中式概念。尾部基准采样有一个集中式元素，即需要将所有跨度数据发送到一个地方。

我对这种集中式方法的偏见是，我不喜欢在生态系统的大块区域中失去可见性。我们并没有这样做。我们甚至现在都没有一个用于发出跨度数据的中继。这带来的好处是，当系统开始退化时，我们可以推断出哪些系统部分出现了退化，因为只有那些无法到达例如 Honeycomb 的部分才会出现问题。

然后我们进一步研究了确定性采样与动态采样的对比。同样出于性能考虑，在已经存在这套经过20年精细调优的机器系统（它正在模拟整个宇宙）的生态系统中，我们实际上无法开始对需要更动态采样的事物进行干预。我们被迫在这一方面采用确定性采样。而更新的系统则会部署在Quasar中，这种情况下我们将能够实现更动态的采样。当我们开始思考如果桌面客户端也能像服务端一样发出追踪跨度（span）时，这种设计变得特别有用。我们能够从客户端获取大量性能数据并进行分析。但同样的问题再次出现：桌面客户端本身也是一个经过精细调优的单体系统，我们也不希望对其造成影响。这又是一个推动我们转向头部采样（head base sampling）的重要因素。

指数移动平均（EMA）采样

接下来我们进入了指数移动平均（EMA）采样的领域。这是我们在Quasar中追踪大多数新系统时采用的核心方法。简单来说，EMA采样的原理是：你选择一个需要追踪的关键字段。对我们而言，这个关键字段变成了我们在系统各处传递的protobuf消息的类型URL。这个字段就成为了我们的键（key）。有趣的是，这个键会形成一个键空间（key space），稍后这将变得非常重要。随着系统演进和生态扩展，你不断向这个生态系统添加更多内容，键空间也会随之增长。这是你在追踪实际会发出多少信息（以跨度形式）时需要考虑的关键因素之一。EMA的另一个特性是，它会动态观察这个键空间，并追踪每个键出现的次数。

EMA算法自带一个非常巧妙的有机特性：看到某物越多，采样频率就越低；看到某物越少，采样频率就越高。这非常好，因为它解决了我们最初遇到的大部分问题——我们不需要关注500人不断切换飞船皮肤，或者子弹在生态系统中持续飞舞的情况。EMA会自动降低对这些高频事件的采样率。但随之而来的新问题是：如果子弹不是从新系统而是从旧系统发射，那么我们就必须在这一方面采用确定性采样。EMA采样的另一个特点在于其完全不依赖协调机制，这意味着与尾部采样（tail base sampling）不同，它不会将所有数据汇聚到一个中心点。而针对EMA采样（特别是头部EMA采样），我们关注的是进入生态系统的不同实例。

然后你有这三个关键组件：消息频率、键空间以及该生态系统运行的实例数量。当你将这些因素综合起来时，会出现一个有趣的现象，即数据会出现分层现象，并产生一个逐渐上升的高水位线。我所说的高水位线是指当我们进行横向扩展时，这个图表中我加入了一些数字来说明这一点。以《EVE Online》中的Quasar部分为例，大约有30,000条消息。键空间的大小可能在2,000条消息左右。我们有35个实例用于进入该生态系统。当你将这些数字综合起来时，会出现一个有趣的现象。对我们来说，每天平均处理约6000万事件，这非常不错。从宏观角度来看，这是一个划算的数字。

这使我们能够保持在熟悉的领域内，了解正在发生的事情。它也让我们知道，如果需要在这些实例中进行扩展，我们必须警惕下一个高水位线的位置，因为这将是我们无法再降低的区域。我所说的“无法再降低”是指，无论我的频率如何变化，或者我如何控制采样目标。EMA也有一个采样目标。采样目标基本上是指，对于单个实例来说，它试图达到的目标是什么？如果它的目标是每3000条消息采样1条，它会根据其键空间、频率以及自身的实例来尝试实现这个目标。如果我试图在整个系统中将采样目标统一为每3000条消息采样1条，由于我们有30到35个实例，以及现有的频率和键空间，每个实例的采样目标为每3000条消息采样1条，这实际上会阻止系统每天的处理量低于约6000万。

因为EMA总会采样某些内容，且永远不会遗漏任何东西。你总是能看到至少每种类型的一个实例，这也是一个好事，我们稍后会再讨论这一点。当谈到键空间时，我也尝试从另一个角度来分析这个问题。当键空间增长时，在分布式机制中EMA会出现许多奇怪的现象。从这个角度来看，这变得非常有趣，因为这要求你的团队在生态系统中非常快速地生成数百种新的消息类型，而以人类的速度，这并不一定会发生。但以AI的速度，这可能在将来成为一个问题。我们会发现这一点。

所有这些因素与我们之前讨论的混合配置相结合，使EMA在我们进行动态采样时非常有用，同时也能使用确定性采样。使用确定性采样以及动态采样时，最重要的部分之一是拥有能够向你展示采样率的工具，并且能够推断这些数字可能意味着什么。这是来自我们模拟帧的样本截图。我们的模拟引擎是一个确定性锁步模拟引擎，我们称之为Destiny。有趣的是，它的其他部分还以其他Destiny Child成员的名字命名。这也是另一个话题。由于在模拟帧中发生了大量事情，系统中也发生了大量事情，我们必须对这些进行确定性采样。首先，出于性能考虑。我们不希望在这里出现性能问题。

其次，它们的数量实在太多，我们无法一一关注。在图表底部，你可以看到我们设置的各种采样率，这些采样率用于确定性地采集模拟状态中发生的机制数据。更重要的是图表右上角部分，Honeycomb会利用这些采样率和采样频率进行外推分析。我们经常使用这种方法。我认为即使在这样的采样率和稀疏数据下，结果通常也能控制在目标值±300单位范围内。当你处理具有统计显著性的信息时，这种方法实际上非常可靠。

特性标志

我们使用的另一个技巧是滥用特性标志。以Hot Rod杂货店为例，我们使用LaunchDarkly将大量JSON数据注入到各个地方。在这里我们采用了一种前缀机制，它允许我们表达两种不同的概念。一种是表示"我想了解这个消息的更多信息"，另一种是"我想让这个领域更加安静，因为这对我们的核心业务重要性较低"。如果你看最后一行，这显然是我们不太关心的领域。它最终会涉及窗口状态的变化，包括聚焦、打开、关闭、失焦等，当用户拖动窗口时还会触发各种操作。我们关心这些状态变化的发生，但并不需要关注每一个实例。再次强调，这些数据在统计学上具有显著性。从客户端视角来看，1000个请求中出现一次的频率确实很低。

但从30000个客户端同时进行1000分之一采样的角度来看，数据密度就会显著提升。我们生态系统中还有其他更频繁发生的事件，例如任何类型的资源采集行为，无论是激光采集、无人机采集还是气体采集。在《EVE Online》中存在一个完整的矿物和工业生态系统。我们经常利用这些特性标志来精准控制数据采集的范围和时机。我认为这也是我们工作的重要组成部分。通过这些工具，我们还具备一种机制，可以分析特定飞船或特定角色的活动情况。当我们启用这些功能时，配额图表就会呈现出这样的形态，你可以在右侧看到两个明显的峰值。当我解读这个图表时，它显示的含义是：有人正在高度关注宇宙中某个特定事件的发生。这些图表集中体现了我们所有工具的集合，展示了我们在性能优化、遗留系统处理、新生态系统演进等方面的努力成果，以及这些不同组件如何协同工作。

总结

然后，最终我想总结一些要点，并重申我们之前讨论过的一些内容。高水位线非常重要，因为它能帮助你在了解高水位线输出结果的情况下管理成本。这是来自一个存在了很长时间的网站EVE Offline的截图。该网站有一个很好的图表，显示了在特定时刻有多少玩家正在玩EVE Online。如你所见，EVE Online拥有一个非常稳定的玩家群体，有些人称之为奢侈，这取决于你和谁交谈，但我们的玩家数量会在3万到4万之间波动，这取决于我们是否发布了扩展包，以及玩家们对新内容的兴奋程度。最终，我们不需要担心出现巨大的流量高峰。高水位线的重要性与我们产品的行为密切相关。

这使我们能够规划支出金额、确定目标范围以及收集更详细的信息。我们还采用了一种针对90%配额利用率的策略。如果你也关注这一点，可以看到我们每天大约达到5000万的使用量。这使我们能够在需要时开启“索伦之眼”而无需担心产生巨额超额费用。我们还利用Honeycomb拥有很多实用功能，例如突发流量保护等。将这些技术整合在一起的另一个重要原因是我们希望确保至少具备每种能力。再次强调，我们希望知道宇宙中某个地方是否发生了某件事。我们确实希望至少知道某件事发生过一次，因为我们可以根据采样率或其他情况推断出系统的健康状况。我们还可以区分哪些是实际调试信息，哪些只是噪声。再次强调，我们关注的是识别统计显著性事件，而不是那些需要持续跟踪的宇宙事实。

这只是关于调度标志的详细说明。有时我们会忘记关闭“索伦之眼”，然后就会收到一条友好的自动消息提示：“你刚刚花了很多钱。”确保每个人在处理此类问题时都将此事项加入检查清单。接着我们讨论了公共应用程序监控的潜在影响。我们之前简单提到了桌面客户端本身，也在我们的启动器中对此进行了分析。从纯粹技术角度来看，我们很可能会完全停止这种做法。因为最终，这些系统会导致我们在追踪早期阶段就做出采样决策，从而影响我们能够看到的内容。视频游戏的很多方面都与玩家的交互有关。如果玩家执行了非常重要的操作，例如锚定空间站，由于这些操作的采样率是1/1000，且来自客户端，我们可能看不到那么多相关数据，因为我们的工具无法提升采样率，以免影响这些系统的实际性能。

我们希望将这一决策过程从客户端本身转移到一个可信网络中，当请求进入我们的网络生态系统时，再在该网络中启动决策和采样流程。这是我们在实践中逐渐学到的经验。这种方法让我们对延迟有了有趣的洞察，但你也可以通过其他方式获得这些信息。你不需要通过30,000个不同客户端的追踪数据来获取这些信息。从某种意义上说，你需要对指标进行更充分的平均处理。这种方法还有一个有趣的副作用，涉及到优化SLO精度。当你开始构建SLO时，对于短期SLO来说，你基本上需要测量错误预算，这意味着你需要区分成功事件和失败事件的数量。这种方法在头部采样中表现得非常好，因为你无法选择成功和失败事件的数量及其比例，而在尾部采样中，你可以调整这个比例并更深入地理解它。

我们无法这样做，因为我们使用的是头部采样。同时，我们还需要谨慎处理SLO对统计显著事件的敏感性，以及是否应该为这些统计显著事件设置SLO。例如，如果我们对UI交互使用头部确定性采样，采样率是1/1000，并且为这个交互设置了SLO，这将带来问题，因为我们每几小时就会看到一次这样的事件。如果在这个事件中出现错误，由于SLO的构建方式，这将立即消耗预算，因为我们无法像尾部采样那样控制这些比例。

综合所有要素

最终，为了将所有这些要素整合在一起，我们使用了确定性采样、EMA（指数移动平均）、头部采样和定向时间采样等多种方法，就像我们开启或关闭的“索伦之眼”一样，根据实际需要关注的重点，进入我们期望的“至少捕获所有事件”的状态。这种方法总体上运行得非常好。我们也遇到过一些情况，这些情况在尾部采样中会非常理想，但仅凭这些还不足以让我们投入大量基础设施来连接所有这些组件，解决性能挑战，并真正获得尾部采样的优势，至少从我们的投资回报率角度来看，这些系统可能并不值得。

问答环节

参与者1：我在《海贼王》项目中工作，我们之前尝试过类似设置，但遇到了非常现实的成本效益问题，因为虚幻引擎在日志方面会产生大量热量。你们是否发现，对于这样的系统，如何在更高层次上管理成本效益？

Nicholas Herring：从更高层次来看，这涉及到我们引入Quasar和各种现代技术的阶段。我最初看到的最大问题在于，当我们最初设计该生态系统时，我们关注的是消息总线生态系统与服务网格生态系统之间的差异。最终，这取决于我们组织的成熟度判断，我们当时尚未达到能够真正利用服务网格来满足需求的阶段。需要记住的是，我们是在Kube 1.0版本之前就采用了它。这已经过去很久了。我之所以提到这点，是因为最终我们意识到，无论选择什么方案，都需要某种方式来追踪所有这些组件，并确保这个新生态系统的成功，从而逐步推进迁移工作。

这一点在我们进行初步测试时变得非常现实。当时我们在一个星系中设置了500艘海盗船，并将一艘飞船放在正中央，然后引爆了一枚智能炸弹。智能炸弹会以辐射模式爆炸，而不会影响到引爆者。接着我们观察了它如何击中其他500艘飞船，最终得到了包含35000个追踪点的数据。而且这还处于人工智能应用之前。当我看到这些数据时，意识到我们正在发现一些之前完全不了解的系统信息。我能够向人们展示这些发现，并证明我们必须拥有这样的工具。这非常重要，因为它也帮助我们深入分析旧系统，对其进行解构和分解，理解它们在开启这些机制时的实际运作方式。随后，我们进入了一场猫鼠游戏，试图弄清楚哪些是关键因素，以及如何真正与它们协作。

我们还做过一些有趣的事情，例如为客户端的每一帧都生成追踪点，这在面对30000个GPU同时发出请求时显然不是一个好主意。我们确实在这个过程中遇到了一些问题。但总体而言，这体现了可观测性机制本身的成本与收益。我们清楚地知道要实现这一点需要付出什么代价，但这也带来了巨大的回报。目前，我们组织中的每一位工程师都无法想象没有这种工具的世界。他们不禁会问：我们以前是怎么完成工作的？我认为，推广这一概念并展示它能带来的价值是至关重要的。我认为这是很长时间以来我们第一次能够深入了解这个古老系统的过去。我最好的解释方式是，科幻作品中总有一个老套的桥段：一种无人理解的古老技术。我曾经非常讨厌这个科幻桥段。但当我开始在CCP工作后，我突然意识到，这其实非常合理。

参与者2：你们如何决定追踪的粒度？因为在谈到模拟等话题时，感觉你们宇宙的一次“心跳”可能涵盖大量内容。是否存在一种统一的方式来表示这种粒度？因为当追踪变得非常庞大时，导航会变得非常困难。如果追踪包含大量信息，而你们又对其进行抽样，就会丢失大量信息，这与较小的追踪相比显然存在劣势。对此你们有什么看法？

Nicholas Herring：我们最初学到的一件事是，当我们讨论如何重新发现这个旧系统的工作原理时，EVE Online中存在一个赏金系统，它并不像你想象的那样。最终当你摧毁一艘NPC飞船时，它们身上会有赏金，但这个赏金不会立即发放。我们某个地方有一个协程，每五分钟就会执行一次，用来发放所有赏金。当我们开启可观测性机制时，很快就发现了这个问题。因为突然之间，就像宇宙的会计出现了，开始给所有人发放赏金。我们随后需要针对特定情况做优化。我们意识到，系统中存在一个已知的模式，即工作者机制。我们通过短路处理绕过这些机制，使追踪不会从根节点开始。我们总是将这些拆分，以便以不同的方式进行采样。

我们还采用了其他一些技巧。因为刚才提到的内容让我联想到其他一些事情。当我们谈论向客户端发送通知时，实际上不会追踪这些通知的传输过程，因为它们是尽力而为的。如果送达了就送达了，如果没送达，我们会再发送一次。这没有问题。我们实际上不会追踪这些通知。这大大减少了我们的配额限制。我们采取的另一个技巧是将请求-响应整合到一个跨度中。我们实际上根据请求和响应机制，将属性命名空间一分为二。在Honeycomb中查看请求时，一个跨度代表整个往返过程。这使我们的成本降低了一半。这非常棒。我们还有很多类似的小技巧。再次强调，这取决于我们判断什么对我们来说是重要的。我们真正关心的是什么？然后调整系统监控的方式。

Liz Fong-Jones：你的开发人员多久会遇到这种情况：我找不到那个特定的追踪？因为这正是你在采样数据时需要做出的权衡。

Nicholas Herring：我认为这种情况只会在他们忘记开启追踪时发生。在我们的生态系统中，默认情况下，当进行开发时，每个人都有自己的本地太阳系和本地宇宙。当他们使用这些时，我们默认会关闭追踪，因为可能有50个人在运行他们自己的宇宙租户。我们不希望追踪所有这些内容，我们并不关心这些。在一些我们的名称服务器和公共测试服务器上，我们开启了追踪。有些人会开启这些设置，但可能忘记实际启用采样，因为我们默认会关闭这个生态系统中的采样。通常当人们说"这是什么？我看不到"时，我们会说"请开启这个"。然后他们通常就能看到所有发生的事情。EMA中的键空间通常能保证我们至少能获取到其中一个。本地开发版本的频率非常稀疏，通常能捕捉到他们需要的所有内容。

参与者3：我个人对一款叫《星公民》的小游戏比较熟悉。他们非常强调持久性和数据存储。我很好奇，像《EVE Online》或《星公民》这样的游戏，与传统企业相比，在数据存储和消息数量方面的规模感是怎样的？

Nicholas Herring：对于我们的生态系统，我估计我们大概每秒处理约6万条消息，是实时的。就在说话的此刻，我们正在这么做。关于存储，这真的取决于具体情况。EVE的历史非常悠久。最终，我认为我们的生产数据库曾经达到大约17到18TB。不算太大。同时，它针对游戏宇宙中的情况做了高度优化。现在我们越来越多地追踪更多事物。例如，我提到过一个系统，允许玩家为其他玩家创建任务。这个系统会持续记录谁为这些任务做出了贡献以及贡献了多少，因为其中一些是团队项目。然后我们需要为这些任务发放奖励。我们实际持久化存储的数据量正在快速增长。在新系统的设计中，我们做了很多工作，主要是为数据的规模和TTL（生存时间）设置约束，以避免创建无限增长的表，从而导致出现Dynamo账单，这正是我们关注的重点。

更重要的是，我们在入口点系统的很多工作，比如我提到的35个实例，我们称它们为服务网关。它们还会将宇宙中的每一个事实分叉到Azure事件中心。无论数据工程团队是否想要这些数据，我都会发送过去。他们有一个数据湖，正被所有这些细节填满。随着他们逐步构建起这个枢纽，他们会从中提取并处理部分信息。例如，当我们实际部署飞船皮肤生态系统时，我立刻有一位数据工程师来到我桌前，问我们发送了什么数据？因为为了让这个系统运行，我们需要让Quasar了解宇宙中每艘飞船在模拟帧的每个时间点的位置，这在生态系统中是一个事件。然后他过来表示，他无法处理这些数据。

我说，你不需要处理它，我只需要你把它存到某个地方就行。我认为我们处理的数据规模是适度的，我们更关注的是交互的规模和同时有多少人能同时与同一片空间区域进行交互。我认为这才是EVE真正关注的重点。

查看更多带文字稿的演讲

录制时间：

2026年10月13日

由

• Nicholas Herring

#### 相关赞助商

#### 相关赞助

• 2026年10月29日 东部时间下午1点 从代币到功能：为AI辅助工程构建成本归属架构 演讲人：Martin Reynolds - Harness首席技术官，Barani Mohandoss - Trimble云治理、FinOps与E-工具总监

#### 本内容属于Java主题

##### 相关主题：

• 开发

• 架构与设计

• DevOps

• 运维监控

• WebSphere MQ

• Websphere

• 应用服务器

• Java

• 可观测性

• Web服务器

• 分布式追踪

• 监控

• Web开发

• QCon伦敦2026

• 分布式系统

• IBM

• QCon软件开发大会

• 文字稿

• 实时

• 应用性能管理

• 性能

• 架构

• InfoQ

• 相关编辑

• InfoQ热门文章 与Joy Ebertz探讨AI编程的真正含义 GitHub通过AI辅助重写将Copilot运行时迁移到Rust 一项调查发现AI生成代码会增加调试和失败率并造成理解鸿沟 上下文语言模型：通过自管理上下文提升性能并降低计算成本 最小可行管理者：建立信任、反馈与目标一致 Cloudflare Traces将代理层转换为OpenTelemetry跨度，推出基于流量的定价方案