本文源码:GitHub·点这里 || GitEE·点这里
一、服务发布简介
分布式系统架构下,服务发布是一件很麻烦的事情,特别是在构建自动发布流程和灰度测试的策略两个核心方面。通常情况下如果不涉及数据层面的灰度流程,服务可以灰度上线,或者滚动上线,这两种方式很常用;如果涉及到数据灰度,则可能需要中间服务做不同版本数据之间追平,或者停机维护一次性处理好数据和上线问题,不过后面这种方式风险较大。
二、蓝绿部署
新版本上线的时候,并不停掉老版本,新旧两个版本同时运行,通常还会在负载均衡的策略上倾向于旧版本服务处理请求,这样新版本就有一个执行的观察期过渡期,等到新版本平稳运行一段时间后,再把请求都发到新版服务上,旧版本服务完成下线。这种方式在分布式架构下很少使用,对服务器要求过高。
三、滚动发布
滚动发布可以避免蓝绿部署的服务器资源占用问,首先发布一台新版本服务,然后停掉一台老版本服务,新版服务经过观察之后,再逐步替换掉所有老版本的服务,这样服务的环境变动比较频繁,相对不稳定。
四、灰度发布
上述两种方式在普通业务场景下都还算好操作,分布式系统下的灰度发布复杂程序相对高很多,基础流程如下:
新版本上线,可能涉及分布式下多个灰度服务,因此在服务在整个链路上分发时,都要判断下个请求是路由到正常服务还是灰度服务,还要对灰度服务做请求的权重控制,不能让灰度服务处理大量的请求。
实际策略:在实际的分布式系统灰度发布流程,通常会采用如下一个策略:
- 配置一个灰度是否开启的标识;
- 配置一批灰度账户,通常内部人员;
- 配置灰度服务版本标识;
- 请求在链路执行时,判断灰度是否开启;
- 判断当前用户身份是否是灰度测试账号;
- 获取当前可以请求的服务列表;
- 根据灰度服务版本选择请求的具体服务;
这个流程非常的复杂,需要很多自定义的策略,还要熟悉分布式框架的底层API原理,要二次重写来适配灰度策略,设计重写原生API还容易触发一些惊喜问题。
五、数据库灰度
如果说最难处理的灰度模式是什么,就是数据库的版本灰度问题,通常业务对数据库改造升级,实际都是通过停机维护来处理的,可能很多开发都经历过,发布停服公告,然后在指定时间内把数据全部追平或者二次搬运,再重新提供服务。但是总有些业务场景是不能停机维护的,处理灰度数据的基本策略如下:
该模式中,除了正常的灰度流程之外,需要在灰度数据库和正常数据中间提供一个数据调配服务,用来解决如下问题:灰度数据库缺失数据,需要临时从正常库拉取,灰度版本失败,新数据需要重新整合写入原本正常库;灰度版本成功,旧版数据迁移等;最终保证数据的平稳升级。
六、源代码地址
GitHub·地址
https://github.com/cicadasmile/data-manage-parent
GitEE·地址
https://gitee.com/cicadasmile/data-manage-parent
推荐阅读:编程体系整理
序号 | 项目名称 | GitHub地址 | GitEE地址 | 推荐指数 |
---|---|---|---|---|
01 | Java描述设计模式,算法,数据结构 | GitHub·点这里 | GitEE·点这里 | ☆☆☆☆☆ |
02 | Java基础、并发、面向对象、Web开发 | GitHub·点这里 | GitEE·点这里 | ☆☆☆☆ |
03 | SpringCloud微服务基础组件案例详解 | GitHub·点这里 | GitEE·点这里 | ☆☆☆ |
04 | SpringCloud微服务架构实战综合案例 | GitHub·点这里 | GitEE·点这里 | ☆☆☆☆☆ |
05 | SpringBoot框架基础应用入门到进阶 | GitHub·点这里 | GitEE·点这里 | ☆☆☆☆ |
06 | SpringBoot框架整合开发常用中间件 | GitHub·点这里 | GitEE·点这里 | ☆☆☆☆☆ |
07 | 数据管理、分布式、架构设计基础案例 | GitHub·点这里 | GitEE·点这里 | ☆☆☆☆☆ |
08 | 大数据系列、存储、组件、计算等框架 | GitHub·点这里 | GitEE·点这里 | ☆☆☆☆☆ |
发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/2698.html原文链接:https://javaforall.cn
【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛
【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...