服务平滑发布与线上验证

发布策略可分为:

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

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

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

前后端平滑发布

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

但若后端接口做了非前向兼容的变更呢?此时在原有接口基础上在进行改动线上不能达到平滑切换的目的,

因此需要新增"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项目会有多个服务,当项目代码改动时,改动涉及的服务都应发布,否则会出现线上不同服务之间的代码来自不同版本,

如果只发布当前改动服务,其他服务在改动服务上线后可能会由于不兼容的变更而运行报错。

线上验证

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

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

黑名单,白名单,特性开关,灰度方式均通过配置中心来控制,能够做到实时变更;

而一些定时任务的验证需要添加参数,如果参数不为空则按参数运行任务,以此来指定对象进行验证,避免影响线上用户。

相关推荐
墨染点香12 分钟前
LeetCode Hot100【6. Z 字形变换】
java·算法·leetcode
ldj202035 分钟前
SpringBoot为什么使用new RuntimeException() 来获取调用栈?
java·spring boot·后端
超龄超能程序猿36 分钟前
Spring 应用中 Swagger 2.0 迁移 OpenAPI 3.0 详解:配置、注解与实践
java·spring boot·后端·spring·spring cloud
风象南1 小时前
SpringBoot配置属性热更新的轻量级实现
java·spring boot·后端
洛阳泰山1 小时前
Spring Boot 整合 Nacos 实战教程:服务注册发现与配置中心详解
java·spring boot·后端·nacos
Y4090011 小时前
C语言转Java语言,相同与相异之处
java·c语言·开发语言·笔记
YuTaoShao1 小时前
【LeetCode 热题 100】994. 腐烂的橘子——BFS
java·linux·算法·leetcode·宽度优先
布朗克1681 小时前
java常见的jvm内存分析工具
java·jvm·数据库
都叫我大帅哥2 小时前
深入浅出 Resilience4j:Java 微服务的“免疫系统”实战指南
java·spring cloud
Cao_Shixin攻城狮4 小时前
Flutter运行Android项目时显示java版本不兼容(Unsupported class file major version 65)的处理
android·java·flutter