深圳市城乡建设部网站首页,wordpress 带水印,电商设计属于什么行业,标签云 wordpress 插件最近很久没有写文章啦#xff0c;刚好遇到了一个问题#xff0c;其实问题也挺简单#xff0c;但是还是得对源码有一定了解才能够发现。
最近在实现一个根据请求流量的标签#xff0c;将请求转发到对应的节点#xff0c;其实和俗称的灰度请求有点相似#xff0c;
实现思…最近很久没有写文章啦刚好遇到了一个问题其实问题也挺简单但是还是得对源码有一定了解才能够发现。
最近在实现一个根据请求流量的标签将请求转发到对应的节点其实和俗称的灰度请求有点相似
实现思路如下
首先为特定节点打上标签通过截取请求中的header的标签key然后存入上下文中在服务转发时Feign在负载均衡步骤前将节点的标签和请求标签相匹配筛选出标签节点。将标签节点进行策略选择一个合适的节点然后转发。
场景定义
实现伪代码
定义策略
public class MyRule extends AbstractLoadBalancerRule {Overridepublic void initWithNiwsConfig(IClientConfig iClientConfig) {}Overridepublic Server choose(Object o) {return this.choose(this.getLoadBalancer(),o);}public Server choose(ILoadBalancer lb, Object key) {// 标签匹配// 节点选择// 策略选举return server;}}
}注入容器
Configuration
public class MyRuleConfig {Beanpublic IRule ribbonRule(){return new MyRule();}
}好一切准备就绪。
在应用当中很快就遇到了问题在选择过程中节点地址出现错乱。 明明请求的是A服务节点结果转发的是B节点 通过调试发现ILoadBalancer对象有问题比如A服务节点持有的节点列表竟然是B的节点列表。
ILoadBalancer 每个服务都独立持有一个独属于该服务负载列表。比如A服务持有的就是A服务列表,B就是B的. 但此时却出现了归属于A的ILoadBalancer中节点列表竟然都是B的。
原因梳理
最终排查发现就是注入的方式问题为什么这么说呢
由于服务节点在初始化的过程中都是以服务名作为一个独立配置存在于容器中的如下图
用户服务单独有一套负载均衡规则IRule同理order订单服务也是单独一套负载均衡规则双方各自持有了各自的服务列表ILoadBalancer。
但是由于我们要改写IRule的实现同时注入到容器中让服务能够获取到我改写的实现我们直接Bean给加入了。
此时在初始化这个IRule的时候就会出现问题因为IRule内部是持有ILoadBalancer的但是ILoadBalancer针对每个服务都是不一样的。
我们看一下IRule是怎么被加载到用户服务上下文的 com.netflix.loadbalancer.BaseLoadBalancer#setRule
public void setRule(IRule rule) {if (rule ! null) { // 此时我们是从容器获取到的默认是个单例this.rule rule;} else {/* default rule */this.rule new RoundRobinRule();}if (this.rule.getLoadBalancer() ! this) { // 肯定满足// 将自身交给rulethis.rule.setLoadBalancer(this);}
}别忘了,我们通过Bean加入到容器中时是单例的。问题也出在这 就意味着每次初始化的时候在设置setLoadBalancer时就是在单例的IRule基础上从后往前覆盖最终IRule持有的永远都是最后一个服务的服务列表。
大意图就是这个样子
问题解决
那么我们如何解决这个问题呢 我们知道了原因是由于单例导致的那么我们就可以将自定义的策略改成多实例的注入。
Configuration
public class MyRuleConfig {BeanScope(prototype) // 将单例变为原型public IRule ribbonRule(){return new MyRule();}
}此时每次获取都是一个新的对象相互不在影响。同理你如果需要覆盖RibbonClientConfiguration配置类中的对象时也需要避免使用单例模式去定义它
