搜尋關注微信公眾號"捉蟲大師"，後端技術分享，架構設計、效能優化、原始碼閱讀、問題排查、踩坑實踐。
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的技術關鍵點和缺點各是什麼。
這也是後端啟示錄系列文章的出發點，「為什麼」比「怎麼做」更重要。如果你也喜歡這類文章，讀完有那麼一點收穫，希望你能幫我點個贊、在看、關注，當然能分享出去就更好了，我會繼續加油寫這個系列~我們下期再見！
後端啟示錄系列
搜尋關注微信公眾號"捉蟲大師"，後端技術分享，架構設計、效能優化、原始碼閱讀、問題排查、踩坑實踐。