如何利用开源框架实现运维编排

关注

VIP免费原创最新推荐文章于 2025-11-14 09:49:11 发布 1k 阅读 AI 写同款· GEO 优化 ›

Kstry流程编排框架 Kstry是什么？ 1、所见（图示模型）即所得（代码执行）的可视化流程编排框架 2、可轻易将流程从串行升级到并行，支持任务拆分、任务重试、任务降级、子任务遍历、指定超时时间的并发框架 3、共享能力平台侧的微服务业务整合框架 4、类似阿里TMF2.0，可以做到平台与业务分离，业务与业务隔离的服务化框架阅读详情

在日常的工作中通常会组合几个系统的相关功能共同完成某个业务场景，这时候通常在一般的微服务中就需要使用分布式事务来解决，或者通过本文说的编排的方式来解决，本文算是这个系列的入门篇，主要是介绍下笔者在实际工作中的尝试，后续会持续更新一些内部的原理与更好玩的生产实践

1.背景

在接手的运维平台中之前的设计是在一个大的controller将完成某个业务场景的代码全部写在一起，然后中间为了兼容各种之前的平台和场景的问题，充斥着大量的if else以及硬编码，导致出了问题需要就要人为介入排查，扩展性、健壮性几乎为零, 为了更好的理解第二部分我们的尝试，这里先给大家介绍几个概念

1.1 运维中的任务编排

在传统的运维开发中，任务编排通常是一个很常见的系统，在k8s之前的运维系统中，通常是基于master-worker架构实现对应的任务的编排，也有很多的开源产品，比如stackstorm、tower、jeankins等同一些业务上使用的框架并无本质区别，我们可以通过写插件来实现对应的接口，就可以丢给系统取跑任务了，任务过程中的数据、状态都由对应的插件自身维护，系统只负责任务的调度，而不负责状态和数据的管理

1.2 运维中的状态

面向终态是大佬们最近这几年引领的新的运维模型，通过描述最终状态，系统根据当前状态去决策采取的动作然后等待对应的反馈结果，再次进行决策从而达到正向反馈环，直到目标状态。但其实日常的工作中很多业务逻辑通常都是有状态的。比如在扩容场景中，如果没有知道当前的Pod或者Server的状态，本质上你也没办法决策接下来该做啥操作。在一个长的worfklow里面如果你不