Spring Framework灰度发布

今天简单介绍下SpringFramework微服务中几种服务发布策略以及实现方式。我接触过的有蓝绿、滚筒和灰度发布。

蓝绿发布：

简单说就像美帝选总统投票一样，非蓝即绿一刀切，这个其实也是传统软件架构最常使用的升级方式，只不过服务需要重启才能生效，而在微服务中这种部分节点的替换是热部署上去的。

微服务中的蓝绿部署依赖的是Spring Cloud Zuul + Spring Cloud Config + Spring Cloud Eureka,实现方式如下：

我准备了5个节点：

1 GreenBlue-Config-server:配置注册中心

配置文件application.yml如下：

server:port: 8090spring:cloud:config:server:git:uri: https://github.com/yejingtao/forblogsearch-paths: /configusername: usernamepassword: usernameapplication:name: greenblue-config-servereureka:client:serviceUrl:defaultZone: http://peer1:1111/eureka/,http://peer2:1112/eureka/

2 GreenBlue-Zuul: API网关

配置文件bootstrap.properties如下：

spring.application.name=greenblue-zuul
spring.cloud.config.profile=dev
spring.cloud.config.label=master
server.port=7002eureka.client.serviceUrl.defaultZone=http://peer1:1111/eureka/,http://peer2:1112/eureka/spring.cloud.config.discovery.enabled=true
spring.cloud.config.discovery.serviceId=greenblue-config-servermanagement.security.enabled=false

3 GreenBlue-Eureka:服务注册中心，peer1、peer2做了高可用性

4 GreenBlue-Service-green:绿营服务端，application-name=greenblue-service-green

5 GreenBlue-Service-blue:蓝营服务端，application-name=greenblue-service-blue

另外git仓库上文件名为greenblue-zuul-dev.properties的内容只有2行：

