首先我给大家看一张图，如果大家对这张图有些地方不太理解的话，我希望你们看完我这篇文章会恍然大悟。

什么是 Spring cloud

构建分布式系统不需要复杂和容易出错。Spring Cloud 为最常见的分布式系统模式提供了一种简单且易于接受的编程模型，帮助开发人员构建有弹性的、可靠的、协调的应用程序。Spring Cloud 构建于 Spring Boot 之上，使得开发者很容易入手并快速应用于生产中。

官方果然官方，介绍都这么有板有眼的。

我所理解的Spring Cloud就是微服务系统架构的一站式解决方案，在平时我们构建微服务的过程中需要做如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等操作，而 Spring Cloud 为我们提供了一套简易的编程模型，使我们能在 Spring Boot 的基础上轻松地实现微服务项目的构建。

Spring Cloud 的版本

当然这个只是个题外话。

Spring Cloud 的版本号并不是我们通常见的数字版本号，而是一些很奇怪的单词。这些单词均为英国伦敦地铁站的站名。同时根据字母表的顺序来对应版本时间顺序，比如：最早 的 Release 版本 Angel，第二个 Release 版本 Brixton（英国地名），然后是 Camden、 Dalston、Edgware、Finchley、Greenwich、Hoxton。

Spring Cloud 的服务发现框架——Eureka

Eureka是基于REST（代表性状态转移）的服务，主要在AWS云中用于定位服务，以实现负载均衡和中间层服务器的故障转移。我们称此服务为Eureka服务器。Eureka还带有一个基于Java的客户端组件Eureka Client，它使与服务的交互变得更加容易。客户端还具有一个内置的负载平衡器，可以执行基本的循环负载平衡。在Netflix，更复杂的负载均衡器将Eureka包装起来，以基于流量，资源使用，错误条件等多种因素提供加权负载均衡，以提供出色的弹性。

总的来说，Eureka 就是一个服务发现框架。何为服务，何又为发现呢？

举一个生活中的例子，就比如我们平时租房子找中介的事情。

在没有中介的时候我们需要一个一个去寻找是否有房屋要出租的房东，这显然会非常的费力，一你找凭一个人的能力是找不到很多房源供你选择，再者你也懒得这么找下去(找了这么久，没有合适的只能将就)。这里的我们就相当于微服务中的Consumer，而那些房东就相当于微服务中的Provider。消费者Consumer需要调用提供者Provider提供的一些服务，就像我们现在需要租他们的房子一样。

但是如果只是租客和房东之间进行寻找的话，他们的效率是很低的，房东找不到租客赚不到钱，租客找不到房东住不了房。所以，后来房东肯定就想到了广播自己的房源信息(比如在街边贴贴小广告)，这样对于房东来说已经完成他的任务(将房源公布出去)，但是有两个问题就出现了。第一、其他不是租客的都能收到这种租房消息，这在现实世界没什么，但是在计算机的世界中就会出现资源消耗的问题了。第二、租客这样还是很难找到你，试想一下我需要租房，我还需要东一个西一个地去找街边小广告，麻不麻烦？

那怎么办呢？我们当然不会那么傻乎乎的，第一时间就是去找中介呀，它为我们提供了统一房源的地方，我们消费者只需要跑到它那里去找就行了。而对于房东来说，他们也只需要把房源在中介那里发布就行了。

那么现在，我们的模式就是这样的了。

但是，这个时候还会出现一些问题。

1. 房东注册之后如果不想卖房子了怎么办？我们是不是需要让房东定期续约？如果房东不进行续约是不是要将他们从中介那里的注册列表中移除。
2. 租客是不是也要进行注册呢？不然合同乙方怎么来呢？
3. 中介可不可以做连锁店呢？如果这一个店因为某些不可抗力因素而无法使用，那么我们是否可以换一个连锁店呢？

针对上面的问题我们来重新构建一下上面的模式图

好了，举完这个我们就可以来看关于 Eureka 的一些基础概念了，你会发现这东西理解起来怎么这么简单。

服务发现：其实就是一个“中介”，整个过程中有三个角色：服务提供者(出租房子的)、服务消费者(租客)、服务中介(房屋中介)。

服务提供者：就是提供一些自己能够执行的一些服务给外界。

服务消费者：就是需要使用一些服务的“用户”。

服务中介：其实就是服务提供者和服务消费者之间的“桥梁”，服务提供者可以把自己注册到服务中介那里，而服务消费者如需要消费一些服务(使用一些功能)就可以在服务中介中寻找注册在服务中介的服务提供者。

服务注册 Register：

官方解释：当 Eureka 客户端向[Eureka] Server注册时，它提供自身的元数据，比如IP地址、端口，运行状况指示符URL，主页等。

结合中介理解：房东 (提供者[Eureka] Client Provider)在中介 (服务器[Eureka] Server) 那里登记房屋的信息，比如面积，价格，地段等等(元数据metaData)。

服务续约 Renew：

官方解释：Eureka 客户会每隔30秒(默认情况下)发送一次心跳来续约。通过续约来告知[Eureka] Server该 Eureka 客户仍然存在，没有出现问题。正常情况下，如果[Eureka] Server在90秒没有收到 Eureka 客户的续约，它会将实例从其注册表中删除。

结合中介理解：房东 (提供者[Eureka] Client Provider) 定期告诉中介 (服务器[Eureka] Server) 我的房子还租(续约) ，中介 (服务器[Eureka] Server) 收到之后继续保留房屋的信息。

获取注册列表信息 Fetch Registries：

