设计网站室内网站建设所需的硬件设备

当前位置： 首页 > news >正文

设计网站室内,网站建设所需的硬件设备,极速网站建设多少钱,大气企业网站欣赏微服务#xff08;4#xff09; 文章目录 微服务#xff08;4#xff09;1. 负载均衡原理2. 源码跟踪1#xff09;LoadBalancerIntercepor2#xff09;LoadBalancerClient3#xff09;负载均衡策略IRule4#xff09;总结 3. 负载均衡策略3.1 负载均衡策略3.2 自定义负载… 微服务4 文章目录 微服务41. 负载均衡原理2. 源码跟踪1LoadBalancerIntercepor2LoadBalancerClient3负载均衡策略IRule4总结 3. 负载均衡策略3.1 负载均衡策略3.2 自定义负载均衡策略 4. 饥饿加载 微服务4 在前面我们添加了LoadBalanced注解即可实现负载均衡功能这是什么原理、什么策略呢

1. 负载均衡原理 SpringCloud底层其实是利用了一个名为Ribbon的组件来实现负载均衡功能的。 那么我们发出的请求明明是http://userservice/user/1怎么变成了http://localhost:8081的呢
2. 源码跟踪 为什么我们只输入了service名称就可以访问了呢之前还要获取ip和端口。 Ribbon是怎么拦截这个请求并将url进行处理的呢 显然有人帮我们根据service名称获取到了服务实例的ip和端口。它就是LoadBalancerInterceptor这个类会在对RestTemplate的请求进行拦截然后从Eureka根据服务id获取服务列表随后利用负载均衡算法得到真实的服务地址信息替换服务id。 我们进行源码跟踪双击shift搜索 1LoadBalancerIntercepor 调试一下 打个断点 浏览器访问 停在这了 跳两步观察 可以看到这里的intercept方法拦截了用户的HttpRequest请求然后做了几件事 request.getURI()获取请求uri本例中就是 http://userservice/user/1originalUri.getHost()获取uri路径的主机名其实就是服务id名称userservicethis.loadBalancer.execute()处理服务id名称和用户请求。 这里的this.loadBalancer是LoadBalancerClient类型我们继续跟入。 2LoadBalancerClient 继续跟入execute方法调用getLoadBalancer方法 调用getServer方法 这个就是我们的内网ip命令行cmdipconfig查看 代码是这样的 getLoadBalancer(serviceId)根据服务id获取ILoadBalancer而ILoadBalancer会拿着服务id去eureka中获取服务列表并保存起来。getServer(loadBalancer)利用内置的负载均衡算法从服务列表中选择一个。本例中可以看到获取了8081端口的服务 放行后再次访问并跟踪发现获取的是8082 果然实现了负载均衡。 3负载均衡策略IRule 跟进getServer方法 进入方法内部 通过规则选择 IRule故名思意就是规则接口想必就是负载均衡算法的规则取决于它 可见IRule接口有很多的实现 最明显的就是RandomRule顾名思义就是随机RoundRobinRule顾名思义就是轮询调度 而现在的规则是ZoneAvoidanceRule key是default其实就是尝试从配置文件里获取常量没有配置就获取不到就默认咯 我们看看这个rule是谁 这不就是轮询的意思嘛。 到这里整个负载均衡的流程我们就清楚了至于这些策略规则是什么随后讲解~ 4总结 SpringCloudRibbon的底层采用了一个拦截器拦截了RestTemplate发出的请求对地址做了修改。用一幅图来总结一下 基本流程如下 拦截我们的RestTemplate请求http://userservice/user/1RibbonLoadBalancerClient会从请求url中获取服务名称也就是userserviceDynamicServerListLoadBalancer根据userservice到eureka拉取服务列表eureka返回列表localhost:8081、localhost:8082IRule利用内置负载均衡规则从列表中选择一个例如localhost:8081RibbonLoadBalancerClient修改请求地址用localhost:8081替代userservice得到http://localhost:8081/user/1发起真实请求
3. 负载均衡策略 3.1 负载均衡策略 负载均衡的规则都定义在IRule接口中而IRule有很多不同的实现类 不同规则的含义如下 内置负载均衡规则类规则描述RoundRobinRule简单轮询服务列表来选择服务器。AvailabilityFilteringRule对以下两种服务器进行忽略 1在默认情况下这台服务器如果3次连接失败这台服务器就会被设置为“短路”状态。短路状态将持续30秒如果再次连接失败短路的持续时间就会几何级地增加。 2并发数过高的服务器。如果一个服务器的并发连接数过高配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限可以由客户端的..ActiveConnectionsLimit属性进行配置。WeightedResponseTimeRule为每一个服务器赋予一个权重值。服务器响应时间越长这个服务器的权重就越小。这个规则会随机选择服务器这个权重值会影响服务器的选择。ZoneAvoidanceRule以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。如果没有Zone的划分其实就是跟普通轮询没啥区别BestAvailableRule忽略那些短路的服务器并选择并发数较低的服务器。RandomRule随机选择一个可用的服务器。RetryRule重试机制的选择逻辑 默认的实现就是ZoneAvoidanceRule是一种轮询方案 默认情况下浏览器依次访问101、102、103、104查看日志右侧栏有个垃圾桶点击清空日志 其实每次都这样一个2 4一个1 3就是轮询策略~ 3.2 自定义负载均衡策略 通过定义IRule实现可以修改负载均衡规则有两种方式 代码方式在order-service中的OrderApplication类中定义一个新的IRule 那么ribbon就会以这个bean的规则优先
   Bean public IRule randomRule(){return new RandomRule(); }效果 每次都不一样甚至会出现有一个服务一个都没有很明显是随机次数多了还每个服务的调用次数是很均衡的 配置文件方式在order-service的application.yml文件中添加新的配置也可以修改规则 userservice: # 给某个微服务配置负载均衡规则这里是userservice服务ribbon:NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则 效果一致~ 注意一般用默认的负载均衡规则不做修改。 配置文件的设置优先级较高如果代码方法设置的是A配置方法设置的是B则最终呈现是B代码设置的是全局的方案也就是说在order-service访问哪个微服务的都是这个规则配置设置的是特定的微服务负载均衡规则优先级高也正常了 从配置设置的键userservice可见是针对一个微服务的 4. 饥饿加载 不知道你有没有发现我们浏览器测试刚才的用例的时候第一次要反应一会儿后面的就很流畅 我们通过浏览器开发者工具来看看第一次访问的时候的时间 达到恐怖的744ms 而之后就比较快了 这是因为 Ribbon默认是采用懒加载即第一次访问时才会去创建LoadBalanceClient请求时间会很长。 严格来说是第一次用到这个服务的LoadBalanceClient才会加载加载之后就缓存下来了可以直接用或者下一次拉取直接赋值给这个对象就行了 当然如果是别的服务的LoadBalanceClient还需要加载
   而饥饿加载则会在项目启动时创建降低第一次访问的耗时通过下面配置开启饥饿加载 ribbon:eager-load:enabled: true # 默认false为懒加载这里设置为true为饥饿加载clients: userservice # 指定对哪个微服务饥饿加载clients的值是一个集合可以这么写 重启 可见已经加载 观察一下时间 第一次访问快了不少了第一次也要加载一些框架之类的当然也可以设置为饥饿加载不在这里演示 文章到此结束谢谢观看 可以叫我 小马我可能写的不好或者有错误但是一起加油鸭 代码cloud-demo · 游离态/云服务 - 码云 - 开源中国 (gitee.com)