zuul.routes.user-service.path=/api-service/**
zuul.routes.user-service.serviceId=greenblue-service-blue

（PS：本案例只能演示蓝绿部署如何割接不能直接用于生产，因为生产上还需要做蓝绿服务节点的高可用性、Spring Cloud Bus的配置推动、每个节点环境参数的Config统一管理、Zuul鉴权过滤、config-server安全控制等）

节点部署与发布如下：

验证步骤：

1 git仓库中边缘服务网关/api-service配置成blue，green节点不需要部署和启动，此时通过zuul访问/api-service是blue提供的服务

2部署green并注册到eureka上，我们要用它替换blue

3 git 仓库中的 /api-service 配置改成 green ，同时调用 zuul 服务的 refresh 方法使修改生效

蓝绿方式的优点是：一旦新服务green发现有bug或其它问题，我们可以重新切换回blue，由于blue没有被我们动过一丝一毫所以我可以认为这次服务的回滚是绝对安全的（数据回滚等除外），当我们将新服务green修复好后又可以最快的速度最小的代价发布上去！

蓝绿方式也有明显的缺陷，如果要发布的节点不是边缘服务、或者被其它节点以Eureka上注册的服务名的方式访问，如图：

如果我们要做Service-BlueB的升级就会很麻烦，但是路子还是有的：

需要多部署一套完整的拓扑才可以满足单独一个节点升级。

所以蓝绿方式的缺点也很明显：会造成硬件资源的浪费，极端情况下我们需要2套硬件资源（取决于系统的拓扑设计和服务拆分，2倍是上限）

滚筒发布：

滚筒发布与蓝绿发布一刀切的概念完全相反，像轮子一样一圈圈的往前滚，先替换一批节点，观察一段时间，确认没问题后再替换其他的节点。滚筒发布的先决条件是节点必须高可用性，也就是说在替换过程中要保留未被替换的节点继续提供旧服务。

我的节点拓扑如下：

滚筒发布完全依赖Eureka，所以为了避免混淆我这里将Zuul和config都去掉了，我现在的目的要将Roll-Service-V2版本发布上去。

1我先将Roll-Service-V1的部分节点下线

2将下线的这个节点进行线下升级，将补丁包、新版本之类的升级上去

3再将升级后的V2版本注册到Eureka上

4观察一段时间确定V2版本OK后，再将剩下的V1版本按批次用相同的方式部署发布。

滚筒发布有3个优点：1，机器利用率100%，没有硬件上的浪费；2，发布过程平滑，新老功能会并行一段时间；3，对节点服务做精确升级

滚筒发布也有3个缺点：1，发布步骤相对比较繁琐； 2，新版本出现问题不能及时回滚，回滚过程其实也是个滚筒发布的过程； 3节点达到一定数量后滚筒发布就会变得很无力，要滚好几次。

灰度发布：

灰色，黑白之间的颜色，如果旧版本为白新版本为黑，灰度发布就是由白变黑的渐进过程。寻龙诀电影里黄渤在下洞盗墓之前会弄个鸟笼里面关着个金丝雀，从洞口到墓底慢慢放下去，洞口为白墓底为黑，放到底金丝雀不死，发布成功。放到一半金丝雀不叫了，发布失败，放弃本次盗墓（扯多了）。

灰度发布的核心是Eureka+客户端负载均衡，发布过程直接上图：

将V2以相同的服务名注册到Eureka上利用Ribbon等客户端负责均衡技术就可以请求得到这个新版本，如图如果客户端使用的轮询策略那相当于对版本升级了25%，如果V2版本这25%的功能稳定没问题了可以按硬件条件继续添加新V2节点或者下线老V1版本直到100%。假如升级到50%我们发现V2版本有重大Bug，直接停掉所有V2服务，剩下50%V1版本短时间内仍可以提供稳定的服务。

如果说V2版本升级100%了需要回滚怎么办？黄渤发现金丝雀到了洞底后扔活蹦乱跳于是跳了下去结果自己被毒死了。这种情况一般要迅速部署几个V1版本的节点注册到Eureka上，同时下线V2节点，能不能抢救的回来看对业务影响多大了。

灰度发布的特点：1，发布过程平滑，进退自如 2，需要冗余的硬件，但不需要像蓝绿那么多。

这三种热部署发布方式没有好坏之分，完全根据自己的硬件条件和业务场景来选择，而且同一个大服务群中可以对不同的微服务模块使用不同的发布方式。个人比较推崇灰度发布，硬件要求不高，易操作，升级平滑。

最后了解下SpringFramework框架下服务节点如何下线：

大方向上分为Eureka注册端下线和节点服务自下线两种。

1 Eureka注册端下线：

$ curl -X PUT "http://peer2:1112/eureka/apps/HELLO-SERVICE/localhost:hello-service:8081/status?value=OUT_OF_SERVICE"

变量对应下图一看便知：

执行成功后服务会尝试设置为下线，下线成功后Eureka中服务状态会发生变化：

过15秒左右client客户端已经不会再分发到该OUT节点上了。此时可以把节点从Eureka上注销掉

$ curl -X DELETE "http://peer2:1112/eureka/apps/HELLO-SERVICE/localhost:hello-service:8081 "

此时微服务节点算是完全的隔离出来了，要杀要剐随你便了。

（PS：如果OUT_OF_SERVICE后没删除之前后悔了，可以将命令中Status改为UP执行下就好）

2 节点端服务下线

利用了Spring Boot Actuator的shutdown命令

Pom依赖添加actuator

配置添加endpoints.shutdown.enabled = true

对要下线的节点执行命令curl -X POST host:port/shutdown

个人推崇第一种方式，因为第二种方式很不安全，虽然可以进行权限控制，但是Eureka自带的功能那么好为啥还要另辟蹊径呢。

Spring Framework灰度发布相关推荐

Spring Cloud 灰度发布解决方案
文章已收录架构技术专栏收藏不迷路,点击获取更多视频资料福利因为目前公司架构全部切换到spring cloud 模式,对于服务灰度方面没有dubbo zk的方便了,所以细细研究总结下留作备份.目前 ...
spring cloud灰度发布快速上下线问题解决
因为目前公司架构全部切换到spring cloud 模式,对于服务灰度方面没有dubbo zk的方便了,所以细细研究总结下留作备份.目前业界有几种流行的发布部署策略,从网上资料可以搜索到,不是这次重点 ...
Spring cloud 灰度发布
Spring Cloud灰度发布之Nepxion Discovery 架构升级,有单体架构升级为微服务架构. 服务的灰度发布,根据访问量逐渐切换用新版本替换老版本,并且能够做到代码零入侵的. Nepx ...
spring java 灰度发布_springcloud灰度发布实现方案
Nepxion Discovery是一款对Spring Cloud Discovery服务注册发现.Ribbon负载均衡.Feign和RestTemplate调用.Hystrix或者阿里巴巴Senti ...
1、Nepxion Discovery：Spring Cloud灰度发布神器
原文地址:http://dockone.io/article/8149 Nepxion Discovery是一款对Spring Cloud服务注册发现和负载均衡的增强中间件,其功能包括灰度发布(包括切 ...
spring java 灰度发布_SpringCloud灰度发布实践（附源码）
前言在平时的业务开发过程中,后端服务与服务之间的调用往往通过fegin或者resttemplate两种方式.但是我们在调用服务的时候往往只需要写服务名就可以做到路由到具体的服务,这其中的原理相比 ...
Spring Cloud 优雅下线以及灰度发布
文章目录前言优雅下线常见的下线方式优雅的下线方式灰度发布蓝绿部署滚动部署金丝雀部署前言在生产环境中,如何保证在服务升级的时候,不影响用户的体验,这个是一个非常重要的问题.如果在我们 ...
Spring Framework（框架）整体架构
原文链接:https://blog.csdn.net/wd2014610/article/details/80061808 Spring 在这个Spring框架大行其道的软件开发世界里,尚有很多工程师 ...
Spring Framework（框架）整体架构（不知道就有些搞笑了哈）
Spring 在这个Spring框架大行其道的软件开发世界里,尚有很多工程师天天在用,但是从来不会去思考下,Spring框架的整体架构到底是什么样子的啊. 一.首先通过维基百科看看什么是Spring框 ...
Spring Cloud微服务版本灰度发布新神器
项目地址:https://github.com/Nepxion/Discovery 强烈建议stra.fork该项目,该项目可以作为学习改造Spring Cloud组件的案例项目. Nepxion D ...

Spring Framework灰度发布

Spring Framework灰度发布相关推荐

最新文章

热门文章