运维

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

2016-12-17  本文已影响68人  小埋酱

书籍出版啦~~~~附上链接item.jd.com/11734638.html

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

随着云计算的发展，企业里面有个百来台主机需要运维其实是很正常的，就更别说某些大型的企业里面，随便一个省的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包的运行，做到热部署的效果，来解决客户端更新的问题，于是，就出现了这样一张图。。。。

Paste_Image.png

好吧，就按照这个思路设计去，写完之后心情大好，这回总把集中化运维的问题解决了吧,通讯的问题简单啦，大把的开源库，什么Mina啊，Netty啊，不行的话，自己写Socket也行的嘛。结果当天我刚好开着虚拟机，这货不知道怎么回事在热部署的时候把我的虚拟机给干掉了。。(/= _ =)/~┴┴ 这个时候有个大忽悠突然和我说”OSGI有没试过，它应该能解决你的问题“

OSGI+MQ

后来试了下比较流行OSGI容器，发现效果和我想要的不一样，然后又陆续多很多容器都做了实验，终于找到我想要的那个容器～～那个艰辛。。。容器的问题解决了，这回抱着能少写代码就少写代码的心，找了一款合适的MQ中间件，解决了二级代理和通讯的问题，于是整体架构就长这样啦～～～

Paste_Image.png

假如了解SaltStack架构的小伙伴肯定会说，切，不就是抄袭了SaltStack的架构嘛。假如是做过监控软件的小伙伴肯定也会说，切，我们监控软件都走的MQ的啦。架构这种东西嘛，大同小异，不同的架构为了解决的问题是不一样的，而OSGI+MQ的这个架构主要是为了解决上面的的问题而设计的

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

架构的缺点

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

上一篇 下一篇

猜你喜欢

热点阅读