tns的两种模式及灰度发布与冷启动

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月750个小时 15LCU
简介:

tns的两种模式

    tns客户端tns-client支持不同的使用模式,包括load balance、masterslave模式,接下来介绍不同模式的作用和设计原理

load balance

    在集群模式中,一个请求过来后要通过某种策略将请求分配到后台某个服务器上,这个策略我们可以称为负载均衡

    tns采用加权随机的方法实现负载均衡

    举例:服务serviceA下面有3个实例,对不同的实例分配不同的vNodes个数(权重),假如:a1:2;a2:4;a3:4,那么客户端会将请求的2/10分配到a1节点,将请求的4/10分配到a2节点或a3节点,从而实现了负载均衡

    在tnsclient中使用LoadbalanceTSNodeIndexBuilderRandomTSNodeSelector

masterslave

    在集群模式中,我们希望将请求分发到主节点(master),然后当master down后,将请求分发到某slave节点


    大多数分布式系统master/slave由分布式系统本身实现,即系统自身包含一个监控组件,当监控组件检测到master不可用后自动提升某slave为master,典型代表为zookeeper(leader、flower)

    tns自身并不提供masterslave功能,通过tnsclient在调用某个服务时实现。同样基于vNodes机制,tnsclient将获取到的某服务的所有实例,根据vNodes进行自然排序,vNodes小的节点优先,若vNodes相同,再根据id进行排序

    同上面例子,如果采用masterslave模式,a1 vnodes最小,排在第一位,作为master;假如a1 down掉,那么a2或a3被提升为master,此时a2和a3 vnodes相同,所以id小的会被提升为master

    在tnsclient中使用MaterSlaveTSNodeIndexBuilderMasterSlaveTSNodeSelector

灰度发布与冷启动

    所谓灰度发布,就是对要发布的程序先小批量上线,一旦出现问题,不至于影响到所有用户。

    tns实现方式天然具有灰度发布的特性。基于vNodes,并且采用load balance模式,我们只需将发布的新节点的vNodes设置比较小(权重低),那么线上的流量只会有一小部分流到这个新节点,从而实现灰度发布的效果。

    一般情况下,刚刚加入到集群的节点认为是冷启动状态,为了进行预热,需要对其慢慢增加压力,同上,tns在每次ping service的时候都会更新vNodes,service可以根据自己的状态返逐级增加vNodes,来达到冷启动的效果。

相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
目录
相关文章
|
3月前
|
Kubernetes 监控 测试技术
在K8S中,如何实现上线发布流程(灰度发布)?
在K8S中,如何实现上线发布流程(灰度发布)?
|
3月前
|
Kubernetes 监控 Java
发布策略:蓝绿部署、金丝雀发布(灰度发布)、AB测试、滚动发布、红黑部署的概念与区别
发布策略:蓝绿部署、金丝雀发布(灰度发布)、AB测试、滚动发布、红黑部署的概念与区别
367 0
|
4月前
|
负载均衡 算法 测试技术
通用快照方案问题之灰度发布中实现用户请求到新旧版本服务的分流如何解决
通用快照方案问题之灰度发布中实现用户请求到新旧版本服务的分流如何解决
45 0
|
4月前
|
数据采集 监控 负载均衡
通用快照方案问题之通过Ribbon进行灰度发布如何解决
通用快照方案问题之通过Ribbon进行灰度发布如何解决
34 0
|
6月前
|
Kubernetes Cloud Native 测试技术
使用ASM流量泳道的全链路灰度发布实践
服务网格ASM实现全链路灰度发布:通过流量泳道隔离不同版本环境,配置虚拟服务实现灰度比例控制。从创建泳道、打标签、部署新版本到灰度切流、最终上线及下线旧版。
|
安全 Perl
使用服务网格ASM的金丝雀模式提升升级稳定性
阿里云服务网格ASM支持基于修订与标签的升级模式,以更稳定安全的方式执行新版本控制面的金丝雀升级。在这个新升级模式中,数据面的网格代理将与他们使用的特定控制面版本相关联。这使得新版本能够以较低的风险在集群中部署, 直到用户明确选择之前,没有代理连接到新版本。同时也允许逐渐将工作负载迁移到新的控制面,每个独立的控制面被称为“修订版”并具有istio.io/rev标签。 为了支持这种基于修订的升级,Istio为命名空间引入了一个istio.io/rev标签。它可以指示哪个控制面版本应该为相应命名空间中的工作负载注入Sidecar代理。例如,标签istio.io/rev=1-17-2表示为该命名
359 0
使用服务网格ASM的金丝雀模式提升升级稳定性
|
缓存 Kubernetes 容灾
应用发布新版本如何保障业务流量无损(一)| 学习笔记
快速学习应用发布新版本如何保障业务流量无损
应用发布新版本如何保障业务流量无损(一)| 学习笔记
|
开发框架 运维 Kubernetes
应用发布新版本如何保障业务流量无损(二)| 学习笔记
快速学习应用发布新版本如何保障业务流量无损
应用发布新版本如何保障业务流量无损(二)| 学习笔记
|
Java 中间件 测试技术
全链路灰度新功能:MSE上线配置标签推送
微服务场景下,全链路灰度作为一种低成本的新功能验证方式,得到了越来越广泛的应用。除了微服务实例和流量的灰度,微服务应用中的配置项也应该具备相应的灰度能力,以应对灰度应用对特殊配置的诉求。
全链路灰度新功能:MSE上线配置标签推送
|
安全 Java
一种可灰度的接口迁移方案
在快速迭代的互联网背景下,系统为了实现快速上线,常常会选择最快的开发模式,例如我们常见的mvp版本迭代。大部分的业务系统对于未来业务的发展是不确定的,因此随着时间的推移,往往会遇到各种各样的瓶颈,例如系统性能、无法适配业务逻辑等问题,这时可能就涉及到系统架构的升级。系统升级往往包含最基础的两个部分:接口迁移重构和数据迁移重构,在系统架构升级的过程中,最重要的是需要保证系统稳定性,即用户不感知。因此文本的目的是提供一种可灰度、回滚的设计思路,实现稳定的架构升级。
682 1
一种可灰度的接口迁移方案
下一篇
无影云桌面