企業中集中運維面臨的問題
隨着雲計算的發展，企業裏面有個百來臺主機需要運維其實是很正常的，就更別說某些大型的企業裏面，隨便一個省的ITC就幾千臺機器了。好吧，那麼問題來了，幾千臺機器，要集中化做一次巡檢，集中化做一次漏掃，任何一件事情都是非常麻煩的，一臺一臺登上去操作真的不太現實。這個時候有小夥伴可能就會跳出來說，你太out啦，這年頭集中化運維大把的工具，什麼Puppet、Ansible、SaltStack啦，隨便一個都是好手啊！
沒錯，隨着開源軟件的發展，已經越來越多這樣的集中化運維軟件可以給我們選擇了，假如我們面對的是互聯網企業，那麼上面這幾種工具就足夠了。爲什麼？互聯網企業的設備大多有這樣的兩個特點：
設備類型較爲統一，沒有奇奇怪怪的操作系統
設備是能夠聯網的，就算不能聯網，自己做個源也是可以的，反正是自家的設備
但是在傳統企業中，現狀就和互聯網企業的狀況相差甚遠了
- 設備類型繁雜，什麼操作系統都有。我從開始搞集中化運維到現在什麼HP-UX、AIX、windows2000、Solaris等等，一堆雜七雜八的系統，簡直就被坑死了。
- 機器是客戶的，不能聯網，不能自己做源。這點也是很要命的一點，這就意味着會出現裝軟件的時候超級煩人的依賴問題、編譯問題。
- 設備的位置不集中。需要運維的設備有些在這個地市，有些在那個地市，程序上了都不敢出問題。而且因爲不能聯網，升級出問題了都不知道怎麼個辦好
現有集中化運維軟件的不足
肯定會有小夥伴說，我們用Puppet、SaltStack、Ansible隨便都能集中化運維幾千臺設備，而且成本低，好吧，我們來一個一個看這運維三劍客在企業自動化運維中是怎麼被幹掉的。。。。
Puppet
Puppet是我們最早選擇的一款產品，畢竟這貨知名度還是挺高的，在公司內部實驗的時候效果挺好的，但是一去到客戶現場就傻眼了，根～本～裝～不～上～去～啊！！！這Ruby的環境要怎麼編譯啊，裝這個少那個啊有木有！！！！Σ(っ °Д °;)っ 於是，我們又挑了下一個，SaltStack
SaltStack
挑來挑去，這回挑到了SaltStack，本想着Python的應該會好裝點，結果。。。根～本～裝～不～上～去～啊！！！一問同事，他們在有源的情況下還是有兩臺SUSE就是怎麼都跑不起來啊！！！又踩坑啦有木有！！！ Σ( ￣д￣；) ！！！
Ansible
好吧，既然客戶端這麼難裝，搞個不用裝客戶端，走SSH的總行了吧。於是挑了個Ansible，本以爲事情告一段落，結果發現。。。。我們的運維對象裏面還有Windows。。。好大的一波Windows啊，Windows下配置SSH那個麻煩啊，總不能跑到地市讓別人一個一個的配置吧。。。。 Σ( ° △ °|||)︴
從頭寫一個容器？
踩過了那麼多的坑之後，我的第一個想法是，我需要一個跨平臺的語言來解決操作系統多樣性的問題，雖然不想用Java，但是翻遍了所有語言，就只有Java能用。第二個想法是，我需要一個容器，這個容器就只是負責管控其他Java包的運行，做到熱部署的效果，來解決客戶端更新的問題，於是，就出現了這樣一張圖。。。。
好吧，就按照這個思路設計去，寫完之後心情大好，這回總把集中化運維的問題解決了吧,通訊的問題簡單啦，大把的開源庫，什麼Mina啊，Netty啊，不行的話，自己寫Socket也行的嘛。結果當天我剛好開着虛擬機，這貨不知道怎麼回事在熱部署的時候把我的虛擬機給幹掉了。。(/= _ =)/~┴┴ 這個時候有個大忽悠突然和我說”OSGI有沒試過，它應該能解決你的問題“
OSGI+MQ
後來試了下比較流行OSGI容器，發現效果和我想要的不一樣，然後又陸續多很多容器都做了實驗，終於找到我想要的那個容器～～那個艱辛。。。容器的問題解決了，這回抱着能少寫代碼就少寫代碼的心，找了一款合適的MQ中間件，解決了二級代理和通訊的問題，於是整體架構就長這樣啦～～～
假如瞭解SaltStack架構的小夥伴肯定會說，切，不就是抄襲了SaltStack的架構嘛。假如是做過監控軟件的小夥伴肯定也會說，切，我們監控軟件都走的MQ的啦。架構這種東西嘛，大同小異，不同的架構爲了解決的問題是不一樣的，而OSGI+MQ的這個架構主要是爲了解決上面的的問題而設計的
- 解決集中化運維過程中操作系統的多樣性問題
- 解決集中化運維過程中客戶端集中更新的問題
- 降低開發的難度（Java程序員一抓一大把，Python、Ruby的可不是那麼好找的喲）
- 降低部署難度（終於不用編譯啦！！你能理解碰到連GCC都沒有的機器那種痛苦嘛(╯°Д°)╯︵ ┻━┻ ）
好吧，這回客戶端都在別人機器上了，想做什麼集中化運維的動作都可以啦～～例如干掉根目錄啦。。。跑個死循環之類的了
架構的缺點
上面吹了一大通，一直都沒提這個架構的缺點
- 佔用內存較多：光跑起容器就要120M左右的內存，把插件包什麼的算上去會去到160～180M，對內存的佔有是挺大的。
- 需要自己開發插件：不像其他開源軟件一樣，拿來就已經有很多現成的插件在上面了，這個架構上運維插件可是要自己動手的喲。（唉，不過說實在的，這年頭客戶的需求各式各樣，其實那些現成的插件去到實際環境很多都用不了，還得自己開發）
- 需要處理更多的細節：整體設計上，消息的交互、線程的調度等等都是要自己處理的，一旦處理不好，好一點的話要不功能失效，慘一點的話直接就把別人機器搞死了