hello大家好，我是小樓，今天給大家分享一個(gè)關(guān)于Agent技術(shù)的話題，也是后端啟示錄的第3篇文章。

通過本文你可以了解到如下內(nèi)容：

什么是Agent技術(shù)

為了解釋什么是Agent技術(shù)，我在網(wǎng)上搜了一圈，但沒有找到想要的結(jié)果。反倒是搜到了不少Java Agent技術(shù)，要注意Java Agent技術(shù)指的是一種Java字節(jié)碼修改技術(shù)，和本文要說的完全是兩碼事。

既然搜不到，我就說下自己的理解吧。Agent技術(shù)是在「客戶端」機(jī)器上部署一個(gè)Agent進(jìn)程，「客戶端」與「服務(wù)端」的交互通過這個(gè)Agent進(jìn)行代理，其中Agent與Client通常在同一主機(jī)，即可通過「localhost」進(jìn)行訪問。

看到這里，相信你能想到不少類似的架構(gòu)，例如當(dāng)前大熱的Service Mesh，又如Flume Agent等等。

在我所在的公司，Agent技術(shù)也被非常廣泛的使用，涉及了日志處理、配置下發(fā)、服務(wù)注冊(cè)發(fā)現(xiàn)、監(jiān)控?cái)?shù)據(jù)收集、流量代理等方面。

Agent技術(shù)能解決什么問題

既然Agent技術(shù)被如此廣泛的運(yùn)用，那么它主要是為了解決什么問題呢?

要充分理解它，我們需要從Agent的特點(diǎn)去考慮。

進(jìn)程級(jí)資源隔離

這點(diǎn)可以參考之前我寫的文章《Cobar SQL審計(jì)的設(shè)計(jì)與實(shí)現(xiàn)》，為了在Cobar中新增SQL審計(jì)的功能，第一考慮的是穩(wěn)定性，不想因?yàn)橐肓诵碌慕M件(Kafka)導(dǎo)致Cobar不可用，所以將SQL收集存儲(chǔ)部分獨(dú)立為一個(gè)Agent。

如果將邏輯放在業(yè)務(wù)進(jìn)程中，首先資源(Cpu、內(nèi)存等)消耗不可控，其次也極易有可能引入Bug導(dǎo)致原進(jìn)程崩潰。

語言框架無關(guān)

舉個(gè)日志切割的例子，如果大家都用Java，并用了Log4J日志框架，那么完全可以使用一個(gè)配置來把日志按時(shí)間進(jìn)行切割和保留。

但如果有人使用了一個(gè)小眾的語言，或者用了一個(gè)不具備日志切割能力的日志框架，這時(shí)想擁有Log4J同樣的日志切割能力怎么辦呢?

你可能會(huì)說怎么會(huì)有這樣的日志框架，可能大家用Log4J或Logback這樣的日志框架都太過于強(qiáng)大了，事實(shí)上其他語言真的有這樣的，而且日志框架也有很多輪子，質(zhì)量參差不齊。

不能要求每個(gè)日志框架都具備同等的能力，只能通過一個(gè)Agent進(jìn)程來處理。

看到這里，你可能已經(jīng)發(fā)現(xiàn)這個(gè)Agent已經(jīng)超出文章開頭的定義了，Agent所在的機(jī)器不一定是Client，他們也不一定會(huì)通信，Agent這時(shí)更像一個(gè)「輔助進(jìn)程」。

存算分離

這個(gè)概念在數(shù)據(jù)庫和消息隊(duì)列使用的比較多，這里我借用一下，如果表述不準(zhǔn)確還請(qǐng)見諒。

在沒有Agent之前，服務(wù)端負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)和計(jì)算，在有了Agent后，服務(wù)端的部分計(jì)算可以交給Agent，這樣不僅可以減少服務(wù)端的壓力，也能大幅度降低服務(wù)端代碼的復(fù)雜度。

基礎(chǔ)組件與業(yè)務(wù)解耦