官方解释：Eureka 客户端从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟）更新一次。每次返回注册列表信息可能与 Eureka 客户端的缓存信息不同, Eureka 客户端自动处理。如果由于某种原因导致注册列表信息不能及时匹配，Eureka 客户端则会重新获取整个注册表信息。Eureka 服务器缓存注册列表信息，整个注册表以及每个应用程序的信息进行了压缩，压缩内容和没有压缩的内容完全相同。Eureka 客户端和 Eureka 服务器可以使用JSON / XML格式进行通讯。在默认的情况下 Eureka 客户端使用压缩JSON格式来获取注册列表的信息。

结合中介理解：租客(消费者[Eureka] Client Consumer) 去中介 (服务器[Eureka] Server) 那里获取所有的房屋信息列表 (客户端列表[Eureka] Client List) ，而且租客为了获取最新的信息会定期向中介 (服务器[Eureka] Server) 那里获取并更新本地列表。

服务下线 Cancel：

官方解释：Eureka客户端在程序关闭时向Eureka服务器发送取消请求。发送请求后，该客户端实例信息将从服务器的实例注册表中删除。该下线请求不会自动完成，它需要调用以下内容：DiscoveryManager.getInstance().shutdownComponent();

结合中介理解：房东 (提供者[Eureka] Client Provider) 告诉中介 (服务器[Eureka] Server) 我的房子不租了，中介之后就将注册的房屋信息从列表中剔除。

服务剔除 Eviction：

官方解释：在默认的情况下，当Eureka客户端连续90秒(3个续约周期)没有向Eureka服务器发送服务续约，即心跳，Eureka服务器会将该服务实例从服务注册列表删除，即服务剔除。

结合中介理解：房东(提供者[Eureka] Client Provider) 会定期联系 中介 (服务器[Eureka] Server) 告诉他我的房子还租(续约)，如果中介 (服务器[Eureka] Server) 长时间没收到提供者的信息，那么中介会将他的房屋信息给下架(服务剔除)。

下面就是Netflix官方给出的 Eureka 架构图，你会发现和我们前面画的中介图别无二致。

当然，可以充当服务发现的组件有很多：Zookeeper，Consul， Eureka 等。

更多关于 Eureka 的知识(自我保护，初始注册策略等等)可以自己去官网查看

负载均衡之 Ribbon
什么是 RestTemplate?

不是讲Ribbon么？怎么扯到了RestTemplate了？你先别急，听我慢慢道来。更多的关于设计，原理知识点的问题，可以在码匠笔记后台回复实践获取。

我不听我不听我不听。

我就说一句！RestTemplate是Spring提供的一个访问Http服务的客户端类，怎么说呢？就是微服务之间的调用是使用的RestTemplate。比如这个时候我们 消费者B 需要调用 提供者A 所提供的服务我们就需要这么写。如我下面的伪代码

@Autowiredprivate RestTemplate restTemplate;// 这里是提供者A的ip地址，但是如果使用了 Eureka 那么就应该是提供者A的名称private static final String SERVICE_PROVIDER_A = "http://localhost:8081";@PostMapping("/judge")public boolean judge(@RequestBody Request request) {    String url = SERVICE_PROVIDER_A + "/service1";    return restTemplate.postForObject(url, request, Boolean.class);}

如果你对源码感兴趣的话，你会发现上面我们所讲的 Eureka 框架中的注册、续约等，底层都是使用的RestTemplate。

为什么需要 Ribbon？

Ribbon 是Netflix公司的一个开源的负载均衡 项目，是一个客户端/进程内负载均衡器，运行在消费者端。

我们再举个，比如我们设计了一个秒杀系统，但是为了整个系统的高可用，我们需要将这个系统做一个集群，而这个时候我们消费者就可以拥有多个秒杀系统的调用途径了，如下图。

如果这个时候我们没有进行一些均衡操作，如果我们对秒杀系统1进行大量的调用，而另外两个基本不请求，就会导致秒杀系统1崩溃，而另外两个就变成了傀儡，那么我们为什么还要做集群，我们高可用体现的意义又在哪呢？

所以Ribbon出现了，注意我们上面加粗的几个字——运行在消费者端。指的是，Ribbon是运行在消费者端的负载均衡器，如下图。

其工作原理就是Consumer端获取到了所有的服务列表之后，在其内部使用负载均衡算法，进行对多个系统的调用。

Nginx 和 Ribbon 的对比

提到负载均衡就不得不提到大名鼎鼎的Nignx了，而和Ribbon不同的是，它是一种集中式的负载均衡器。

何为集中式呢？简单理解就是将所有请求都集中起来，然后再进行负载均衡。如下图。

我们可以看到Nginx是接收了所有的请求进行负载均衡的，而对于Ribbon来说它是在消费者端进行的负载均衡。如下图。

请注意Request的位置，在Nginx中请求是先进入负载均衡器，而在Ribbon中是先在客户端进行负载均衡才进行请求的。

Ribbon 的几种负载均衡算法

负载均衡，不管Nginx还是Ribbon都需要其算法的支持，如果我没记错的话Nginx使用的是 轮询和加权轮询算法。而在Ribbon中有更多的负载均衡调度算法，其默认是使用的RoundRobinRule轮询策略。

• RoundRobinRule：轮询策略。Ribbon默认采用的策略。若经过一轮轮询没有找到可用的provider，其最多轮询 10 轮。若最终还没有找到，则返回 null。
• RandomRule: 随机策略，从所有可用的 provider 中随机选择一个。
• RetryRule: 重试策略。先按照 RoundRobinRule 策略获取 provider，若获取失败，则在指定的时限内重试。默认的时限为 500 毫秒。

还有很多，这里不一一举了，你最需要知道的是默认轮询算法，并且可以更换默认的负载均衡算法，只需要在配置文件中做出修改就行。

providerName:  ribbon:    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

当然，在Ribbon中你还可以自定义负载均衡算法，你只需要实现IRule接口，然后修改配置文件或者自定义Java Config类。