1、通用运维流程架构ByCodeBox-腾讯设计理念1.简单。2.可扩展。3.开发量少。4.无状态。5.容易问题定位。设计目标1.单一性，每个运维子系统提供单一最纯粹的服务，比机器资源子系统，域名子系统。2.原子性，每个子系统的只提供最原始的原子接口，即只提供机制，不提供策略。3.幂等性，一个接口被多次调用，不会产生副作用。4.松耦合，每个运维子系统不知道其它子系统的存在，最大程度上解耦。5.无状态，架构中的每个点都是无状态的，可以任意水平扩展。6.统一协议，每个运维子系统提供的都是htp+json的接口。架构解析架构图如下：Web层紫色部分是整个运维系统提供的htp功能性接口，供web页面或其它
2、系统调用。设计思路是这样的：接收到大的功能请求后，将其拆成内部子系统(蓝色部分)的原子接口，并根据流程，排列成有序的步骤(图中将cmd拆解成step0,1,2)。将其作为一个消息投递的绿色的消息总线中，然后htpcgi就给调用方返回了(返回一个taskid,供调用方实轮询task运行结果)。为方便前端调用，cgi可以将以上两个步骤合起了，形成一个同步接口。消息队列绿色部分是消息队列，是驱动整个系统运转的消息总线。执行器黑色部分是原子接口执行器excutor，每个excutor对应一个运维子系统(蓝色部分)。Excutor监听消息总线中属于自己的消息，消息由1中的cgi投递或者其实它上游的exc
3、utor投递。Excutor收到属于自己的消息后，进行个性化的逻辑处理，处理完成后将处理结果写到translog中，供cgi查询；最后excutor将消息重新投放到消息队列中，接收者为下一步的excutor，直到完成。有两个比较特殊的excutor，Erro和Debug。所有的常规excutor执行发生错误，会将消息的接收者设置为Erro，Erro会把消息置成回滚状态，重新投递到消息队列中去。这个时候的执行顺序就是反着的了step2,step1,step0，依次执行回滚操作。这样Erro的消息可以作为观察系统异常的窗口，不用到各个子系统上到处查日志什么的，便于定位问题。消息队列中的所有消息都有
4、一份走到Debug中，用于开发调试，同样是一个观察整个大系统运行的窗口TransLog红色的translog是excutor的执行结果的保存，cgi根据taskid来轮询任务的完成情况。运维子系统蓝色的是运维子系统，是提供具体特定服务的运维系统。其内部的总是设计实际上也是正在介绍的这套框架，也就是说像是递归一样到最后一层的子系统，基本上就是操作系统库，或跟RS机器的各种agent打交道了。采用的组件1.web层Qzhtp2.消息队列RabitMQ的worker模式3.Excutor用python实现的框架4.TransLog用自研的持久化内存存储，接口兼容mecahe5.有些事务必须加锁的，使用zokeper。这样，每个结构都可以做集群来提高性能和稳定性。后续给大家介绍特定子系统相关内裤。
个人主页