服务平滑发布与线上验证

发布策略可分为：

• 蓝绿发布：将新版本服务器全部发好后，将旧版本服务器的流量统一切换到新版本上
• 灰度发布（金丝雀发布）：是一种滚动发布方式，首先部署部分新版本服务器，将部分流量切到新版本上进行灰度验证，后逐步增大灰度范围至全量

在业务服务的部署过程中，通常通过预发机器来验证新版本代码，验证完成后滚动发布线上机器。

但是发布过程中通常涉及多方服务的依赖，包括前后端、后端服务间、服务与数据库间。

前后端平滑发布

常见的场景是后端接口返回新增字段，此时需要后端先发布，前端再发布。

但若后端接口做了非前向兼容的变更呢？此时在原有接口基础上在进行改动线上不能达到平滑切换的目的，
因此需要新增“v2”接口，前端新版本均替换为调用后端的“v2”接口，因此再后端发布过程中，“v1”接口仍然能正常提供服务，
当前端发布完新版本后，流量会全走到“v2”接口，示意图如下：

二方包打包策略

二方包即公司内部服务之间RPC调用所需的依赖，通常为接口定义，具体实现包括Open Feign、Dubbo等。

在上线前需要将测试环境的SNAPSHOT版本的包替换为正式版本，需要注意的是SNAPSHOT版本通常是可覆盖的，
而正式版本只能追加不能变更包中代码的，所以SNAPSHOT版本应严禁上线。

当两个服务之间是单向依赖时，如A服务依赖B服务的二方包，只需B服务先上线并提供正式版本，A服务修改依赖B的二方包为
正式版本后上线。

而B的正式包什么时候打呢？以哪个分支打呢？有两种

1. B服务上线后并合到master后，以master分支打包
2. B服务预发验证完，上线前打包，以特征分支打包

使用方式1的弊端是当存在二方包循环依赖时，需要一方以SNAPSHOT上线
使用方式2的弊端是在多人开发时，B服务的二方包并不是最新的master代码，如果直接打包上线可能把已经上线的代码冲掉。

方式2的弊端可以在CD流程中增加校验来避免：当前上线分支是否包含master的最新commit。

所以推荐方式2+CD校验master最新commit方式。

Git项目多服务发布

通常一个Git项目会有多个服务，当项目代码改动时，改动涉及的服务都应发布，否则会出现线上不同服务之间的代码来自不同版本，
如果只发布当前改动服务，其他服务在改动服务上线后可能会由于不兼容的变更而运行报错。

线上验证

在预发和上线后需要对代码进行验证，尽量在不影响线上用户的情况下完成。

在开发时就需要为后续的验证“开后门”，常用的方式有黑名单，白名单，特性开关，灰度，指定参数运行任务等。

黑名单，白名单，特性开关，灰度方式均通过配置中心来控制，能够做到实时变更；
而一些定时任务的验证需要添加参数，如果参数不为空则按参数运行任务，以此来指定对象进行验证，避免影响线上用户。