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

发表于 2年以前 | 总阅读数：425 次

什么是 Agent 技术

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

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

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

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

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

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

进程级资源隔离例如，为了在 Cobar 中新增 SQL 审计的功能，第一考虑的是稳定性。不想因为引入了新的组件（Kafka）导致 Cobar 不可用，所以将 SQL 收集存储部分独立为一个 Agent。

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

语言框架无关

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

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

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

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

看到这里，你可能已经发现这个 Agent 已经超出文章开头的定义了。Agent 所在的机器不一定是 Client，他们也不一定会通信，Agent 这时更像一个「辅助进程」。

存算分离

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

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

基础组件与业务解耦

这点用 Service Mesh 的例子讲解恰到好处。对于流量的治理，比如限流、熔断、切流，原先实现在 RPC 框架，每一次改动升级都需要业务方修改依赖升级并发布。

而使用 Agent 技术后，将原先 RPC 具有的能力下沉到 Agent，变更也只需要升级 Agent，业务与基础组件的研发互不相干，效率得到极大提升。

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

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

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

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

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

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

资源消耗问题

Agent 毕竟只是个附属品，不能占用过多的内存、CPU，启动速度也得快，从这点来看 Go 是个不错的选择。
在容器的环境下，Agen t独立为一个容器和业务容器组成 Pod，这就导致了一台物理机上装了很多 Agent 容器，资源浪费严重。同理，虚拟机也是如此。所以省资源的玩法是一台物理机只装一个 Agent，做好租户隔离。

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