认识达内从这里开始

随着互联网的不断发展，越来越多的人都在学习达内Java编程开发等互联网技术，而本文我们就通过案例分析来了解一下，声明式API和命令式API的对比。

命令式

命令式有时也称为指令式，命令式的场景下，计算机只会机械的完成指定的命令操作，执行的结果就取决于执行的命令是否正确。

声明式

声明式也称为描述式或者申明式，这种方式告诉计算机想要的，由计算机自己去设定执行的路径，需要计算机有一定的智能。

常见的声明式栗子就是数据库，查询的sql就表示我们想要的结果集，数据库运行查询sql的时候，会帮我们处理查询，并且返回查询的结果。数据库在查询的时候，会进行索引匹配，做查询优化等处理，再返回数据结果的时候，同时使用优的查询路径。如果我们自己去处理这些操作，就需要写很多代码了，而不是仅仅通过一行代码就能解决。

在运维中，命令式的思路弊端就很多了

1、编写脚本的难度很大，需要想明白每一步的操作，处理每一步可能遇到的各种情况，高度依赖编写者的经验;

2、脚本依赖部署的环境，不同的环境可能执行的结果就是不一样的,同时依赖稳定的环境，在分布式环境下，不太容易实现;

3、运维的流程很难具备事务性，如果脚本的执行被以外打断，会产生一些意想不到的中间状态;

4、需要另外编写运维的文档，如果多人维护，协作就很困难。

声明式的思路就能解决上面的这些情况了

声明式的运维表现，就是编写一个配置文件，描述想要的部署结果，然后平台去解析这个配置文件生成部署的结果。部署的配置文件比过程化的脚本更容易理解，也更方便开发人员编写。

配置文件更容易审错和多人维护，并且如果当前的部署失败，我们只需要更改部署文件为之前的版本，重新部署就能回退到之前的版本。

Kubernetes的设计用的就是声明式的设计思想。

Kubernetes不仅仅是一个编排系统，实际上它消除了编排的需要。编排的技术定义是执行已定义的工作流程：先执行A，然后执行B，再执行C。而Kubernetes包含了一组独立可组合的控制过程，可以连续地将当前状态驱动到所提供的预期状态。你不需要在乎如何从A移动到C，也不需要集中控制，这使得系统更易于使用且功能更强大、系统更健壮，更为弹性和可扩展。这正是声明式的设计思想的体现。

Kubernetes声明式API的工作原理

当一个YAML文件提交给Kubernetes之后，它究竟是如何创建出一个API对象的呢?

在Kubernetes项目中，一个API对象在Etcd里的完整资源路径，是由：Group(API组)、Version(API版本)和Resource(API资源类型)三个部分组成的。

APIServer如何处理API请求

1、请求过滤请求，进行一些前置性的工作，比如授权、超时处理、审计等;

2、API路由匹配;

进入MUX和Routes流程，MUX和Routes的主要作用是完成APIServer的URL和Handler绑定，Handler找到对应的CronJob类型定义。

3、根据提交的YAML文件创建资源;

上面的栗子，根据这个CronJob类型定义，使用提交的YAML文件里的字段，创建一个CronJob对象。

4、使用准入控制器，进行变更操作或验证操作;

准入控制器(AdmissionController)位于APIServer中，在对象被持久化之前，准入控制器拦截对APIServer的请求，一般用来做身份验证和授权。

准入控制器包括以下两种：

1、变更(Mutating)准入控制：修改请求的对象;

2、验证(Validating)准入控制：验证请求的对象。

5、序列化，保存到Etcd中。

APIServer会把验证过的API对象转换成用户初提交的版本，进行序列化操作，并调用Etcd的API把它保存起来。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。