shoulder-specs-doc/src/main/asciidoc/specs/devOps/deployAndUpgrade.adoc

// 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 灰度发布]

// end::main[]