服务平滑发布与线上验证

发布策略可分为:

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

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

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

前后端平滑发布

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

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

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

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

线上验证

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

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

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

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

相关推荐
CryptoRzz7 分钟前
欧美(美股、加拿大股票、墨西哥股票)股票数据接口文档
java·服务器·开发语言·数据库·区块链
杂货铺的小掌柜27 分钟前
apache poi excel 字体数量限制
java·excel·poi
大厂码农老A35 分钟前
你打的日志,正在拖垮你的系统:从P4小白到P7专家都是怎么打日志的?
java·前端·后端
艾菜籽1 小时前
Spring MVC入门补充2
java·spring·mvc
爆更小哇1 小时前
统一功能处理
java·spring boot
程序员鱼皮1 小时前
我造了个程序员练兵场,专治技术焦虑症!
java·计算机·程序员·编程·自学
n8n1 小时前
SpringAI 完全指南:为Java应用注入生成式AI能力
java·后端
不爱编程的小九九2 小时前
小九源码-springboot082-java旅游攻略平台
java·开发语言·旅游
只是懒得想了2 小时前
用C++实现一个高效可扩展的行为树(Behavior Tree)框架
java·开发语言·c++·design-patterns
码农阿树2 小时前
Java 离线视频目标检测性能优化:从 Graphics2D 到 OpenCV 原生绘图的 20 倍性能提升实战
java·yolo·目标检测·音视频