123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687 |
- // tag::main[]
- = 服务升级规范
- 为保证整个系统中某个服务升级,但不影响正常使用,列出以下要求。
- == 术语定义:
- *
- **
- == 规范约束
- === 发布流程
- ==== snapshot 自测版本
- . 开发人员提交源代码至 `git` 服务器,触发 CI 的 `普通 CICD 流程`
- . CI 服务器根据 `自动测与部署流程` 配置进行以下操作
- .. 自动编译构构建代码
- .. 部署 `dev` 版本至 *内测环境*
- .. 执行单元测试
- .. 执行自动化测试
- . 开发人员在内测平台进行自测
- ==== release.pre 预发布版本
- . 开发完毕后提交代码,msg中附带 `release test` 等 `预发布版` 标识性关键词,触发 CI 的 `预发布流程`
- .. 自动编译构构建代码
- .. 部署 `release` 版本至 *预发布环境*
- .. 执行单元测试
- .. 执行自动化测试
- . 开发、测试人员在预发布平台进行测试
- ==== release 发布版本
- . 开发完毕后提交代码,msg中附带 `release` 等 `发布版` 标识性关键词,触发 CI 的 `自动发布流程`
- .. 自动编译构构建代码,将生成的 jar 发布到仓库
- .. 根据 `Dockerfile` 生成 docker 镜像,打 `TAG` ,发布到镜像仓库
- . 触发 *正式发布流程*,进行 *滚动升级*
- . 开发、测试人员在预发布平台进行测试
- === 正式发布注意点
- ==== 发布过程
- * 配置文件备份
- ** 如 nginx.conf 文件,修改前备份,并放置在安全易查找的位置,以便于升级后服务异常,便于快速回滚。
- * 数据库修改后置
- ** 若升级需要修改数据库数据,最好放置在升级完成后进行。
- * 尽量保证预发布环境与正式环境的一致性(数据库尽量)
- ==== 部署方案
- * 中间件集群部署,保证高性能、高可用(至少至少3个节点)
- * 数据库至少高可用部署,具体方案与业务量有关(至少2个节点,主备VIP)
- * 微服务至少2个节点(至少两个节点)
- === 发布类型
- * [.line-through]停机发布
- ** 流量低谷发布,会有 404,不推荐。
- * 滚动发布
- ** 每次只执行一个或一批服务,升级完成后加入系统,成本低。
- * 灰度发布(金丝雀发布、A/B发布)
- ** 启动需要更新的服务,部分流量先迁移,如果没问题则全部迁移,主流。
- * 蓝绿发布
- ** 运行整个新系统,运行后直接切换到新系统。稳定,成本大。
- === 平滑升级
- * 新版本能处理旧版本请求,废弃的功能返回固定错误码,由调用发进行不兼容处理
- * 旧版本能处理新版本的接口响应,错误码统一
- * 版本升级,数据库变动时,以新加字段为主,对于废弃字段,新版本提供默认值处理
- * 消息队列中消息附带版本号
- * 文件系统中、配置文件等带版本号
- ******
- * https://bbs.huaweicloud.com/blogs/211869[HUAWEI 灰度发布]
- * https://blog.csdn.net/qq_35425070/article/details/106885246 自动生成 changeLog
- // end::main[]
|