這點(diǎn)用Service Mesh的例子講解恰到好處，對(duì)于流量的治理，比如限流、熔斷、切流，原先實(shí)現(xiàn)在RPC框架，每一次改動(dòng)升級(jí)都需要業(yè)務(wù)方修改依賴升級(jí)并發(fā)布，而使用Agent技術(shù)后，將原先RPC具有的能力下沉到Agent，變更也只需要升級(jí)Agent，業(yè)務(wù)與基礎(chǔ)組件的研發(fā)互不相干，效率得到極大地提升。

為什么大廠偏愛Agent技術(shù)

大廠的特點(diǎn)是人多，人多必然帶來一些效率上的問題，所以大廠在工程效率上的探索往往走的比較靠前，他們會(huì)把基礎(chǔ)架構(gòu)和業(yè)務(wù)研發(fā)分開，大家的邊界很清晰，各司其職。

但這也帶來了很嚴(yán)重的問題，如果基礎(chǔ)組件和業(yè)務(wù)耦合比較嚴(yán)重，那就導(dǎo)致架構(gòu)的演進(jìn)受到阻礙。

舉個(gè)例子，某一天基礎(chǔ)架構(gòu)部新增了一個(gè)維度的限流能力，升級(jí)推廣需要業(yè)務(wù)方操作，這時(shí)剛好業(yè)務(wù)緊急，那基礎(chǔ)組件的升級(jí)勢必會(huì)擱置。

于是基礎(chǔ)組件與業(yè)務(wù)解耦的Agent技術(shù)受到大廠的偏愛。

大廠同樣有個(gè)問題是技術(shù)棧眾多，有時(shí)候?yàn)榱丝缯Z言、跨框架地解決問題，只能采用Agent技術(shù)。

Agent關(guān)鍵技術(shù)和缺點(diǎn)

Agent關(guān)鍵技術(shù)有很多，看起來不難，但要做好，確實(shí)得下很多功夫：

• 資源隔離，這點(diǎn)通常使用cgroups技術(shù)
• Agent生命周期管理，包括Agent的上線、升級(jí)、灰度、下線等等的管理，需要有統(tǒng)一的管控平臺(tái)，否則Agent的管理將會(huì)非常頭疼
• 進(jìn)程間通信，這點(diǎn)不是必須，但大多數(shù)Agent需要考慮這點(diǎn)，一般有如下可選，結(jié)合實(shí)際情況進(jìn)行選擇即可

• 穩(wěn)定性，Agent隨時(shí)會(huì)掛，要帶著這個(gè)去設(shè)計(jì)實(shí)現(xiàn)Agent，最好是Agent可降級(jí)，就算沒有Agent，業(yè)務(wù)也可以照樣跑起來
• 資源消耗問題

• Agent畢竟只是個(gè)附屬品，不能占用過多的內(nèi)存、CPU，啟動(dòng)速度也得快，從這點(diǎn)來看Go是個(gè)不錯(cuò)的選擇
• 在容器的環(huán)境下，Agent獨(dú)立為一個(gè)容器和業(yè)務(wù)容器組成Pod，這就導(dǎo)致了一臺(tái)物理機(jī)上裝了很多Agent容器，資源浪費(fèi)嚴(yán)重，同理，虛擬機(jī)也是如此。所以省資源的玩法是一臺(tái)物理機(jī)只裝一個(gè)Agent，做好租戶隔離

技術(shù)沒有銀彈，Agent也有它的缺點(diǎn)：

架構(gòu)復(fù)雜，管理困難使多小廠望而卻步

性能問題，如果是直接代理流量，性能問題會(huì)很嚴(yán)重，畢竟在網(wǎng)絡(luò)通信上多了一跳，這也是Service Mesh的問題之一，甚至還演進(jìn)出了proxyless Mesh

最后說一句

雖然看完本文你也不知道怎么實(shí)現(xiàn)一個(gè)Agent，但通過本文你能了解到Agent技術(shù)是什么，有什么好處，大廠為什么偏愛這項(xiàng)技術(shù)，以及要實(shí)現(xiàn)一個(gè)Agent的技術(shù)關(guān)鍵點(diǎn)和缺點(diǎn)各是什么。