在springcloud中，引入Ribbon来作为客户端时，负载均衡使用的是被@LoadBalanced修饰的RestTemplate对象。
RestTemplate详细的用法
- GET请求
第一种方式
返回ResponseEntity，该对象是Spring对HTTP请求响应的封装，其中主要存储了HTTP的几个重要元素，HttpStatus代表了错误码如404,500等。以及HttpHeaders代表了请求头，body代表了接收到的对象，其类型是根据第二个参数决定的。第一个url为请求地址，可以使用{1}占位符，而参数的值在该方法的最后的可变参数。
ResponseEntity<String> forEntity = restTemplate.getForEntity("http://eureka-client/hello",String.class);
String body = forEntity.getBody();
HttpHeaders headers = forEntity.getHeaders();
HttpStatus statusCode = forEntity.getStatusCode();
三个重载方法：
getForEntity(String url,Class responseType,Object... urlVariables);
getForEntity(String url,Class responseType,Map urlVariables);
getForEntity(URI url,Class responseType);
第二种方式
String forObject = restTemplate.getForObject("http://eureka-client/hello", String.class);
第二种方式与第一种方式唯一的不同就是getForObject的返回值类型直接就是参数列表的第二个参数指定的类型，所以这种方式没法获取错误码和请求头等信息。
RestTemplate本来是Spring提供的发送REST请求的工具类，但是当其被@LoadBalanced注解修饰后，通过其发送REST请求，会被LoadBalanceInterceptor类的inteceptor拦截，然后进行一些负载均衡和请求地址的转换。
负载均衡策略
通过继承AbstractLoadBalancerRule抽象类来具体实现负载均衡策略。
RandomRule
通过随机服务实例的数量来产生一个随机数，通过索引获取该服务实例
RoundRobinRule
按照线性轮询的方式依次选择每个服务实例的功能
RetryRule
该策略实现了一个具备重试机制的实例选择功能。其内部还定义了一个IRule对象，默认使用RoundRobinRule实例。在choose方法中则实现了对内部定义的策略进行反复尝试的策略，若期间能够选择到具体的服务实例就返回，若选择不到就根据设置的尝试结束时间为阀值（maxRetryMillis参数定义的值+choose方法开始执行是的时间戳），当超过该值后就返回null
WeightedResponseTimeRule
该策略是对RoundRobinRule的扩展，增加了根据实例的运行情况来计数权重，并根据权重来挑选实例。该策略实例化的时候在内部创建了一个定时任务，每过30s便去统计一下各个实例的权重。
ClientConfigEnableRoundRobinRule
该策略较为特殊，一般不直接使用它。该策略内部定义了一个RoundRobinRule策略，choose函数的实现也是使用了RoundRobinRule的线下轮询机制。一般使用方法：继承该策略，默认的choose方法实现了线性轮询机制，在子类中做一些高级策略时通常可能会存在一些无法实施的情况，那么就可以用父类的实现作为备选。
BestAvailableRule
该策略继承ClientConfigEnableRoundRobinRule，在实现中它注入了负载均衡器的统计对象LoadBalancerStats，同时在具体的choose算法中利用LoadBalancerStats保存的实例统计信息来满足要求的实例。它通过遍历负载均衡器中维护的所有服务实例，会过滤掉故障的实例，并找出并发请求数最少的一个，所以该策略的特性是可选出最空闲的实例。
PredicateBasedRule
抽象策略，继承了ClientConfigEnableRoundRobinRule，基于Predicate实现的策略，Predicate是Google Guava Collection工具对集合进行过滤的条件接口，策略：先过滤清单，在轮询选择
AvailableFilteringRule
继承自PredicationBasedRule
ZoneAvoidanceRule
继承自PredicationBasedRule
重试
spring cloud eureka比较注重可用性，所以在极端情况下，它宁愿接收故障实例也不会丢掉“健康”实例，比如当服务注册中心的网络发生故障断开时，由于所有的服务实例无法持续维持心跳，一般的服务治理会将所有的服务实例剔除，但是eureka则会因为超过85%的实例丢失心跳而触发保护机制，注册中心将会保留此时的所有节点，以实现服务间依然可以进行互相调用的场景，即使其中有部分故障节点，但这样做可以继续保障大多数的服务正常消费。
由于spring cloud eureka咋可用性与一致性上的取舍，所以我们在实现服务调用的时候通常会加入一些重试机制。spring cloud 整合了spring retry来增强RestTemplate的重试能力，只需通过简单的配置，原来那些通过RestTemplate实现的服务访问就会自动根据配置来实现重试策略。
spring.cloud.loadbalancer.retry.enabled=true
#开启重试机制
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000
#断路器的超时时间需要大于Ribbon的超时时间，不然不会触发重试
eureka-consumer.ribbon.ConnectTimeout=250
#请求连接的超时时间
eureka-consumer.ribbon.ReadTimeout=1000
#请求处理的超时时间
eureka-consumer.ribbon.OkToRetryOnAllOperations=true
#对所有操作请求都进行重试
eureka-consumer.ribbon.MaxAutoRetriesNextServer=2
#切换实例的重试次数
eureka-consumer.ribbon.MaxAutoRetries=1
#对当前实例的重试次数
当访问到故障请求的时候，它会在尝试访问一次当前实例（次数由MaxAutoRetries配置），如果不行，就换一个实例进行访问，如果还是不行，在换一次实例访问（更换次数由MaxAutoRetriesNextServer配置），如果依然不行，在返回失败信息。
