在平常的工做中一般会组合几个系统的相关功能共同完成某个业务场景，这时候一般在通常的微服务中就须要使用分布式事务来解决，或者经过本文说的编排的方式来解决，本文算是这个系列的入门篇，主要是介绍下笔者在实际工做中的尝试，后续会持续更新一些内部的原理与更好玩的生产实践程序员
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个业务模块，其功能以下：ide
| 模块 | 说明 |
|---|---|
| 原子组件 | 封装各类原子任务，提供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里面好玩的东西。大佬们帮我分享分享，要吃土了。。。
云原生学习笔记地址: https://www.yuque.com/baxiaoshi/tyado3 微信号：baxiaoshi2020 公共号: 图解源码
微信号：baxiaoshi2020