Datadog如何将其Agent Go二进制文件的大小减少77%

进入2026年，信息技术的不断发展，好多东西修改变了人们工作习惯，编码不断完善修正，行业的变革越来越多。

在5年的时间里，Datadog代理从428 MiB增长到1.22 GiB，Datadog工程师们开始努力减少其二进制文件的大小。他们发现大多数Go二进制文件的膨胀来自于隐藏的依赖项、禁用的链接器优化以及Go编译器和链接器中的微妙行为。

这种增长影响了我们和我们的用户：网络成本和资源使用增加，人们对代理的看法恶化，并且在资源受限的平台上使用代理变得更加困难。

为了解决这个问题，Datadog 软件工程师 Pierre Gimalac 撰道，他们的方法包括审计导入、隔离可选代码以及消除反射/插件陷阱，以尽可能缩小二进制文件。

事实上，经过分析Agent的增长情况，Datadog的工程师们发现其增长是由新功能、额外的集成和大型第三方依赖（例如Kubernetes SDKs）推动的。特别是，Go的依赖模型包括传递性导入，这使得即使一个小的更改也能引入数百个包。

Datadog工程师们提出了两种实用的方法来移除不必要的依赖：使用构建标签(//go:build feature_x)来排除可选代码，并将代码移动到单独的包中，以便非可选包保持尽可能小。两种技术都需要系统地审计导入项，以确定哪些文件或包可以从给定的构建中排除。例如，将一个函数移动到自己的包中，从不使用它的二进制文件中移除了约570个包和约36 MB的生成代码。

审计依赖项不是一件容易的事，但Go生态系统提供了三个有用的工具来帮助：go list，它列出了构建中使用的所有包；goda，它可视化依赖关系图和导入链，以帮助理解为什么需要某个依赖项；和go-size-analyzer，它显示每个依赖项为二进制文件贡献了多少空间。

除了依赖优化，Datadog 工程师通过减少反射的使用，将代码大小进一步减少了 20%，反射可能会悄无声息地禁用一些链接器优化，包括消除死代码：

如果你使用非常量的方法名，链接器在构建时将无法知道在运行时将使用哪些方法。因此，它需要保留每个可到达类型的所有导出方法及其所有依赖的符号，这可能会大幅增加最终二进制文件的大小。

为了解决这个问题，他们在代码库和依赖项中尽可能消除了动态反射。这一步需要向kubernetes/kubernetes、uber-go/dig、google/go-cmp等项目提交多个 PR。

另一个禁用死代码消除的特性是Go插件，这是一种允许Go程序在运行时动态加载Go代码的机制。事实上，仅仅导入plugin包就会使链接器将二进制文件视为动态链接，“这禁用了方法的死代码消除，并且迫使链接器保留所有未导出的方法”。这个变化在某些构建中又额外减少了约20%。

最后，Gimalac 强调，这些改进是在六个月的时间内完成的，并且最重要的是，不需要移除任何功能。他的账户包含更多无法在此涵盖的细节，因此请务必阅读以了解整个故事。

软件工程师的努力，会不是最后优化的自己，是否可以有一个共存的方法机制呢？