11 | Loadbalancer 实战：通过自定义负载均衡策略实现金丝雀测试
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入介绍了如何通过自定义负载均衡策略实现金丝雀测试。首先，文章解释了Spring Cloud Loadbalancer的工作原理，包括@Loadbalanced注解的使用和负载均衡过滤器的注入过程。然后，文章提到了Loadbalancer提供的内置负载均衡策略以及如何实现自定义负载均衡策略来进行金丝雀测试。金丝雀测试是一种灰度测试，通过将代码改动部署到极个别的几台机器上，实现在极小规模范围内进行线上测试。文章详细介绍了CanaryRule负载均衡规则的编写过程，包括如何识别测试流量和对测试流量进行负载均衡。接着，文章讲解了配置CanaryRule负载均衡策略以及在WebClient请求的Header中传入测试流量标记的方法。最后，文章指出了金丝雀测试的实现原理和方法对技术人员的成长具有重要意义，鼓励读者不要在技术学习上给自己设界，而是多去了解更多技术框架的全貌，积累到一定程度之后，这些努力都会在未来某一个时刻给你回报。整体而言，本文内容深入浅出，适合读者快速了解负载均衡策略的实现原理和金丝雀测试的应用场景。
《Spring Cloud 微服务项目实战》，新⼈⾸单¥59
全部留言(24)
- 最新
- 精选
peter老师我有个关于代理的问题：一般用nginx将请求转发到后端多个应用服务器上。现在用了API网关，由API网关将请求转发到后端应用服务器上。这样的话，API网关和nginx的功能就重复了，就不需要nginx了，对吗？ 尤其对于中小公司，服务器数量不是很多，nginx就足够了，或者用API网关就足够了，两者选一个就够了啊。作者回复: 还是需要nginx的，微服务网关和nginx扮演的角色不一样，nginx作为高性能反向代理，性能上是完爆任何微服务网关的。而且一般公司会根据安全策略设置多层LVS+Nginx网关，比如secure zone, unsecure zone等等，内部网络拓扑非常复杂，这里依然需要nginx来扮演网关的角色。 而微服务网关，比如后面我们要看到的spring cloud gateway，往往扮演的角色是在外部网关和内部微服务之间的桥梁，通常不会作为最外层网关直接承接外部用户流量
2022-01-06310- Geek_0b93c0集群优先代码 private Response<ServiceInstance> getSameClusterService(Request request, List<ServiceInstance> instances) { String clusterName = environment.resolvePlaceholders("${spring.cloud.nacos.discovery.cluster-name:}"); List<ServiceInstance> instanceList = instances.stream().filter(v -> { Map<String, String> metadata = v.getMetadata(); String serviceClusterName = metadata.get("nacos.cluster"); return clusterName.equals(serviceClusterName); }).collect(Collectors.toList()); //有同集群下服务 RoundRobin算法挑选 if (CollectionUtils.isNotEmpty(instanceList)){ return getRoundRobinInstance(instanceList); }else { return getRoundRobinInstance(instances); } }
作者回复: perfect, 从metadata这个属性里可以读到很多data做各种定制
2022-05-319 
与路同飞现在公司所有api服务都是注册到api网关上去了。api网关替我们做了负载均衡和路由规则。那业务团队是不是就不需要引用负载均衡组件了作者回复: api网关只负责网关->微服务的链路，但是基于服务发现构建的微服务架构里，微服务之间互相调用是不经过网关的
2022-01-2029
何衍其// 当前服务的集群名称 String clusterName = environment.resolvePlaceholders("${spring.cloud.nacos.discovery.cluster-name:}"); // 服务实列所属集群名称 serviceInstance.getMetadata().get("nacos.cluster");作者回复: 非常正确，metadata里面包罗万象
2022-04-1328
~说一下思考题我的思路： 从 CanaryRule 就可以看出来了，其实实现负载均衡的逻辑就在getRoundRobinInstance中，我们只需要改造这里就可以了。我的想法是设置一个缓存（map 也好，其他的也好），存放上次选择出的 serverInstance，如果是第一次选择，那么使用老逻辑选出一个，如果上次选择的服务已经不可用了，就从缓存中清除，重新选一个就可以了。 补充2点： 1. 怎么判断一个服务是否可用？其实在这里的代码中，传入的 List<ServiceInstance> 参数就是从 nacos 中获取到的可用服务的列表。那么只需要判断缓存中存放的 serviceInstance 是否也在 list 中就可以了。具体怎么获取到可用服务列表的，需要进一步查看源码才能了解。 2. 仅做一个猜想，不具有实际意义，老师如果能解答也再好不过了：能否直接在获取可用服务列表那步就直接确定一个服务？其他的逻辑也是如此。就算可行其实设计上也是不合理的，因为获取可用服务的代码就应该只负责相关逻辑，负载均衡代码就应该只管负载均衡。提出这个猜想只不过是想对源码有进一步了解，设计上还是各司其职更合理。 以上就是我的思考，附上代码（超过字数限制了，放在我的留言的回复里了），如果有问题，欢迎指出问题~作者回复: 同学是一个爱思考的三好学生，非常不错。我思考题里面埋了一个机关是“集群优先”，所以这里还需要判定一下当前instance所属的集群是否与当前这台服务器一致，当前服务的集群可以从配置文件中读取，而instance的集群其实被封装到了每个instance的metadata里，可以从中读取并比较
2022-01-1635
Yarnbo姚总好，学习了您的本节课受益匪浅。虽然照葫芦画瓢也实现了“优先调用同一个 Cluster 的服务器”，但是这样做的意义有哪些，能结合您的经验介绍下吗？（我能盲猜到的是，假如服务以集群为基本单元提供服务能力，将来方便弹性扩展机器）作者回复: 同学都说出正确答案了，没错，其实“优先调用同一个cluster”是一种最简单的单元化能力。假设前置网关能根据用户location等条件做单元调用（淘系用户就分单元/中心机房等等），比如说江浙沪的用户请求进上海机房，相对应的全链路缓存都构建再同一个机房，那么将打到单元A的流量只在内部做流转能降低请求响应时间
2022-09-29归属地：上海1
二饼
Nacos-服务管理-服务列表-开发环境 `coupon-template-serv` 只有一个实例，不是两个，我又把前面的文章看了一遍，没有发现什么地方又说定义了两个实例，和示例代码比对了一下配置文件没看出什么问题，请教一下老师我这是什么造成的？作者回复: 同学要在本地换一个端口再启动一个coupon-template-serv服务，确保有两个同名但占用端口不同的服务启动并注册
2022-08-21归属地：上海21
胖子菜dubbo整合了nacos后，因为我用的最新版本的nacos没有自带ribbon,我又引入了loadbalancer依赖，我想问下dubbo有负载均衡机制，loadbancer也有，他们冲突么，谁会生效呢作者回复: 我一般是直接用dubbo原生的负载均衡策略，spring cloud自带的loadbalancer其实功能性还不如ribbon，内置的负载均衡策略也没得比，完全是为了去netflix化搞的这么个玩意儿
2022-05-071
靠人品去赢像金丝雀这些线上验证，会产生线上数据，万一没搞好打标打错了或者没配置好，导入到正常服务的机器上没有到金丝雀上，怎么辨别消除影响呢？作者回复: 万一打标错了，一个最好的方案就是扣打标的那个人的年终奖吧。 金丝雀可以只打线上测试流量，下单商品也打上测试标，即使产生影响也不影响线上真实客户
2022-04-011
rrbbt老师能详细讲一下这句话吗？没太看懂，为什么不应用到全局？不加@Configuration就能不应用到全局吗？===========[原文]"因为我不希望把这个负载均衡策略应用到全局，所以我没有为这个配置类添加 @Configuration 注解"作者回复: configuration注解内部包含了Component注解，加上之后这个类就会在被spring容器“盯上”，进而将里面声明的bean初始化后作用于全局。所以我在代码中使用了一种“指定配置项”的方式，让这个类只服务于指定的service
2023-06-24归属地：山东
