为保证整个系统中某个服务升级,但不影响正常使用,列出以下要求。

术语定义:

* **

规范约束

发布流程

snapshot 自测版本

  1. 开发人员提交源代码至 git 服务器,触发 CI 的 普通 CICD 流程

  2. CI 服务器根据 自动测与部署流程 配置进行以下操作

    1. 自动编译构构建代码

    2. 部署 dev 版本至 内测环境

    3. 执行单元测试

    4. 执行自动化测试

  3. 开发人员在内测平台进行自测

release.pre 预发布版本

  1. 开发完毕后提交代码,msg中附带 release test预发布版 标识性关键词,触发 CI 的 预发布流程

    1. 自动编译构构建代码

    2. 部署 release 版本至 预发布环境

    3. 执行单元测试

    4. 执行自动化测试

  2. 开发、测试人员在预发布平台进行测试

release 发布版本

  1. 开发完毕后提交代码,msg中附带 release发布版 标识性关键词,触发 CI 的 自动发布流程

    1. 自动编译构构建代码,将生成的 jar 发布到仓库

    2. 根据 Dockerfile 生成 docker 镜像,打 TAG ,发布到镜像仓库

  2. 触发 正式发布流程,进行 滚动升级

  3. 开发、测试人员在预发布平台进行测试

正式发布注意点

发布过程

  • 配置文件备份

    • 如 nginx.conf 文件,修改前备份,并放置在安全易查找的位置,以便于升级后服务异常,便于快速回滚。

  • 数据库修改后置

    • 若升级需要修改数据库数据,最好放置在升级完成后进行。

  • 尽量保证预发布环境与正式环境的一致性(数据库尽量)

部署方案

  • 中间件集群部署,保证高性能、高可用(至少至少3个节点)

  • 数据库至少高可用部署,具体方案与业务量有关(至少2个节点,主备VIP)

  • 微服务至少2个节点(至少两个节点)

发布类型

  • [.line-through]停机发布

    • 流量低谷发布,会有 404,不推荐。

  • 滚动发布

    • 每次只执行一个或一批服务,升级完成后加入系统,成本低。

  • 灰度发布(金丝雀发布、A/B发布)

    • 启动需要更新的服务,部分流量先迁移,如果没问题则全部迁移,主流。

  • 蓝绿发布

    • 运行整个新系统,运行后直接切换到新系统。稳定,成本大。

平滑升级

  • 新版本能处理旧版本请求,废弃的功能返回固定错误码,由调用发进行不兼容处理

  • 旧版本能处理新版本的接口响应,错误码统一

  • 版本升级,数据库变动时,以新加字段为主,对于废弃字段,新版本提供默认值处理

  • 消息队列中消息附带版本号

  • 文件系统中、配置文件等带版本号