北京
Uber近期公开了一项名为“零增长堆栈”（Zero Growth Stack）的基础设施优化方案。该方案的核心思路是让服务规模的扩展与物理硬件的增长脱钩，这意味着业务量攀升时，公司不必同步扩充服务器等物理资源，反而有可能压缩现有硬件的占用空间。这一转变的背后，是Uber对软件运行时与AI成本进行系统性优化的结果。
传统的基础设施扩容总是跟着业务指标走：订单量涨，机器就得加；用户数翻倍，数据中心规模也要翻番。Uber的技术团队开始审视这套线性增长的逻辑。他们发现，如果能在应用层面更精细地控制资源的消耗节奏，完全有可能用更少的硬件支撑起更大的服务体量。零增长堆栈的策略便是从这一观察出发，把优化目标锁定在自动化运行时调优和严格的AI生命周期管理上。
具体来说，Uber不再依赖静态的、一次性的性能参数设定，而是转向了动态的系统控制。即便内部微服务的数量激增、代码库日趋复杂，基础设施的运行效率也不会被同步拖垮。这种能力背后，是一套可以实时感知负载特征并做出调整的机制，它让机器的每一次CPU周期都花在了真正需要的地方。
这项工程中最具代表性的成果，是一个名为GOGCTunner的工具。Uber的后台服务大量使用Go语言编写，不同服务的内存占用差异悬殊——从100MB到1GB的跨度很常见。这样的多样性意味着，为垃圾回收（GC）设置一个固定的触发阈值往往顾此失彼：对轻量服务来说，阈值过高会导致内存迟迟得不到释放；对重服务而言，阈值过低又会让GC频繁运行，白白吃掉性能。GOGCTunner的目的，就是根据每个服务实际的内存画像，自动调节GOGC这个关键参数。GOGC决定了新分配对象的总量达到上一次垃圾回收后存活对象量的多少百分比时，新一轮GC会被触发。通过让这个百分比动态匹配服务当下的内存使用特征，Uber得以在瞬时的吞吐高峰期和内存缓释期之间，找到一个不断滑移的平衡点。
除了运行时性能的自我调节，零增长堆栈还将AI研发的每一环都纳入了成本管控的视野。Uber在机器学习模型的训练、部署和持续迭代过程中，施加了一套严格的生命周期管理规则。这意味着从实验阶段的算力申请，到模型线上推理的GPU占用，再到模型退役时资源的回收，每一个节点都不会出现无谓的浪费。过去，AI团队为了快速迭代，常常会保留多份冗余的模型副本和训练集群，而这些“僵尸”资源消耗了可观的运维成本。如今，系统会迫使每一份AI相关的开销都与实际业务价值挂钩，确保没有一分算力被空转。
这种强约束的AI治理，与Go运行时的动态调优形成了互补：前者在宏观业务层面抑制了不必要的需求，后者在微观进程层面榨出了现有硬件的极限。最终，二者共同支撑起Uber所追求的“零增长”状态——不是业务不增长，而是支撑业务的物理资源规模可以保持平缓甚至缩减。对于任何一家仍在扩张期的平台型公司，这都提供了一条颇具吸引力的路径：与其去跟硬件厂商抢产能、抢交付周期，不如先问自己的软件栈里还有多少冗余可以被消除。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
