管控平台适合面向Kubernetes设计么？

现在都流行面向Kubernetes编程，也就是使用Kubernetes申明式API,面向终态思想衍生出来的管控平台。
但流行的东西真的适用么？

管控平台

管控平台就是公司后台资源和应用服务的系统，也被称作运维平台。

演进

一个公司的管控平台，通常先从单机脚本开始，随着规模逐渐扩大，需求增多，慢慢演变出平台型的云位系统。
为了解决任务执行过程中的异常，在系统中加入一些状态判断，慢慢演变出任务流系统，再在此基础上衍生出巡检系统，智能修复系统等。
更进一步，当管控平台能管理更大的规模的资源，有更多的功能，直到可以为外部提供服务时，就变成了云计算平台。

分层

一般的管控平台通常会有两个部分，逻辑层和操作层。逻辑层组织业务处理的流程，操作层负责执行具体操作。
假设我们要创建一个数据库实例，需要以下几个步骤：
1. 申请主机资源。
2. 在主机上安装数据库。
3. 初始化数据库文件。
4. 启动数据库。
5. 初始化数据库账号等信息。
6. 建立数据访问通道。

每个步骤都对应一个函数，这些函数便是操作层。
逻辑层则是将这些步骤串联起来。就和高级语言一样，封装的多了，开发也就更方便。
逻辑规则可以是代码，也可以是配置，二者也是可以相互转换的。过于复杂的规则不如用代码，简单的流程不如写规则。

管控逻辑

操作层都差不多，主要的区别在于逻辑层。
同样的功能有不同的设计思想和实现方式，但本质上还是相同的，都是让事情按照一定的依赖执行下去。

任务流

任务流就好像是一个传送带，每个任务就是传送带上的物品，传送带把物品送到执行点，处理后运往下一个执行点。最简单的任务流就是这样顺序执行。

特点

1. 流程走向是确定的。

优点

1. 任务流的特点在于逻辑简单，因为任务流的思维逻辑出发点在于任务本身，由任务(传送带)去驱动每个工作环节。这是一个顺序的思维，符合常人的思维模式。
2. 通常使用配置文件编写任务流程，很好地分离了逻辑层和操作层。

缺点

1. 从图中可以看出，流程较为简单，任务走向是固定的。
2. 全局同步，受全局任务队列控制，通常只会单线程执行。

优化方向

1. 支持更复杂的图配置，甚至是可编程的。

Operaotr式

Operator就是Kubernetes的工作单元，它依托Kubernetes运行。
Operator会主动去获取任务，就好像是一个自治工作单元的组合。每个单元前会有一个自己的入口和出口队列，它们接收上游的任务，处理后放到下游的队列中。

特点

1. 面向终态。
2. 没有提前确定流程。

优点

1. 有非常好的并行度，类似systemd的思想，让所有自启动程序自己运行，然后它们会根据依赖关系自己推进。
2. 更高的灵活性，不需要编写流程配置。

缺点

1. Operator的逻辑是一种逆向思维。思维逻辑出发点在每个工作单元，没有很好地全局视角，所以对开发者的要求较高。
2. 由于Operator是通过任务的属性来判断状态的，这就导致逻辑代码会有非常多的if else,对代码维护不利。
3. 过于灵活，可能会产生死循环。

优化方向

1. 让任务依赖关系可被展示。

小结

任务流是从简单开始，去累加更多的功能。
Operator则是站在了更高的起点上，把复杂留给自己，再慢慢优化。

总结

面向Kubernetes的设计适合较为简单的事务。在有较为复杂的逻辑处理时，面向任务的设计更加适合。
当然，二者在实现上都可以优化，吸收对方的优点。只是思考方式不同罢了。
所以，具体需求具体分析，找到最合适的抽象方式，而不是手里有个锤子，看什么都是钉子，生搬硬套地过度抽象。