服务平滑发布与线上验证

发布策略可分为:

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

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

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

前后端平滑发布

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

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

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

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

线上验证

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

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

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

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

相关推荐
RainbowSea9 分钟前
跨域问题(Allow CORS)解决(3 种方法)
java·spring boot·后端
掘金-我是哪吒10 分钟前
分布式微服务系统架构第155集:JavaPlus技术文档平台日更-Java线程池实现原理
java·分布式·微服务·云原生·架构
RainbowSea13 分钟前
问题 1:MyBatis-plus-3.5.9 的分页功能修复
java·spring boot·mybatis
前端 贾公子16 分钟前
monorepo + Turborepo --- 开发应用程序
java·前端·javascript
不学会Ⅳ1 小时前
Mac M芯片搭建jdk源码环境(jdk24)
java·开发语言·macos
虫小宝1 小时前
高佣金返利平台监控体系建设:APM、链路追踪与佣金异常预警系统技术实现
java
sniper_fandc2 小时前
SpringBoot系列—入门
java·spring boot·后端
代码的余温3 小时前
Maven引入第三方JAR包实战指南
java·maven·jar
pianmian16 小时前
类(JavaBean类)和对象
java
我叫小白菜7 小时前
【Java_EE】单例模式、阻塞队列、线程池、定时器
java·开发语言