書籍出版啦~~~~附上鏈接item.jd.com/11734638.html
企業(yè)中集中運維面臨的問題
隨著云計算的發(fā)展笤休，企業(yè)里面有個百來臺主機需要運維其實是很正常的，就更別說某些大型的企業(yè)里面钻洒，隨便一個省的ITC就幾千臺機器了尤慰。好吧，那么問題來了已日，幾千臺機器，要集中化做一次巡檢，集中化做一次漏掃河质，任何一件事情都是非常麻煩的，一臺一臺登上去操作真的不太現(xiàn)實震叙。這個時候有小伙伴可能就會跳出來說掀鹅，你太out啦，這年頭集中化運維大把的工具媒楼，什么Puppet乐尊、Ansible、SaltStack啦划址，隨便一個都是好手叭忧丁！
沒錯夺颤，隨著開源軟件的發(fā)展痢缎，已經(jīng)越來越多這樣的集中化運維軟件可以給我們選擇了，假如我們面對的是互聯(lián)網(wǎng)企業(yè)世澜，那么上面這幾種工具就足夠了独旷。為什么？互聯(lián)網(wǎng)企業(yè)的設(shè)備大多有這樣的兩個特點：
- 設(shè)備類型較為統(tǒng)一寥裂，沒有奇奇怪怪的操作系統(tǒng)
- 設(shè)備是能夠聯(lián)網(wǎng)的嵌洼，就算不能聯(lián)網(wǎng)，自己做個源也是可以的抚恒，反正是自家的設(shè)備
- 但是在傳統(tǒng)企業(yè)中咱台，現(xiàn)狀就和互聯(lián)網(wǎng)企業(yè)的狀況相差甚遠了
設(shè)備類型繁雜，什么操作系統(tǒng)都有俭驮。我從開始搞集中化運維到現(xiàn)在什么HP-UX回溺、AIX、windows2000混萝、Solaris等等遗遵，一堆雜七雜八的系統(tǒng)，簡直就被坑死了逸嘀。
機器是客戶的车要，不能聯(lián)網(wǎng)，不能自己做源崭倘。這點也是很要命的一點翼岁，這就意味著會出現(xiàn)裝軟件的時候超級煩人的依賴問題类垫、編譯問題。
設(shè)備的位置不集中琅坡。需要運維的設(shè)備有些在這個地市悉患，有些在那個地市，程序上了都不敢出問題榆俺。而且因為不能聯(lián)網(wǎng)售躁，升級出問題了都不知道怎么個辦好
現(xiàn)有集中化運維軟件的不足
肯定會有小伙伴說，我們用Puppet茴晋、SaltStack陪捷、Ansible隨便都能集中化運維幾千臺設(shè)備，而且成本低诺擅，好吧市袖，我們來一個一個看這運維三劍客在企業(yè)自動化運維中是怎么被干掉的。烁涌。凌盯。。
Puppet
Puppet是我們最早選擇的一款產(chǎn)品烹玉，畢竟這貨知名度還是挺高的，在公司內(nèi)部實驗的時候效果挺好的阐滩，但是一去到客戶現(xiàn)場就傻眼了二打，根～本～裝～不～上～去～啊５嗬啤＜绦А！這Ruby的環(huán)境要怎么編譯啊装获，裝這個少那個啊有木有Ｈ鹦拧！Ｑㄔァ凡简！Σ(っ °Д °;)っ 于是，我們又挑了下一個精肃，SaltStack
SaltStack
挑來挑去秤涩，這回挑到了SaltStack，本想著Python的應(yīng)該會好裝點司抱，結(jié)果筐眷。。习柠。根～本～裝～不～上～去～霸纫ァＵ掌濉！武翎！一問同事烈炭，他們在有源的情況下還是有兩臺SUSE就是怎么都跑不起來啊：笃怠Ｊ崆臁！又踩坑啦有木有１跋А８嘀础！ Σ( ￣д￣露久；) ８住！毫痕！
Ansible
好吧征峦，既然客戶端這么難裝，搞個不用裝客戶端消请，走SSH的總行了吧栏笆。于是挑了個Ansible，本以為事情告一段落臊泰，結(jié)果發(fā)現(xiàn)蛉加。。缸逃。针饥。我們的運維對象里面還有Windows。需频。丁眼。好大的一波Windows啊，Windows下配置SSH那個麻煩啊昭殉，總不能跑到地市讓別人一個一個的配置吧苞七。。饲化。莽鸭。 Σ( ° △ °|||)︴
從頭寫一個容器？
踩過了那么多的坑之后吃靠，我的第一個想法是硫眨，我需要一個跨平臺的語言來解決操作系統(tǒng)多樣性的問題，雖然不想用Java，但是翻遍了所有語言礁阁，就只有Java能用巧号。第二個想法是，我需要一個容器姥闭，這個容器就只是負(fù)責(zé)管控其他Java包的運行丹鸿，做到熱部署的效果，來解決客戶端更新的問題棚品，于是靠欢，就出現(xiàn)了這樣一張圖。铜跑。门怪。。
好吧锅纺，就按照這個思路設(shè)計去掷空，寫完之后心情大好，這回總把集中化運維的問題解決了吧,通訊的問題簡單啦囤锉，大把的開源庫坦弟，什么Mina啊，Netty啊官地，不行的話酿傍，自己寫Socket也行的嘛。結(jié)果當(dāng)天我剛好開著虛擬機驱入，這貨不知道怎么回事在熱部署的時候把我的虛擬機給干掉了拧粪。。(/= _ =)/~┴┴ 這個時候有個大忽悠突然和我說”O(jiān)SGI有沒試過沧侥，它應(yīng)該能解決你的問題“
OSGI+MQ
后來試了下比較流行OSGI容器，發(fā)現(xiàn)效果和我想要的不一樣魄鸦，然后又陸續(xù)多很多容器都做了實驗宴杀，終于找到我想要的那個容器～～那個艱辛。拾因。旺罢。容器的問題解決了，這回抱著能少寫代碼就少寫代碼的心绢记，找了一款合適的MQ中間件扁达，解決了二級代理和通訊的問題，于是整體架構(gòu)就長這樣啦～～～
假如了解SaltStack架構(gòu)的小伙伴肯定會說蠢熄，切跪解，不就是抄襲了SaltStack的架構(gòu)嘛。假如是做過監(jiān)控軟件的小伙伴肯定也會說签孔，切叉讥，我們監(jiān)控軟件都走的MQ的啦窘行。架構(gòu)這種東西嘛，大同小異图仓，不同的架構(gòu)為了解決的問題是不一樣的罐盔，而OSGI+MQ的這個架構(gòu)主要是為了解決上面的的問題而設(shè)計的
- 解決集中化運維過程中操作系統(tǒng)的多樣性問題
- 解決集中化運維過程中客戶端集中更新的問題
- 降低開發(fā)的難度（Java程序員一抓一大把救崔，Python惶看、Ruby的可不是那么好找的喲）
- 降低部署難度（終于不用編譯啦！六孵！你能理解碰到連GCC都沒有的機器那種痛苦嘛(╯°Д°)╯︵ ┻━┻ ）
好吧纬黎，這回客戶端都在別人機器上了，想做什么集中化運維的動作都可以啦～～例如干掉根目錄啦狸臣。莹桅。。跑個死循環(huán)之類的了
架構(gòu)的缺點
上面吹了一大通烛亦，一直都沒提這個架構(gòu)的缺點
- 占用內(nèi)存較多：光跑起容器就要120M左右的內(nèi)存诈泼，把插件包什么的算上去會去到160～180M，對內(nèi)存的占有是挺大的煤禽。
- 需要自己開發(fā)插件：不像其他開源軟件一樣铐达，拿來就已經(jīng)有很多現(xiàn)成的插件在上面了，這個架構(gòu)上運維插件可是要自己動手的喲檬果。（唉瓮孙，不過說實在的，這年頭客戶的需求各式各樣选脊，其實那些現(xiàn)成的插件去到實際環(huán)境很多都用不了杭抠，還得自己開發(fā)）
- 需要處理更多的細(xì)節(jié)：整體設(shè)計上，消息的交互恳啥、線程的調(diào)度等等都是要自己處理的偏灿，一旦處理不好，好一點的話要不功能失效钝的，慘一點的話直接就把別人機器搞死了
