搜索關注微信公眾號"捉蟲大師"，后端技術分享，架構設計、性能優化、原始碼閱讀、問題排查、踩坑實踐，
hello大家好，我是小樓，今天給大家分享一個關于Agent技術的話題，也是后端啟示錄的第3篇文章，
通過本文你可以了解到如下內容：
什么是Agent技術
為了解釋什么是Agent技術，我在網上搜了一圈，但沒有找到想要的結果，反倒是搜到了不少Java Agent技術，要注意Java Agent技術指的是一種Java位元組碼修改技術，和本文要說的完全是兩碼事，
既然搜不到，我就說下自己的理解吧，Agent技術是在「客戶端」機器上部署一個Agent行程，「客戶端」與「服務端」的互動通過這個Agent進行代理，其中Agent與Client通常在同一主機，即可通過「localhost」進行訪問，
看到這里，相信你能想到不少類似的架構，例如當前大熱的Service Mesh，又如Flume Agent等等，
在我所在的公司，Agent技術也被非常廣泛的使用，涉及了日志處理、配置下發、服務注冊發現、監控資料收集等方面，
Agent技術能解決什么問題
既然Agent技術被如此廣泛的運用，那么它主要是為了解決什么問題呢？
要充分理解它，我們需要從Agent的特點去考慮，
- 行程級資源隔離
這點可以參考之前我寫的文章《Cobar SQL審計的設計與實作》，為了在Cobar中新增SQL審計的功能，第一考慮的是穩定性，不想因為引入了新的組件（Kafka）導致Cobar不可用，所以將SQL收集存盤部分獨立為一個Agent，
如果將邏輯放在業務行程中，首先資源（Cpu、記憶體等）消耗不可控，其次也極易有可能引入Bug導致原行程崩潰，
- 語言框架無關
舉個日志切割的例子，如果大家都用Java，并用了Log4J日志框架，那么完全可以使用一個配置來把日志按時間進行切割和保留，
但如果有人使用了一個小眾的語言，或者用了一個不具備日志切割能力的日志框架，這時想擁有Log4J同樣的日志切割能力怎么辦呢？
你可能會說怎么會有這樣的日志框架，可能大家用Log4J或Logback這樣的日志框架都太過于強大了，事實上其他語言真的有這樣的，而且日志框架也有很多輪子，質量參差不齊，
不能要求每個日志框架都具備同等的能力，只能通過一個Agent行程來處理，
看到這里，你可能已經發現這個Agent已經超出文章開頭的定義了，嚴格來說叫「Sidecar模式」，但這個詞更多的用在Service Mesh上，所以本文還是用Agent來代替，
- 存算分離
這個概念在資料庫和訊息佇列使用的比較多，這里我借用一下，如果表述不準確還請見諒，
在沒有Agent之前，服務端負責資料的存盤和計算，在有了Agent后，服務端的部分計算可以交給Agent，這樣不僅可以減少服務端的壓力，也能大幅度降低服務端代碼的復雜度，
- 基礎組件與業務解耦
這點用Service Mesh的例子講解恰到好處，對于流量的治理，比如限流、熔斷、切流，原先實作在RPC框架，每一次改動升級都需要業務方修改依賴升級并發布，而使用Agent技術后，將原先RPC具有的能力下沉到Agent，變更也只需要升級Agent，業務與基礎組件的研發互不相干，效率得到極大地提升，
為什么大廠偏愛Agent技術
大廠的特點是人多，人多必然帶來一些效率上的問題，所以大廠在工程效率上的探索往往走的比較靠前，他們會把基礎架構和業務研發分開，大家的邊界很清晰，各司其職，
但這也帶來了很嚴重的問題，如果基礎組件和業務耦合比較嚴重，那就導致架構的演進受到阻礙，
舉個例子，某一天基礎架構部新增了一個維度的限流能力，升級推廣需要業務方操作，這時剛好業務緊急，那基礎組件的升級勢必會擱置，
于是基礎組件與業務解耦的Agent技術受到大廠的偏愛，
大廠同樣有個問題是技術堆疊眾多，有時候為了跨語言、跨框架地解決問題，只能采用Agent技術，
Agent關鍵技術和缺點
Agent關鍵技術有很多，看起來不難，但要做好，確實得下很多功夫：
- 資源隔離，這點通常使用cgroups技術
- Agent生命周期管理，包括Agent的上線、升級、灰度、下線等等的管理，需要有統一的管控平臺，否則Agent的管理將會非常頭疼
- 行程間通信，這點不是必須，但大多數Agent需要考慮這點，一般可選項有如下可選，結合實際情況進行選擇即可
- 穩定性，Agent隨時會掛，要帶著這個去設計實作Agent
- 資源消耗問題
- Agent畢竟只是個附屬品，不能占用過多的記憶體、CPU，啟動速度也得快，從這點來看Go是個不錯的選擇
- 在容器的環境下，Agent獨立為一個容器和業務容器組成Pod，這就導致了一臺物理機上裝了很多Agent容器，資源浪費嚴重，同理，虛擬機也是如此，所以省資源的玩法是一臺物理機只裝一個Agent，做好租戶隔離即可，
技術沒有銀彈，Agent也有它的缺點：
- 架構復雜，管理困難使多小廠望而卻步
- 性能問題，如果是直接代理流量，性能問題會很嚴重，畢竟在網路通信上多了一跳，這也是Service Mesh的問題之一，甚至還演進出了
proxyless Mesh
最后說一句
雖然看完本文你也不知道怎么實作一個Agent，但通過本文你能了解到Agent技術是什么，有什么好處，大廠為什么偏愛這項技術，以及要實作一個Agent的技術關鍵點和缺點各是什么，
這也是后端啟示錄系列文章的出發點，「為什么」比「怎么做」更重要，如果你也喜歡這類文章，讀完有那么一點識訓，希望你能幫我點個贊、在看、關注，當然能分享出去就更好了，我會繼續加油寫這個系列~我們下期再見！
后端啟示錄系列
- 《Dubbo為什么用Go重寫？》
- 《服務探活的五種方式》
搜索關注微信公眾號"捉蟲大師"，后端技術分享，架構設計、性能優化、原始碼閱讀、問題排查、踩坑實踐，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/431443.html
標籤：其他