在日常的工作中通常会组合几个系统的相关功能共同完成某个业务场景，这时候通常在一般的微服务中就需要使用分布式事务来解决，或者通过本文说的编排的方式来解决，本文算是这个系列的入门篇，主要是介绍下笔者在实际工作中的尝试，后续会持续更新一些内部的原理与更好玩的生产实践
1.背景
在接手的运维平台中之前的设计是在一个大的controller将完成某个业务场景的代码全部写在一起，然后中间为了兼容各种之前的平台和场景的问题，充斥着大量的if else以及硬编码，导致出了问题需要就要人为介入排查，扩展性、健壮性几乎为零, 为了更好的理解第二部分我们的尝试，这里先给大家介绍几个概念
1.1 运维中的任务编排
在传统的运维开发中，任务编排通常是一个很常见的系统，在k8s之前的运维系统中，通常是基于master-worker架构实现对应的任务的编排，也有很多的开源产品，比如stackstorm、tower、jeankins等
同一些业务上使用的框架并无本质区别，我们可以通过写插件来实现对应的接口，就可以丢给系统取跑任务了，任务过程中的数据、状态都由对应的插件自身维护，系统只负责任务的调度，而不负责状态和数据的管理
1.2 运维中的状态
面向终态是大佬们最近这几年引领的新的运维模型，通过描述最终状态，系统根据当前状态去决策采取的动作然后等待对应的反馈结果，再次进行决策从而达到正向反馈环，直到目标状态。
但其实日常的工作中很多业务逻辑通常都是有状态的。比如在扩容场景中，如果没有知道当前的Pod或者Server的状态，本质上你也没办法决策接下来该做啥操作。在一个长的worfklow里面如果你不知道任务的状态，则就无法知道当前可以在那个步骤进行重试
1.3 智能决策的愿景
记得在之前公司的时候大家还一起听大佬分享的AIOPS，根据人工智能和专家经验在故障发生时可以自动进行决策，达到快速止损的目标，什么知识图谱、根因分析、智能机器人想想就可怕。不过作为一个程序员，我感觉我写的程序如果能比我先发现问题，我都会怀疑是不是Bug
相比智能运维笔者更看好可落地的基于事件驱动的运维，通过感知对应的事件根据专家经验，将对应事件的处理机制流程化自动化，无论是从可控性、稳定性、确定性上都可以得到保障
2.解决方案
其实也谈不上方案，主要是落地的一点思考，其实没有调研太长时间，因为时间上并不允许。所以就粗暴的选型后，开始根据我们的业务场景进行系统设计了，这里就先介绍下选型和架构
2.1 选型
根据运维场景分析出来，我们需要的是一个有状态的、可编程的、支持workflow、带容错、无限扩展的分布式任务编排框架。当前云原生里面的任务编排貌似是一个冷门方向，于是笔者就看了下业务上解决分布式事务场景的框架，最终我们选定uber的cadence框架来实现，不过Candance的作者对DSL貌似很反感，并没有实现默认的DSL编排功能。
为什么选型没有按照常规的选择一些比如airflow之类的，主要原因其实跟笔者环境有关。公司当前的基础服务大多数要么是基于开源的改造，要么就是自研。所以对开源的默认集成的对笔者来说其实意义不大，反正都得自己写Provider。其二笔者现在的平台有Java、Go两种语言，为了方便集成，一定要选择一个夸语言的。
2.2 系统架构
基于开源的candance我们直接设计了我们的上层业务层v0.1版本，为了实现上面提到的两大核心功能：编排和决策，我们设计了6个业务模块，其功能如下：
| 模块 | 说明 |
|---|---|
| 原子组件 | 封装各种原子任务，提供workflow和dsl做任务编排 |
| DSL编排 | 系统提供基础的workflow决策，并且支持DSL编排 |
| 事件 | 用于监听或者接受外部系统传递的事件触发对应的决策模块 |
| 决策 | 实现基础的业务分级、机器分批等决策功能，决策会触发对应的workflow或者原子组件 |
| 服务目录 | 通过服务目录对外提供原子操作和worfklow使用 |
| 管控模块 | 管控模块主要是对决策的结果进行管理，避免多个决策模块进行相同作业的下发，实现统一的控制 |
可以看出candance帮我们解决很分布式底层的很多问题，只需要构建上层业务模块就可以了，等业务功能写完，抽时间看看对应的实现，到时候再分享给大家
2.3 工作流程
系统的运行分为两个大的阶段：编排期与运行时
> 编排期
1.平台研发负责将各种平台功能分装成原子组件接入到系统中
2.运维专家根据业务场景，组合下层的原子任务，并构建对应的DSL流程，对应的worfklow作为决策分支供决策模块使用，同时设置对应的互斥策略
> 运行时
1.当对应的运维对象发生状态变更时，则会产生对应的事件
2.决策模块接收到事件之后，根据事件类型和决策分支进行决策，生成决策结果
3.然后调用管控模块，确认决策结果是否可以下发到生产环境
4.管控模块根据当前的运行中的工作任务确定是否可以进行对应的决策
5.下发workflow给Candance，然后由candance进行workflow和原子任务的编排
6.原子操作最终红会触发运维对象的状态变更，然后再进行对应的操作，直到达到目标状态
3.心得
先写到这吧，最近还是比较忙，周末在家看了一天service catalog的代码，晚上想想还是得总结下，因为好久没写文章了，想了好几个小时，也没咋写，感觉乱乱的。等后面代码写完了在给大家分享下里面的一些代码级别的设计。明天再给大家分享下service manager里面好玩的东西。大佬们帮我分享分享，要吃土了。。。