转载

命令式和声明式，哪个才是你的菜

转载本文需注明出处：EAII企业架构创新研究院（微信号：eaworld），违者必究。如需下载此文PPT，加入微信群参与微课堂、架构设计与讨论直播请直接回复此公众号：“加群姓名公司职位微信号”。

今天的主题是讨论一下“命令式”思想和“声明式”思想在分布式系统和微服务架构运维中的应用。

主要大纲
1. “命令式”和“声明式”的概念

2. 命令式思想在分布式系统和微服务架构中遇到的困境

3. 以Kubernetes的设计思想为例，介绍声明式思想的优势

4. 普元的实践

“命令式”和“声明式”的概念

“命令式”和“声明式”这两个概念最初来自于编程语言，这两个概念并不常见，所以我们首先将他们明确一下。

第一个是“ 命令式 ”：

命令式和声明式，哪个才是你的菜

“命令式”有时也被称作“指令式”，好像有一个是台湾翻译，我不确定是哪一个了。“命令式”强调的是how，如果你是在写命令式的程序，那么你将step-by-step的告诉计算机如何完成一项工作，大多数的程序都是这样的。

在命令式场景下，计算机是不具备“智能”的，只是很机械的完成你交代的事情，至于结果如何，要看你的水平。就像上图，煎饼好吃不好吃、会不会糊锅，要看厨师对原料和火候的掌握。

另一个是“ 声明式 ”：

命令式和声明式，哪个才是你的菜 “声明式”有时也被成为“描述式”或者“申明式”，为告诉计算机你想要什么， “声明”你想要的what，由计算机自己去设计执行路径，需要计算机或者是“运行时”具备一定的“智能”。在这种情况下，计算机显然不会实现所有你想要的what，用专业术语说就是“非图灵完备”，但是针对特定的任务，“声明式”要远比“命令式”方便，其实大多数声明式语言都是针对特定任务的领域专用语言，即DSL。当然，随着深度学习驱动的自动编程技术的兴起，我们有可能在任意领域使用“声明式”完成任务，这是后话，暂且不提。

最常见的声明式语言就是SQL —— 告诉计算机你想要的结果集，SQL语言的运行时，即数据库，帮你设计获取这个结果集的执行路径，并返回结果集。众所周知，使用SQL语言获取数据，要比自行编写处理过程去获取数据容易的多。

下面是一个最简单的例子：

命令式和声明式，哪个才是你的菜

在这个例子里我们可以看到，使用其他通用语言“命令式”的完成查询，要比使用SQL语言“声明式”的完成查询复杂的多。在数据量很大的时候两种方法的复杂度差距会更加明显，数据库可以帮助你收集数据分布的统计信息、维护索引和选择最佳执行路径，以保证查询性能，如果你自行编码完成这些工作，那代码量会有成千上万行。

“声明式”虽然为一个编程语言的概念，但是也可以上升到一个比较高的层面，作为一个设计软件的思想或思路，就好像你可以使用“命令式”的C语言，编写一个可以“声明式”使用的数据库一样。

但是我们很少使用“声明式”思想去设计软件。下面是我能想到的几个原因：

命令式和声明式，哪个才是你的菜

最重要的原因是第三个，归纳和提取完备的what，是件很困难、很技术化的工作，令人望而却步。

但是在很多特定的领域，我们往往更加喜欢实现“声明式”思想的工具，比如前面提到的SQL语言。

命令式和声明式，哪个才是你的菜

原因也很简单，因为这些工具的编写者，已经把实践“声明式”思想的最大障碍—— 归纳和提取what，替你完成了。

命令式思想在分布式系统和微服务架构中遇到的困境

现在我们跳出编程的概念，看下“声明式”思想在系统和微服务架构的运维还有DevOps等领域的应用。

首先看一个运维故事：

命令式和声明式，哪个才是你的菜再看另外一个运维故事：

命令式和声明式，哪个才是你的菜

开个小玩笑，这里不是黑Puppet，也不是鼓吹Docker，我想表达的是，如果你以“命令式”的思路，编写一个过程化的脚本去部署应用，很可能会发生意想不到的事情，造成部署失败；而如果以“声明式”的思路，去制作和部署一个Docker镜像，那么成功率将大大提高。当然，Puppet也支持“声明式”，Docker也可以按“命令式”去使用，比如不太友好的Entrypoint脚本，但是这些都不是重点。

重点是：使用“命令式”思路去部署一个分布式系统或者微服务架构，已经变得非常困难。

比如部署下面这个系统：

命令式和声明式，哪个才是你的菜

“命令式”运维存在这下述问题，这些问题在分布式系统和微服务架构中日趋严重。

命令式和声明式，哪个才是你的菜

在分布式系统和微服务架构中，edge case更加复杂，环境更加动态，想在脚本中处理这些问题，你需要成为一个事无巨细的绝顶高手。如果同时还想实现部署结果的一致性、事务性和版本化，那简直是不可能完成的任务，就好像只是为了查询一笔数据，却要去编写一个数据库。

如果使用“声明式”的思路，问题则简单的多：

命令式和声明式，哪个才是你的菜

“声明式”运维的表现，就是编写一个配置文件，描述想要的部署结果，然后由平台解析这个配置文件并自动生成这个部署结果。描述部署结果的配置文件比过程化的脚本更加易于理解，可以由开发人员自行编写。由开发人员参与的Ops，才叫DevOps。

配置文件一目了然，多人维护不是问题，有错误也很容易被发现。配置文件本身就是文档。部署结果为配置文件所描述，如果达不到这个结果，那么部署失败并回退到部署之前的状态，所以部署天然具备了一致性和事务性。

当然，上述优势需要平台去保证，Kubernetes就是这样的一个平台。

以Kubernetes的设计思想为例，介绍声明式思想的优势

接下来就以Kubernetes为例，说明一下平台软件的“声明式”设计思想。

Kubernetes非常强调声明式思想，在其文档的第一篇就明确提出：

命令式和声明式，哪个才是你的菜

使用Kubernetes时，用户不需要去定义do A then B then C这种workflow，而是直接去描述一个desired state，然后Kubernetes帮助用户去达到这个state。至于如何达到这个state，用户不必关心。这种设计使Kubernetes更加易用和健壮，更具弹性和扩展性。

在Kubernetes的设计原则中，也把Declarative列在首位。

命令式和声明式，哪个才是你的菜