[实践]分布式微服务SpringCloud灰度/蓝绿/AB测试发布方式实践

架构 springcloud devops 发布方案 持续集成
768

前言

目前常见的发布策略有蓝绿发布、金丝雀发布（灰度发布）、AB测试这几种，在国内的开发者中，对这几个概念有独立的理解。蓝绿发布通常被大家成为热部署；金丝雀发布在国内的名头完全被他的变种发布方式盖过了，主要是灰度发布与AB测试。[AppAdhoc:互联网产品的3种发布策略]

  1. 蓝绿发布
    在发布的过程中用户无感知服务的重启，通常情况下是通过新旧版本并存的方式实现，也就是说在发布的流程中，新的版本和旧的版本是相互热备的，通过切换路由权重的方式（非0即100）实现不同的应用的上线或者下线。
  2. 金丝雀发布
    通过在线上运行的服务中，新加入少量的新版本的服务，然后从这少量的新版本中快速获得反馈，根据反馈决定最后的交付形态。对于比较流行的SpringCloud分布式微服务方案的发布方式如果要使用以上提到的发布方案，则有很多实现方式。后面几篇文章介绍并实践集中方案
  3. 灰度发布
    灰度发布是通过切换线上并存版本之间的路由权重，逐步从一个版本切换为另一个版本的过程。和金丝雀发布相比，金丝雀发布更倾向于获取快速的反馈，而灰度发布更倾向于从一个版本到另一个版本平稳的切换。

很多大厂一般会有自己的自研平台，比如

  1. 网易[刘超:大规模微服务场景下灰度发布与流量染色实践， 01 Dec.2019]
  2. 有赞[飘石:有赞灰度发布与蓝绿发布实践，19 Mar.2020]

除了大厂自研，云服务器供应商也会提供上述的发布方案。比如:

  1. 阿里云方案[edas]

但是使用云服务器供应商的发布方案虽然会很简单实用，但容易形成与供应商的技术绑定，形成耦合。
所以方案很多，可以根据自己的需要进行选择。
但我此次实践的是基于开源可实践的方案，会有以下几种方式的实践：

  1. Kubernetes
  2. Nepxion/Discovery[Discovery]
  3. 自己实现[结合Spring Cloud Zuul 与 Kubernetes的灰度发布测试方法]

需求

对于基于SpringCloud的分布式微服务项目

springcloud
  - register //eureka-server
  - gateway //springcloud-gateway
  - book-service //eureka-client,openfeign
  - user-service //eureka-client,openfeign

此次验证发布方式主要以蓝绿发布为主。

验证

  1. Nepxion/Discovery
  2. Kubernetes 蓝绿部署

对比

总结

参考

  1. 互联网产品的3种发布策略
  2. 刘超:大规模微服务场景下灰度发布与流量染色实践， 01 Dec.2019
  3. 飘石:有赞灰度发布与蓝绿发布实践，19 Mar.2020
  4. Alibaba:edas
  5. 结合Spring Cloud Zuul 与 Kubernetes的灰度发布测试方法