运维部署系统介绍

导读

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

  • 效率：降低部署门槛，使业务发布变更工作由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