深入明白微服务中的负载均衡算法与配置策略

上一期我们详细探讨了微服务之间的通信，特别是先容了如何集成Ribbon。简单来说，通过使用resttemplate类举行RPC调用时，我们内部增长了一个拦截器来实现负载均衡。然而，我们并未深入讨论具体的负载均衡算法。因此，本章节的重点是先容如何从多个副本中选择合适的节点举行服务调用。这将帮助大家更好地明白在微服务架构中如何有效地实现负载均衡。
好的，今天我们依旧会涉及源码，但盼望大家能把注意力会集在理念层面，而不是穷究每个具体的过程调用。无需纠结于代码的具体行数，因为紧张的是明白整体架构和流程，如许才能更好地掌握主题的实质。
负载均衡算法

我们起首来探讨一下默认情况下Ribbon使用的负载均衡算法。有些人可能会说它使用轮询算法，因为在本地测试时，我们常常会看到轮询的效果。然而，简单地依赖这种外貌的观察来答复口试题是有风险的。实际上，忽略了深入明白源代码可能会导致严重的误解。
尽管实践是增长知识的一部分，但是在真实的生产情况中，尤其是跨多个数据中央部署的情况下，我们无法简单地将问题简化为本地集群的测试情况。
获取服务器ip

我们接着上一篇内容，讨论如何选择服务器的步骤如下复述：

1.     public <T> T execute(String serviceId, LoadBalancerRequest<T> request, Object hint)
2.             throws IOException {
3.         ILoadBalancer loadBalancer = getLoadBalancer(serviceId);
4.         Server server = getServer(loadBalancer, hint);
5.         if (server == null) {
6.             throw new IllegalStateException("No instances available for " + serviceId);
7.         }
8.         RibbonServer ribbonServer = new RibbonServer(serviceId, server,
9.                 isSecure(server, serviceId),
10.                 serverIntrospector(serviceId).getMetadata(server));
12.         return execute(serviceId, ribbonServer, request);
13.     }

复制代码

获取负载均衡器——ZoneAwareLoadBalancer

我们来看看getServer方法，突然间出现这么多负载均衡器，应该怎么处理呢？这时候最好的方法就是查看主动配置，看看哪些被注入进来了。

中间步骤大家就不消再找了，我已经事先找好了，就在这里：

这张图包含两个关键信息：起首是注入了一个IRule规则，其次是将该IRule规则应用到了ZoneAwareLoadBalancer负载均衡器中。好的，现在我们清楚了接下来的步骤。接下来我们继续查看
[code]    public Server chooseServer(Object key) {        if (!ENABLED.get() || getLoadBalancerStats().getAvailableZones().size()