大厂偏爱的 Agent 技术究竟是个啥

搜索关注微信公众号"捉虫大师"，后端技术分享，架构设计、性能优化、源码阅读、问题排查、踩坑实践。

hello 大家好，我是小楼，今天给大家分享一个关于 Agent 技术的话题，也是后端启示录的第 3 篇文章。

通过本文你可以了解到如下内容：

什么是 Agent 技术

为了解释什么是 Agent 技术，我在网上搜了一圈，但没有找到想要的结果。反倒是搜到了不少Java Agent技术，要注意Java Agent技术指的是一种 Java 字节码修改技术，和本文要说的完全是两码事。

既然搜不到，我就说下自己的理解吧。Agent 技术是在「客户端」机器上部署一个 Agent 进程，「客户端」与「服务端」的交互通过这个 Agent 进行代理，其中 Agent 与 Client 通常在同一主机，即可通过「localhost」进行访问。

看到这里，相信你能想到不少类似的架构，例如当前大热的 Service Mesh，又如 Flume Agent 等等。

在我所在的公司，Agent 技术也被非常广泛的使用，涉及了日志处理、配置下发、服务注册发现、监控数据收集等方面。

Agent 技术能解决什么问题

既然 Agent 技术被如此广泛的运用，那么它主要是为了解决什么问题呢？

要充分理解它，我们需要从 Agent 的特点去考虑。

1. 进程级资源隔离

这点可以参考之前我写的文章《Cobar SQL审计的设计与实现》，为了在 Cobar 中新增 SQL 审计的功能，第一考虑的是稳定性，不想因为引入了新的组件（Kafka）导致 Cobar 不可用，所以将 SQL 收集存储部分独立为一个 Agent。

如果将逻辑放在业务进程中，首先资源（Cpu、内存等）消耗不可控，其次也极易有可能引入 Bug 导致原进程崩溃。

2. 语言框架无关

举个日志切割的例子，如果大家都用 Java，并用了 Log4J 日志框架，那么完全可以使用一个配置来把日志按时间进行切割和保留。

但如果有人使用了一个小众的语言，或者用了一个不具备日志切割能力的日志框架，这时想拥有 Log4J 同样的日志切割能力怎么办呢？

你可能会说怎么会有这样的日志框架，可能大家用 Log4J 或 Logback 这样的日志框架都太过于强大了，事实上其他语言真的有这样的，而且日志框架也有很多轮子，质量参差不齐。

不能要求每个日志框架都具备同等的能力，只能通过一个 Agent 进程来处理。

看到这里，你可能已经发现这个 Agent 已经超出文章开头的定义了，严格来说叫「Sidecar 模式」，但这个词更多的用在 Service Mesh 上，所以本文还是用 Agent 来代替。

3. 存算分离

这个概念在数据库和消息队列使用的比较多，这里我借用一下，如果表述不准确还请见谅。

在没有 Agent 之前，服务端负责数据的存储和计算，在有了 Agent 后，服务端的部分计算可以交给 Agent，这样不仅可以减少服务端的压力，也能大幅度降低服务端代码的复杂度。

4. 基础组件与业务解耦

这点用 Service Mesh 的例子讲解恰到好处，对于流量的治理，比如限流、熔断、切流，原先实现在 RPC 框架，每一次改动升级都需要业务方修改依赖升级并发布，而使用 Agent 技术后，将原先 RPC 具有的能力下沉到 Agent，变更也只需要升级 Agent，业务与基础组件的研发互不相干，效率得到极大地提升。

为什么大厂偏爱 Agent 技术

大厂的特点是人多，人多必然带来一些效率上的问题，所以大厂在工程效率上的探索往往走的比较靠前，他们会把基础架构和业务研发分开，大家的边界很清晰，各司其职。

但这也带来了很严重的问题，如果基础组件和业务耦合比较严重，那就导致架构的演进受到阻碍。

举个例子，某一天基础架构部新增了一个维度的限流能力，升级推广需要业务方操作，这时刚好业务紧急，那基础组件的升级势必会搁置。

于是基础组件与业务解耦的 Agent 技术受到大厂的偏爱。

大厂同样有个问题是技术栈众多，有时候为了跨语言、跨框架地解决问题，只能采用 Agent 技术。

Agent 关键技术和缺点

Agent 关键技术有很多，看起来不难，但要做好，确实得下很多功夫：

• 资源隔离，这点通常使用 cgroups 技术

• Agent 生命周期管理，包括 Agent 的上线、升级、灰度、下线等等的管理，需要有统一的管控平台，否则 Agent 的管理将会非常头疼

• 进程间通信，这点不是必须，但大多数 Agent 需要考虑这点，一般可选项有如下可选，结合实际情况进行选择即可

• 稳定性，Agent 随时会挂，要带着这个去设计实现 Agent

• 资源消耗问题

• Agent 毕竟只是个附属品，不能占用过多的内存、CPU，启动速度也得快，从这点来看 Go 是个不错的选择

• 在容器的环境下，Agent 独立为一个容器和业务容器组成 Pod，这就导致了一台物理机上装了很多 Agent 容器，资源浪费严重，同理，虚拟机也是如此。所以省资源的玩法是一台物理机只装一个 Agent，做好租户隔离即可。

技术没有银弹，Agent 也有它的缺点：

• 架构复杂，管理困难使多小厂望而却步

• 性能问题，如果是直接代理流量，性能问题会很严重，毕竟在网络通信上多了一跳，这也是 Service Mesh 的问题之一，甚至还演进出了proxyless Mesh
  

最后说一句

虽然看完本文你也不知道怎么实现一个 Agent，但通过本文你能了解到 Agent 技术是什么，有什么好处，大厂为什么偏爱这项技术，以及要实现一个 Agent 的技术关键点和缺点各是什么。

这也是后端启示录系列文章的出发点，「为什么」比「怎么做」更重要。如果你也喜欢这类文章，读完有那么一点收获，希望你能帮我点个赞、在看、关注，当然能分享出去就更好了，我会继续加油写这个系列~我们下期再见！

后端启示录系列

• 《Dubbo为什么用Go重写？》
  

• 《服务探活的五种方式》
  

搜索关注微信公众号"捉虫大师"，后端技术分享，架构设计、性能优化、源码阅读、问题排查、踩坑实践。