大廠偏愛的 Agent 技術(shù)究竟是個啥？
今天給大家分享一個關(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ù)是在「客戶端」機器上部署一個Agent進程，「客戶端」與「服務(wù)端」的交互通過這個Agent進行代理，其中Agent與Client通常在同一主機，即可通過「localhost」進行訪問。
看到這里，相信你能想到不少類似的架構(gòu)，例如當前大熱的Service Mesh，又如Flume Agent等等。
在我所在的公司，Agent技術(shù)也被非常廣泛的使用，涉及了日志處理、配置下發(fā)、服務(wù)注冊發(fā)現(xiàn)、監(jiān)控數(shù)據(jù)收集、流量代理等方面。
Agent技術(shù)能解決什么問題
既然Agent技術(shù)被如此廣泛的運用，那么它主要是為了解決什么問題呢？
要充分理解它，我們需要從Agent的特點去考慮。
進程級資源隔離
這點可以參考之前我寫的文章《Cobar SQL審計的設(shè)計與實現(xiàn)》，為了在Cobar中新增SQL審計的功能，第一考慮的是穩(wěn)定性，不想因為引入了新的組件（Kafka）導(dǎo)致Cobar不可用，所以將SQL收集存儲部分獨立為一個Agent。
如果將邏輯放在業(yè)務(wù)進程中，首先資源（Cpu、內(nèi)存等）消耗不可控，其次也極易有可能引入Bug導(dǎo)致原進程崩潰。
語言框架無關(guān)
舉個日志切割的例子，如果大家都用Java，并用了Log4J日志框架，那么完全可以使用一個配置來把日志按時間進行切割和保留。
但如果有人使用了一個小眾的語言，或者用了一個不具備日志切割能力的日志框架，這時想擁有Log4J同樣的日志切割能力怎么辦呢？
你可能會說怎么會有這樣的日志框架，可能大家用Log4J或Logback這樣的日志框架都太過于強大了，事實上其他語言真的有這樣的，而且日志框架也有很多輪子，質(zhì)量參差不齊。
不能要求每個日志框架都具備同等的能力，只能通過一個Agent進程來處理。
看到這里，你可能已經(jīng)發(fā)現(xiàn)這個Agent已經(jīng)超出文章開頭的定義了，Agent所在的機器不一定是Client，他們也不一定會通信，Agent這時更像一個「輔助進程」。
存算分離
這個概念在數(shù)據(jù)庫和消息隊列使用的比較多，這里我借用一下，如果表述不準確還請見諒。
在沒有Agent之前，服務(wù)端負責(zé)數(shù)據(jù)的存儲和計算，在有了Agent后，服務(wù)端的部分計算可以交給Agent，這樣不僅可以減少服務(wù)端的壓力，也能大幅度降低服務(wù)端代碼的復(fù)雜度。
基礎(chǔ)組件與業(yè)務(wù)解耦
這點用Service Mesh的例子講解恰到好處，對于流量的治理，比如限流、熔斷、切流，原先實現(xiàn)在RPC框架，每一次改動升級都需要業(yè)務(wù)方修改依賴升級并發(fā)布，而使用Agent技術(shù)后，將原先RPC具有的能力下沉到Agent，變更也只需要升級Agent，業(yè)務(wù)與基礎(chǔ)組件的研發(fā)互不相干，效率得到極大地提升。
為什么大廠偏愛Agent技術(shù)
大廠的特點是人多，人多必然帶來一些效率上的問題，所以大廠在工程效率上的探索往往走的比較靠前，他們會把基礎(chǔ)架構(gòu)和業(yè)務(wù)研發(fā)分開，大家的邊界很清晰，各司其職。
但這也帶來了很嚴重的問題，如果基礎(chǔ)組件和業(yè)務(wù)耦合比較嚴重，那就導(dǎo)致架構(gòu)的演進受到阻礙。
舉個例子，某一天基礎(chǔ)架構(gòu)部新增了一個維度的限流能力，升級推廣需要業(yè)務(wù)方操作，這時剛好業(yè)務(wù)緊急，那基礎(chǔ)組件的升級勢必會擱置。
于是基礎(chǔ)組件與業(yè)務(wù)解耦的Agent技術(shù)受到大廠的偏愛。
大廠同樣有個問題是技術(shù)棧眾多，有時候為了跨語言、跨框架地解決問題，只能采用Agent技術(shù)。
Agent關(guān)鍵技術(shù)和缺點
Agent關(guān)鍵技術(shù)有很多，看起來不難，但要做好，確實得下很多功夫：
資源隔離，這點通常使用cgroups技術(shù) Agent生命周期管理，包括Agent的上線、升級、灰度、下線等等的管理，需要有統(tǒng)一的管控平臺，否則Agent的管理將會非常頭疼 進程間通信，這點不是必須，但大多數(shù)Agent需要考慮這點，一般有如下可選，結(jié)合實際情況進行選擇即可
穩(wěn)定性，Agent隨時會掛，要帶著這個去設(shè)計實現(xiàn)Agent，最好是Agent可降級，就算沒有Agent，業(yè)務(wù)也可以照樣跑起來 資源消耗問題 Agent畢竟只是個附屬品，不能占用過多的內(nèi)存、CPU，啟動速度也得快，從這點來看Go是個不錯的選擇 在容器的環(huán)境下，Agent獨立為一個容器和業(yè)務(wù)容器組成Pod，這就導(dǎo)致了一臺物理機上裝了很多Agent容器，資源浪費嚴重，同理，虛擬機也是如此。所以省資源的玩法是一臺物理機只裝一個Agent，做好租戶隔離
技術(shù)沒有銀彈，Agent也有它的缺點：
架構(gòu)復(fù)雜，管理困難使多小廠望而卻步 性能問題，如果是直接代理流量，性能問題會很嚴重，畢竟在網(wǎng)絡(luò)通信上多了一跳，這也是Service Mesh的問題之一，甚至還演進出了 proxyless Mesh
最后說一句
雖然看完本文你也不知道怎么實現(xiàn)一個Agent，但通過本文你能了解到Agent技術(shù)是什么，有什么好處，大廠為什么偏愛這項技術(shù)，以及要實現(xiàn)一個Agent的技術(shù)關(guān)鍵點和缺點各是什么。
這也是后端啟示錄系列文章的出發(fā)點，「為什么」比「怎么做」更重要。如果你也喜歡這類文章，讀完有那么一點收獲，希望你能幫我點個贊、在看、關(guān)注，當然能分享出去就更好了，我會繼續(xù)加油寫這個系列~我們下期再見！