鑽石舞台

什麼是 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 隨時會掛，要帶着這個去設計實現 Agent，最好是 Agent 可降級。就算沒有 Agent，業務也可以照樣跑起來。

Agent 畢竟只是個附屬品，不能占用過多的內存、CPU，啟動速度也得快，從這點來看 Go 是個不錯的選擇。

在容器的環境下，Agen t獨立為一個容器和業務容器組成 Pod，這就導致了一台物理機上裝了很多 Agent 容器，資源浪費嚴重。同理，虛擬機也是如此。所以省資源的玩法是一台物理機只裝一個 Agent，做好租戶隔離。

雖然看完本文你也不知道怎麼實現一個 Agent，但通過本文你能了解到 Agent 技術是什麼，有什麼好處，大廠為什麼偏愛這項技術，以及要實現一個Agent的技術關鍵點和缺點各是什麼。

- EOF -

看完本文有收穫？請轉發分享給更多人

關注「ImportNew」，提升Java技能

點讚和在看就是最大的支持❤️