如何执行一条命令

干货概览

 

今天我们不聊上层建筑，不聊单机房自愈，也不聊智能运维的暗夜与黎明，今天我们聊一个很基础的话题：如何执行一条命令。许多人看到这，可能觉得这是一个简单至极的问题，事实果真如此吗，别急，下面我们来抽丝剥茧，一探究竟。

 

什么是命令

 

首先回顾一下“命令”的具体含义，发令以使之，谓发令而使其做某事，这是“命令”一词的基础释义。从这里我们可以看命令的三个最基本的要素：命令内容（令）、命令传递（发）、命令执行（使）。如果将这三要素限定在服务器上，它们又是如何运作的呢？

 

图1 windows与linux下的命令

 

命令内容（令）

 

无论是windows还是linux操作系统，都会提供相应的CLI（不要吐槽windows的CLI难用），供使用者交互执行命令或运行批处理脚本。仔细观察，所有命令行都有一个相同的特点：固定词+选项+参数，无出其右。因CLI伴随着操作系统的诞生，且命令行处理又是一个复杂但相似的过程，因此各种语言也都提供了相应的库支持，如C语言提供了getopt/getopt_long等函数，C++的boost提供了Options库，shell中处理此事的是getopts和getopt。

 

命令传递（发）

 

命令传递有两种方式，一种是文件形式，将bat/shell脚本上传到服务器然后执行。另外一种就是交互式，通过telnet/ssh等方式远程连接服务器后，直接在命令行界面执行。虽然从形式上我们将命令传递分为了两种方式，但从本质上来说，服务器上的命令传递，都没有逃脱网络传输这个过程。

 

命令执行（使）

 

对于操作系统来说，命令的执行，其实就是启动一个进程并传递相应的参数，运行完成后得到相应的结果。这里我们并不关心进程如何创建，PBC的结构如何等细节，我们只关心命令进程的启动方式以及结果的获取方式。

 

为什么要执行命令

 

在分布式产品的开发维护过程中，有三个主题是无法绕过的，分别是配置管理、部署升级和监控采集。

 

配置管理

 

配置管理的目标是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更。从某种角度讲，配置管理是一种标识、组织和控制修改的技术。通常情况下，配置管理都会统一部署配置服务器来同步所有节点的配置。但是在开发测试过程中，总会出现临时修改某个或某一批节点的配置的情况，这时通过人工逐个登录来完成修改显然是不太可能的。

 

部署升级

 

DevOps的概念如今日趋流行，部署升级越发成为开发运维过程中重要的一环，频繁的交互意味着频繁的部署。部署过程可以拆解为两个小的步骤，一是新软件包的上传，二是服务进程的重新启动。服务进程的重新启动不必多说，软件包的上传可能有多种方式，如sftp的集中式，p2p的点对点式等。

 

监控采集

 

软件运维过程需要时刻监控系统及业务软件的运行状态，各种运维决策都是以这些数据为依据进行的。随着自动化运维的发展，很多运维动作都从人工执行变为了自动执行，自动执行的决策过程更是需要采集大量的实时信息（前期文章《百度大规模时序数据存储》中介绍的TSDB就是为了解决这些数据的存储问题而研发的）。监控数据的来源主要分两种，一种是通过业务软件提供的接口直接读取状态数据，另一种是通过日志/进程状态/系统状态等（如使用grep提取日志，通过ps查询进程状态，通过df查询磁盘使用等）方式间接查询。

 

无论是配置管理、部署变更还是监控采集，都有一个共同的目的：控制服务器。在现阶段，要想对服务器进行控制，离不开“在大量服务器上执行命令并收集结果”这一基础能力，这也是今天我们的主题“如何执行一条命令”的意义所在。

 

面临的困难

 

命令行的三要素，也是如何执行一条命令行面对的三个问题，如前文所述，对于单机环境来说，这三个问题在前人的努力下已经被很好的解决。可是如果要在几十万台机器上每天执行几十亿条命令，同时保证时效性，保证执行成功率，保证结果正确收集，保证7*24小时稳定运行，就不是一件简单的事情了。所谓远行无轻担，量大易也难，在构建这样的执行系统的过程中要面临诸多困难，此处举几个突出的例子如下：

 

信息存储问题：为了支持水平扩展，需要高效的内存数据库作为缓存。为了做到执行命令的可追溯、可统计，需要对执行过的命令信息持久化。日均几十亿的热数据，年均上万亿的冷数据，需要仔细选择存储方案。

 

任务调度问题：为了达到在任意多台服务器上执行命令的要求，需要确定何时分发命令、何时回收结果以及怎么样的并发度批量下发。

 

消息传输问题：为了保证命令高效正确送达目标服务器，需要构建一个可靠的命令传输网络，使命令信息在准确送达的前提下保障传输的可靠与高效，毕竟百度的几十万台服务器分布在世界各地。

 

代理执行问题：为了更好的处理权限、单机并发等单机执行问题，需要在目标机构建执行代理，以应对单机的复杂执行环境。

 

图2简单问题放大后也变得困难

 

百度目前拥有分布在世界各地的几十万台服务器，并且随着业务的不断扩张，这个数字还在持续增长，构建一个高效稳定通用可扩展的命令描述、传递、执行系统在这样的环境中有着重要的现实意义。对百度各产品线的用户来说，这样的一个系统，最基础的要求是：执行高效，控制灵活，扩展方便。

 

1.执行高效：

 

单机执行，要求能够达到秒级命令下发/执行/结果收集。

 

集群执行，要求支持同时在10万台服务器上并行执行，同时保证集群中每个机器达到单机执行的性能。

 

2.控制灵活：

 

单机控制，要求支持暂停、取消、重做功能。

 

集群控制，要求支持暂停点功能，也即可以在执行到某台服务器时暂停，等待人工检查确认无问题后可继续执行。

 

3.扩展方便：

 

支持插件，要求支持自定义执行插件，用户可编写自己的插件执行相应操作。

 

支持回调，要求支持自定义用户回调，如任务执行失败调用相应回调接口。

 

除了以上的业务需求外，一个分布式系统的搭建，还要考虑可用性、可扩展性、性能、一致性等方面的硬性要求。

 

如何解决

 

为了解决这个简单的难题，我们设计了如图3所示的百度集群控制系统（Cluster Control System，简称CCS系统），通过分离控制信息与执行信息建立了两级数据模型，结合命令执行及机房部署特点建立了四级传输模型，通过三级守护方式建立了稳定的执行代理，在大规模服务器集群上解决了“命令三要素”问题。

 

图3百度集群控制系统架构

 

截至目前，CCS系统已经部署在全百度的所有机房中，用户可以方便的在任意一台机器上进行秒级命令下发和结果收集，日均承载数亿次来自各产品的接口调用。关于数据模型、传输模型、执行代理这“分布式命令三要素”的设计及应用，我们将在下一篇文章中详细介绍。