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