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