使用OSGI+MQ的方式解决集中化运维问题

企业中集中运维面临的问题

随着云计算的发展，企业里面有个百来台主机需要运维其实是很正常的，就更别说某些大型的企业里面，随便一个省的ITC就几千台机器了。好吧，那么问题来了，几千台机器，要集中化做一次巡检，集中化做一次漏扫，任何一件事情都是非常麻烦的，一台一台登上去操作真的不太现实。这个时候有小伙伴可能就会跳出来说，你太out啦，这年头集中化运维大把的工具，什么Puppet、Ansible、SaltStack啦，随便一个都是好手啊！

没错，随着开源软件的发展，已经越来越多这样的集中化运维软件可以给我们选择了，假如我们面对的是互联网企业，那么上面这几种工具就足够了。为什么？互联网企业的设备大多有这样的两个特点：

设备类型较为统一，没有奇奇怪怪的操作系统

设备是能够联网的，就算不能联网，自己做个源也是可以的，反正是自家的设备

但是在传统企业中，现状就和互联网企业的状况相差甚远了

1. 设备类型繁杂，什么操作系统都有。我从开始搞集中化运维到现在什么HP-UX、AIX、windows2000、Solaris等等，一堆杂七杂八的系统，简直就被坑死了。
2. 机器是客户的，不能联网，不能自己做源。这点也是很要命的一点，这就意味着会出现装软件的时候超级烦人的依赖问题、编译问题。
3. 设备的位置不集中。需要运维的设备有些在这个地市，有些在那个地市，程序上了都不敢出问题。而且因为不能联网，升级出问题了都不知道怎么个办好

现有集中化运维软件的不足

肯定会有小伙伴说，我们用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的这个架构主要是为了解决上面的的问题而设计的

1. 解决集中化运维过程中操作系统的多样性问题
2. 解决集中化运维过程中客户端集中更新的问题
3. 降低开发的难度（Java程序员一抓一大把，Python、Ruby的可不是那么好找的哟）
4. 降低部署难度（终于不用编译啦！！你能理解碰到连GCC都没有的机器那种痛苦嘛(╯°Д°)╯︵ ┻━┻ ）

好吧，这回客户端都在别人机器上了，想做什么集中化运维的动作都可以啦～～例如干掉根目录啦。。。跑个死循环之类的了

架构的缺点

上面吹了一大通，一直都没提这个架构的缺点

1. 占用内存较多：光跑起容器就要120M左右的内存，把插件包什么的算上去会去到160～180M，对内存的占有是挺大的。
2. 需要自己开发插件：不像其他开源软件一样，拿来就已经有很多现成的插件在上面了，这个架构上运维插件可是要自己动手的哟。（唉，不过说实在的，这年头客户的需求各式各样，其实那些现成的插件去到实际环境很多都用不了，还得自己开发）
3. 需要处理更多的细节：整体设计上，消息的交互、线程的调度等等都是要自己处理的，一旦处理不好，好一点的话要不功能失效，惨一点的话直接就把别人机器搞死了