背景
目前項目中會使用了Iaas中的vm，所有操作都是通過ssh連上去的。pm表示要不要寫個agent在里面用，現(xiàn)在每次操作都ssh一下都很惡心。

談?wù)勎艺J為使用ssh的好處：
代碼集中在一處，不需要分發(fā)
不需要維護agent這么一個進程的生命周期，以及檢測它的心跳
缺點：

不支持異步
我想問的問題
ssh的開銷大嗎？在我看來似乎和寫一個基于web server 的agent差不多
大家一般是如何選型的？為什么這么選？

這個東西以前做過類似的，也有過反思，甚至設(shè)計的原型和你說的一模一樣。

例如，我為什么要用基于web server的agent呢，我干嘛不用tcp長連接到服務(wù)端，這樣執(zhí)行的結(jié)果可以流式傳輸?shù)秸{(diào)用方，他那邊顯示起來比較平滑，不用每個命令執(zhí)行完等結(jié)果。
但是我這樣搞的話，中控端流量和日志存儲就成了問題了啊。
如果我的業(yè)務(wù)都在云上，如果不同機房網(wǎng)絡(luò)不互通的話，我又要蛋疼地搞點兼容的事情……
例如，agent的生命周期，為什么我要檢測她的心跳呢？機器上萬臺的話，任何可能的事情都會發(fā)生啊，修復(fù)起來太蛋疼了。但是我不處理的話……所以后面我會考慮用ssh來修復(fù)agent啊。

我假設(shè)你所有的機器都是linux，發(fā)行版為同一種。

SSH：

1. 依賴于ssh的速度，一旦網(wǎng)絡(luò)抖動，ssh操作便會失敗。（低概率/風(fēng)險）
2. 依賴于key，如果你安全策略不夠嚴謹，或者管理比不嚴格的話，那么必然會造成root key的泛濫。（安全風(fēng)險高）
3. 開源技術(shù)很成熟，你很容易就能用幾行python包裝出一個比較完善的腳本，或者寫出一個ansible的配置。（用起來簡單）

AGENT：

1. 依賴于中控端。如果你不打算搞個中控端，那和ssh沒本質(zhì)區(qū)別。
2. 其實和SSH一樣，依賴于網(wǎng)絡(luò)，一旦抖動也會出問題。
3. 保活。如果你的公司稍微大點的話，會有各種亂七八糟的原因能讓你的agent不起作用，甚至被kill。雖然處理起來沒啥問題，但是這個活總得有人來干。（低風(fēng)險）
4. 維護。（成本中等）
5. agent其實可以不用中間代碼，因為一方面工作量比較大，一方面教育成本和學(xué)習(xí)成本也比較高。只是向agent下發(fā)shell腳本、python腳本等也可以完成相同的功能，沒問題的。

大公司有各種審計、安全方面的需求，會把這種事情統(tǒng)一到某個地方，搞個中控端，所有的批量操作必須通過中控端。模式也不一樣，有些用agent，有些用ssh，只有中控端才是必須要有的。

再說的直白點，
你是個小公司，小于30臺機器或者小于50臺機器的話，不建議考慮agent模式。
沒那個需求，投入的成本大而收效低。
基于各種第三方框架包裝一個就好了嘛，嫌麻煩就ansible用起。

• 如果管理的OS都是同一類的，比如Linux，那么用ssh最簡單了。
• 如果還有其他的OS，那SSH可能就不好使了，而agent可以一定程度上屏蔽掉OS之間的差異。比如puppet這類解決方案，實際下發(fā)的操作指令并不是實實在在在機器上執(zhí)行的指令，而是一種中間代碼，由agent將中間代碼翻譯成當前OS實際該執(zhí)行的本地命令。