公司网站设计注意什么,访问自己做的网站吗,网络营销师就业前景,uzi视频网站谁做的文章目录 前言灰度发布的优点设计概要系统架构图流量控制客户端服务端 路由路径应用客户端实现核心组件分析1.网关2. spring-cloud3. dubbo4. nocas5. thread6. message queue 前言
微服务架构中的灰度发布#xff08;也称为金丝雀发布或渐进式发布#xff09;是一种在不影响… 文章目录 前言灰度发布的优点设计概要系统架构图流量控制客户端服务端 路由路径应用客户端实现核心组件分析1.网关2. spring-cloud3. dubbo4. nocas5. thread6. message queue 前言
微服务架构中的灰度发布也称为金丝雀发布或渐进式发布是一种在不影响现有用户的情况下逐步将新版本的服务部署到生产环境的策略。通过灰度发布你可以先将新版本的服务暴露给一小部分用户或特定的流量观察其表现确保没有问题后再逐步扩大流量最终完全替换旧版本。 注: 该灰度方案的实现主要基于java 去实现
灰度发布的优点
降低风险通过只对一部分用户或流量进行更新可以减少新版本引入的问题对所有用户的影响。快速回滚如果新版本出现问题可以迅速将流量切换回旧版本避免影响更多用户。渐进式验证可以在小范围内验证新版本的功能和性能确保其稳定性和兼容性。用户体验优化可以通过灰度发布收集用户反馈逐步优化新功能而不必一次性全面推广。避免熬夜发版
设计概要 系统架构图 流量控制
客户端
对于请求流量识别控制可以据实际需求设计下面列举几种常用的
用户设备ID客户端版本客户端标签
服务端
流量管理服务端主要作用灰度信息管理及控制:
管理: 用户、 设备ID、 客户端版本客户端标签,等维度信息;灰度信息推送到网关: 让网关依据这些信息请求识别为正常流量还上灰度流量 如果正常流量将路由到正常实例如果是灰度流量将路由到灰度实例 注:为了简化设计同时满足核心需求不做过度设计实现仅给流量打上灰度标签或无(正常流量)
路由路径
网关-ribbon-cloud服务-ribbon-cloud服务网关-ribbon-cloud服务-thread–ribbon-dubbo服务网关-ribbon-cloud服务-mq服务-cloud服务网关-dubbo-dubbo服务-thread-dubbo服务网关-dubbo-dubbo服务-mq服务-dubbo服务 上面大概列举基本请求所可能经过的路径要实现灰度路由经过这些路径的组件必须实现灰度标签 的传递及据灰度标签选择路由
应用客户端实现
因为需要对应用实例状态的控制以及服务实例之间的灰度标签传递和路由所以需要修改相关客户端代码的实现。
sdk 方式 如果采用该方法可能面临的问题: 1.业务应用推广难大需要对所有应用依赖升级打包 2.跨线程标签续传可能需求修改来务业务代码代价太大了 3 消息队列收发可能要调整业务代agent 方式 该方式可以很好解决sdk方式的三个问题但开发会复杂些综合分析采用 agent 方式更为合适些
核心组件分析
1.网关
网关作为后端流量的统一入囗在灰度布实现中充当着什么重要的角色
担任着灰度信息管理入口流量的灰度识别请求路由(确认是路由到正常服务实例或是灰度实例)
2. spring-cloud
如果微服务实现的是spring-cloud灰度路由的控制需要实现以下几点
eureka client 自动生成实例id作为元数据上报到注册中心,用作实例与管理标识管理灰度标签的续传如a服务调用b服务把标签通过http请求头传递到b服务拦截feign调用或 RestTemplate 把灰度请求添加到http 请求头里ribbon 的rule 拦截依赖灰度标签做路由选择
3. dubbo
如果微服务实现的是dubbo处理跟spring-cloud类似,灰度路由的控制需要实现以下几点
灰度标签的续传如a服务调用b服务把标签通过rpc attachment续给续传拦截dubbo 路由接口,依赖灰度标签做路由选择
4. nocas
如果注册中心使用的是nacos同步也要自动上报实例id,到nacos注册中心
5. thread
在服务路由选择时需要依赖灰度标签,所以需要把灰度标签由一引服务传递到另一个服务或一个线程传到另一个线程; 像经过spring-cloud或dubbo这些框架上面已实现跨服务标签续传,但是如果业务代码内出现跨线程操作后,则会出现标签断传; 处理该问题可以分别对以下接口或类进行标签续传增强处理:
拦截Runnable或Callable,接口增强实现标签续传;拦截ThreadPoolExecutor, 但是当业务使用Callable或Runnable 时使用的是lambda表达式时 可以通过拦截ThreadPoolExecutor增强实现标签续传
6. message queue
一般现在的后端服务难免会用到消息队列如果用到自然也要对消息队列消费路由处理 但是消息的消费无法像微服务之间调用可据路由规则选择提供方 既然无法像服务之间调用处理去理路由只有另求其他办法据消息中间件具体的特性也可以实现同样的消息 1.kakfa,rocketmq 可以把topic分成正常消费组和灰度消费组各自只接口符合自身状态的消息其它状成的消息丢掉 2.rabbit 可以分正常virtualhost和灰度virthualHost,收发消息 … 未完后续介绍具体的实现
最后给大家安利一款mysql监控软件: 安装方便消耗低可视化傻瓜式操作可以监控慢日志详情、cpu、内存、连接数、tps 等信息 体验演示 下载地址
