在企业内部时常有服务启停的需求,有时是由于在进行故障排除时须要对某些服务进行启停;有时是由于这些服务在线时间长了容易发生异常,须要按期进行启停;有时是由于须要进行更新包的投产发布,须要进行服务的启停。shell
无论怎样,企业中的运维工做中离不开服务启停,而每次进行服务启停若是都要手工登录目标服务进行操做的话,不但繁琐低效,并且容易出现错误操做。服务器
在远程链接的时候特别容易操做错误,好比经过远程桌面或者是ssh链接,原本想要重启A服务器上的服务,不当心把B服务器上的服务重启了。因此,咱们能够借助自动化运维平台,来开发一个用于批量、自动执行服务启停的SaaS。框架
本文就对服务启停SaaS的设计进行一些讨论。下面咱们就分类进行讨论要完成一个服务启停动做要包含的要素。运维
要进行服务启停,首先咱们要知道通常在企业内部对应用进行运维的过程当中,都须要对应用服务执行什么操做。常见的操做有【启动服务】、【中止服务】和【重启服务】,另外还有若是按常规方法中止服务后,服务不响应请求时,须要一个【强制杀进程】的操做。ssh
在执行完上面的操做后,一般咱们还须要进行一下检查这个操做是否成功。【启动服务】后,咱们须要检查服务是否启动成功;【中止服务】后,咱们须要检查服务是否中止成功等。ide
那么咱们就要设计出针对这些动做的检查动做了,通常的检查动做有:设计
检查该服务的进程是否在运行对象
检查该服务对应的端口是否在侦听blog
检查该服务对应的应用是否能正常提供服务进程
而对于检查进程运行和端口侦听,咱们能够结合成一个动做,因此这里须要设计两个检查动做:【端口检测】和【应用状态检测】。
综上所述,对于服务启停来讲,咱们能够设计出以下几个动做(固然,根据须要启停的服务的特殊性,也能够有针对性地设计不一样的动做):
启停的流程比较简单,根据企业实际的运维场景去设计就行了,下面以两种场景为例:
1.因故障排除等缘由须要临时性地进行服务启停
2.周期性地进行服务启停
其中提交申请和审批的动做是在外部完成,因为是周期的执行,是有计划的,因此一些企业须要要求进行工单申请,待审批后才能执行,而且是须要建立一个启停任务来执行,以便于更好地进行任务管控和审计。
对于临时性地进行服务启停(如故障排查时),启停模式比较简单,只须要提供用户主动执行的启停按钮便可,用户在有须要的时候进行点击执行,配合被动的检查动做便可基本知足需求。
而对于计划性地服务启停,则有点不同,因为是周期性或计划性地启停,必然不会只启停单一的一个服务,一般是针对整个应用下的集群的服务进行启停,可能涉及十几乃至几十上百个节点上的服务的启停,若是还只提供那几个单纯的启停按钮的话,那用户可能会点鼠标点到手抽筋。因此咱们必须设计批量的方式,针对多个服务同时进行启停。
另外还有考虑批量启停的状况下进行分批启停,也就是第一批服务的启停执行完后,紧接着执行第二批的启停。由于通常在启停整个集群下的服务时,为了避免让应用出现中断服务的状况,须要先启停其中一部分服务,启停成功且正常提供服务后,再启停剩余部分。如图示:
你设计的服务启停能启停哪些服务?这很重要,若是你针对Nginx启停设计一套SaaS,那么是否还要针对Weblogic的服务启停再设计一套SaaS呢?Tomcat呢?启停更多的服务呢?
因此,咱们须要考虑能尽可能知足多种服务的启停的SaaS,可是每种服务的启停方式不一致,其运行环境不一致,使用的命令也不一致,那怎么办呢?
额……把这个事情交给管理员去作吧,咱们提供一个通道入口就好了:咱们设计一个框架,支持管理员根据服务的实际启停命令录入相应的脚本或命令,咱们的SaaS来执行这些命令,以完成相应的启停动做。
同时还要考虑目标对象对脚本的适应性,好比Windows上的服务支持使用bat脚本,Linux上的服务支持使用shell脚本等。
对于临时性地启停需求,管理员只需定位到相应的服务去执行启停动做就能够了,可是对于周期性、有计划第执行批量启停的时候,如何将这一批服务编排起来又是一个问题,难道我每次要启停的时候,都须要一个一个服务去找到并进行编排吗?那显然是浪费时间和精力的。
在此咱们须要为方便管理员针对固定的一批服务进行编排批量执行而进行设计,所以咱们能够设计“模板”这个功能,把管理员须要常常启停的比较固定的一批服务事先编排好放在哪里,等到须要执行启停的时候,直接把这个模板拿出来用就行了。
以上就服务启停进行了简单设计讨论,通过如此设计后的服务启停SaaS,应该比较能适用于通常企业对于服务启停的需求了,供你们参考。
做者:何立
好文推荐