运维部署系统介绍

导读

部署系统负责在线业务的变更,是国之重器。部署系统主要承担了三方面的职责,

  • 效率:降低部署门槛,使业务发布变更工作由SRE转移给RD,提高公司整体运维效率
  • 稳定性:固化变更流程,预防变更隐患;提供高效止损手段,加快故障恢复
  • 标准化:建立和推动运维规范,奠基大一统的运维自动化体系。标准化也是为效率和稳定性两个大目标服务的

本文概要介绍了XJ半自动化部署系统的产品模型、技术架构、流程规范等。

背景和目标

XJ业务快速发展、在线服务规模迅速扩大,微服务架构逐渐落地、在线服务模块数迅速增加。XJ的部署工具未能同步发展,因服务部署(变更)引发的故障占比极高(大约80%左右)。因此,运维部启动了半自动化部署系统的建设项目。

从产品层面来讲,这套部署系统的目标用户是业务RD,主要解决业务RD通过UI来操作上线的半自动化场景、不解决持续发布等全自动化场景。OP会放权给业务RD来自助执行上线操作。

从运维体系建设的角度来讲,这套系统承担了如下两个重要使命,

  • 固化变更流程:约束业务RD的上线流程,强制实现变更通告、分级发布、异常阻断等变更流程,弱化对人员素质的要求,降低稳定性风险
  • 统一运维规范:重塑在线业务的运维特征,包括服务定义、编译方式、启停方式、目录结构等,使之足够统一,奠基大一统的运维自动化体系

下面,我们主要从产品模型、系统架构、流程规范两个角度来介绍这套系统,产品形态不做详细介绍。

产品模型

服务变更的本质是 “将指定版本的代码批量更新服务的多台机器上”。XJ的部署系统,在经典的服务树结构上增加了一级机器分组, 实现了对机器的批量管理。如下图,

arch.png

每次代码更新都需要发一个部署单。一个部署单,只能更新一个服务或模块,可以更新一个或多个集群,对机器的更新节奏(流程)由部署系统来控制。

关于服务、集群、模块等的定义,在 “流程规范” 一节详细介绍。

技术架构

部署系统的技术架构相对简单,由5个部分组成,如下图所示。

arch.png

模块介绍

  1. Web模块是FE部分,实现了和用户的交互,基于蚂蚁金服的antdesign开发。
  2. Api模块是整个部署系统的控制中心,实现了诸如发单审核、变更通知、分级发布、异常阻断等核心业务逻辑。
  3. Build模块负责生成部署包。Build并不会完成源代码的编译工作,而是直接使用了持续编译(对应EP.Build)产出的可执行文件包。Build会拆解可执行文件包,注入运维元数据、托管配置、镜像配置等,然后重新压缩成部署包。
  4. Artifact是部署包的下载源,提供了简单的http下载能力。
  5. Agent是部署在每台机器上的代理。它接受Api模块的控制,从Artifact拉取部署包,按照指定的逻辑停止老服务、更新代码、启动新服务。

操作流程

  1. 用户通过Web发单
  2. 单子被审核通过后
  3. Api会自动控制Build完成打包、并在Artifact上生成部署包下载源
  4. 之后,用户通过Web依次操作多个集群下的不同物理机部署。部署
    • 用户在Web上的操作会发指令给Api
    • Api将收到的指令转化为单机任务,发送给对应机器上的Agent
    • Agent收到Api控制指令后,完成单机部署任务

流程规范

流程和规范是两个事情:流程重在约束人的行为,规范重在约束平台或工具。部署系统实现了多种流程和规范,下面逐步介绍。

流程

  • 变更通告:平台自动发送变更通知给一组自定义的人,通知时机为每个集群分组开始变更;
  • 变更步骤:平台强制实现了工单审核,提供了一键回滚的能力;
  • 分级发布:平台实现了灰度、小流量、中流量、全流量的发布控制策略,通过拉长周期、分批上线来控制灾难的影响范围;
  • 高峰期封线:平台在高峰期窗口内强制封线,各业务线或者服务按需自定义高峰期窗口;
  • 服务检查:平台实现了checklist定义、部署暂停、double check、QA质检拦截、监控异常拦截等功能,在变更引发故障时做阻断;

上述流程,是XJ内部固化的变更五条军规,具备相当的普适性。一个典型的部署模块配置如下所示,包含了大部分的流程定义,

arch.png

规范

  • 服务定义:服务管理中心为每个服务分配一个全局唯一服务名USN,USN命名尽量做到与组织结构无关,如 falcon-graph
  • 集群定义:集群是一组完全同构的服务实例,简称Cluster,通常按照”逻辑机房”的方式来命名,如 gz01、gz01-pre
  • 服务单元:服务单元即为服务的一个集群,简称SU,如 falcon-graph.gz01、falcon-graph.gz01-pre
  • 部署模块:部署模块由 “git地址 + git子目录 + git分支” 来唯一确定
  • 编译规范:在每个部署模块的目录下,实现一个名为build.sh的编译脚本,执行build.sh将源码转换为可执行文件
    • 根据退出码是否为0判断编译是否成功,通过标准输出、标准错误打印编译信息
    • 可执行文件存储在output目录下,部署时会将output目录结构拷贝到线上机器的部署路径下
  • 启停规范:在编译生成的可执行文件output目录下,实现一个名为control.sh的服务启停控制脚本,执行control.sh stop停止服务、执行control.sh start启动服务
    • 根据退出码是否为0判断编译是否成功,通过标准输出、标准错误打印编译信息
  • 服务自描述:部署系统会生成一个服务自描述文件目录.deploy,存放在每个服务实例部署目录下
    • 自描述信息主要包括服务名USN、集群名Cluster、服务单元SU、模块名称、代码版本等信息
    • 自描述信息为方便应用程序获取自身元信息而设计

源码包、编译产出的可执行文件、部署包结构分别如下。其中,可执行文件的deploy-meta目录存放的是部署动作控制文件,部署包的.deploy目录存放的是服务自描述文件,

arch.png

后续优化方向

  • 融合物理机和容器的产品形态
  • 抽象出一套通用的变更通路(API),使支持代码变更、大数据配送、单机故障自愈、自定义软件安装等


Prev     Next