服务发布策略

蓝绿部署

蓝绿部署需要对服务的新版本进行冗余部署，一般新版本的实例规格和数量与旧版本保持一致，相当于该服务有两套完全相同的部署环境，只不过此时只有旧版本在对外提供服务，新版本作为热备。当服务进行版本升级时，只需将流量全部切换到新版本即可，旧版本作为热备。由于冗余部署的缘故，所以不必担心新版本的资源不够。如果新版本上线后出现严重的问题，那么只需将流量全部切回至旧版本，大大缩短故障恢复的时间。待新版本完成问题修复并重新部署之后，再将旧版本的流量切换到新版本。

蓝绿部署通过使用额外的实例资源来解决服务发布期间的不可用问题，当服务新版本出现故障时，也可以快速将流量切回旧版本。

如下图所示，某服务旧版本为v1，对新版本v2进行冗余部署。版本升级时，将现有流量全部切换为新版本v2。

当新版本v2存在问题或者发生故障时，可以快速切回旧版本v1。

• 蓝绿部署的优点：

  • 部署结构简单，运维方便。

  • 服务升级过程操作简单，周期短。

• 蓝绿部署的缺点：

  • 资源冗余，需要部署两套生产环境。

  • 新版本故障影响范围大。

A/B测试

A/B测试基于用户请求的元信息将流量路由到新版本，这是一种基于请求内容匹配的灰度发布策略。只有匹配特定规则的请求才会被引流到新版本，常见的做法包括基于HTTP Header和Cookie。基于HTTP Header方式，例如User-Agent的值为Android的请求 （来自安卓系统的请求）可以访问新版本，其他系统仍然访问旧版本。基于Cookie方式，Cookie中通常包含具有业务语义的用户信息，例如普通用户可以访问新版本，VIP用户仍然访问旧版本。

如下图所示，某服务当前版本为v1，现在新版本v2要上线。希望安卓用户可以尝鲜新功能，其他系统用户保持不变。

通过在监控平台观察旧版本与新版本的成功率、RT对比，当新版本整体服务符合预期后，即可将所有请求切换到新版本v2，最后为了节省资源，可以逐步下线到旧版本v1。

• A/B测试的优点：

  • 可以对特定的请求或者用户提供服务新版本，新版本故障影响范围小。

  • 需要构建完备的监控平台，用于对比不同版本之间请求状态的差异。

• A/B测试的缺点：

  • 仍然存在资源冗余，因为无法准确评估请求容量。

  • 发布周期长。

金丝雀发布

金丝雀发布是将少量的请求引流到新版本上，因此部署新版本服务只需极小数的实例。验证新版本符合预期后，逐步调整流量权重比例，使得流量慢慢从老版本迁移至新版本，期间可以根据设置的流量比例，对新版本服务进行扩容，同时对老版本服务进行缩容，使得底层资源得到最大化利用。

如下图所示，某服务当前版本为v1，现在新版本v2要上线。为确保流量在服务升级过程中平稳无损，采用金丝雀发布方案，逐步将流量从老版本迁移至新版本。

• 金丝雀发布的优点：

  • 按比例将流量无差别地导向新版本，新版本故障影响范围小。

  • 发布期间逐步对新版本扩容，同时对老版本缩容，资源利用率高。

• 金丝雀发布的缺点：

  • 流量无差别地导向新版本，可能会影响重要用户的体验。

  • 发布周期长。