上一篇我们介绍了如何使用Ribbon的earger-load配置加速Spring Cloud中对服务接口的第一次调用。可是这样只是解决了内部服务间的调用，另外一个问题依然经常困扰我们，那就是网关到内部服务的访问。由于Spring Cloud Zuul的路由转发也是通过Ribbon实现负载均衡的，所以它也会存在第一次调时比较慢的情况。那么这个时候我们要如何设置呢？ Zuul中的Eager Load配置在Spring Cloud Zuul中也提供了一个配置参数来实现earger-load，具体如下： zuul.ribbon.eager-load.enabled=true 但是，可能你尝试一下之后会发现，并没有起效？为什么呢？这是由于Spring Cloud Zuul中实现eager-load的时候同Ribbon中一样，都需要指定具体哪些服务需要饥饿加载。那么在Spring Cloud...

我们在使用Spring Cloud的Ribbon或Feign来实现服务调用的时候，如果我们的机器或网络环境等原因不是很好的话，有时候会发现这样一个问题：我们服务消费方调用服务提供方接口的时候，第一次请求经常会超时，而之后的调用就没有问题了。下面我们就来说说造成这个问题的原因，以及如何解决的方法。 问题原因造成第一次服务调用出现失败的原因主要是Ribbon进行客户端负载均衡的Client并不是在服务启动的时候就初始化好的，而是在调用的时候才会去创建相应的Client，所以第一次调用的耗时不仅仅包含发送HTTP请求的时间，还包含了创建RibbonClient的时间，这样一来如果创建时间速度较慢，同时设置的超时时间又比较短的话，很容易就会出现上面所描述的显现。 从日志中我们也能知道这一点细节，在第一次发起调用的时候我们可以从日志中看到如下信息： 2017-09-25 08:29:54,...

当我们使用Spring Cloud Ribbon实现客户端负载均衡的时候，通常都会利用@LoadBalanced来让RestTemplate具备客户端负载功能，从而实现面向服务名的接口访问（原理可见《Spring Cloud源码分析（二）Ribbon》一文，如果对Spring Cloud中使用Ribbon进行服务消费还没有概念的话，建议先阅读《Spring Cloud构建微服务架构（二）服务消费者》一文。）。 下面的例子，实现了对服务名为hello-service的/hello接口的调用。由于RestTemplate被@LoadBalanced修饰，所以它具备客户端负载均衡的能力，当请求真正发起的时候，url中的服务名会根据负载均衡策略从服务清单中挑选出一个实例来进行访问。 @SpringCloudApplicationpublic class Application { ...

断断续续看Ribbon的源码差不多也有7-8天了，总算告一段落。本文记录了这些天对源码的阅读过程与一些分析理解，如有不对还请指出。 友情提示：本文较长，请选择一个较为舒适的姿势来阅读在之前介绍使用Ribbon进行服务消费的时候，我们用到了RestTemplate，但是熟悉Spring的同学们是否产生过这样的疑问：RestTemplate不是Spring自己就有的吗？跟Ribbon的客户端负载均衡又有什么关系呢？下面在本文，我们来看RestTemplate和Ribbon是如何联系起来并实现客户端负载均衡的。 首先，回顾一下之前的消费者示例：我们是如何实现客户端负载均衡的？仔细观察一下代码之前的代码，我们可以发现在消费者的例子中，可能就是这个注解@LoadBalanced是之前没有接触过的，并且从命名上来看也与负载均衡相关。我们不妨以此为线索来看看源码实现的机制。 从@LoadBal...

在上一篇《Spring Cloud构建微服务架构（一）服务注册与发现》中，我们已经成功创建了“服务注册中心”，实现并注册了一个“服务提供者：COMPUTE-SERVICE”。那么我们要如何去消费服务提供者的接口内容呢？ RibbonRibbon是一个基于HTTP和TCP客户端的负载均衡器。Feign中也使用Ribbon，后续会介绍Feign的使用。 Ribbon可以在通过客户端中配置的ribbonServerList服务端列表去轮询访问以达到均衡负载的作用。 当Ribbon与Eureka联合使用时，ribbonServerList会被DiscoveryEnabledNIWSServerList重写，扩展成从Eureka注册中心中获取服务端列表。同时它也会用NIWSDiscoveryPing来取代IPing，它将职责委托给Eureka来确定服务端是否已经启动。 下面我们通过实例看看如何...