今天我们来聊一个很基础的话题：如何执行一条命令

作者简介

运小宇 百度高级研发工程师

负责基础运维组件相关开发工作，致力于运维基础设施的建设，夙兴夜寐，只为提高设备操作的便利性，一桥飞架南北，天堑变通途。

干货概览

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

什么是命令

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

图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 简单问题放大后也变得困难

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

执行高效：

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

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

控制灵活：

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

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

扩展方便：

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

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

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

如何解决

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

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

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