3月3日《大厂偏爱的 Agent 技术究竟是个啥》

Agent 技术的简单介绍

什么是 Agent 技术

Agent 技术是在「客户端」机器上部署一个 Agent 进程，「客户端」与「服务端」的交互通过这个 Agent 进行代理，其中 Agent 与 Client 通常在同一主机，即可通过「localhost」进行访问。

那简单点理解：Agent 其实就是客户端代理技术。客户端不直接与服务端通信，而是通过一个代理节点，间接的与服务端通信。

Agent 技术的架构有：Service Mesh，又如 Flume Agent 等等。

简单点说，==Service Mesh 是微服务时代的 TCP/IP 协议==。具体的就需要设计到比较复杂的知识了，需要重新看文章。

Flume Agent 是开源日志系统。是一个分布式、可靠性和高可用的海量日志聚合系统。也比较复杂。

这两个系统有时间可以看一下。

Agent 特点

进程级资源隔离
语言框架无关

当各个项目的开发语言不一致，同时又希望有些功能能统一管理。这时就可以使用 Agent。

这时 Agent 已经超出文章开头的定义了，严格来说叫「Sidecar 模式」，但这个词更多的用在 Service Mesh 上，所以本文还是用 Agent 来代替。
存算分离

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

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

所以要真正理解 Agent 技术，还是得看项目或者框架代码。这里只会有一个简单的介绍。

大厂偏爱 Agent 技术的原因

大厂的特点是人多，人多必然带来一些效率上的问题，所以大厂在工程效率上的探索往往走的比较靠前，他们会把基础架构和业务研发分开，大家的边界很清晰，各司其职。
大厂还有个问题是技术栈众多，有时候为了跨语言、跨框架地解决问题，只能采用 Agent 技术。

Agent 关键技术和缺点

资源隔离，这点通常使用 cgroups 技术
Agent 生命周期管理，包括 Agent 的上线、升级、灰度、下线等等的管理，需要有统一的管控平台，否则 Agent 的管理将会非常头疼。

是不是类似于 nas 中对于docker的管理一样，我感觉图形化界面更方便一些。
进程间通信，这点不是必须，但大多数 Agent 需要考虑这点，例如，linux 中进程间通信方式：无名管道、命名管道、共享内存、信号量等等。
稳定性，Agent 随时会挂，需要把这种情况要在设计中就考虑进去。
资源消耗问题
- Agent 毕竟只是个附属品，不能占用过多的内存、CPU，启动速度也得快。

Agent 也有它的缺点：

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

ke小厂也不太需要这么复杂的技术吧。
性能问题，如果是直接代理流量，性能问题会很严重，毕竟在网络通信上多了一跳，这也是 Service Mesh 的问题之一，甚至还演进出了proxyless Mesh

EDN