我在spring boot & spring cloud关系？里曾说到下次讲spring cloud的核心组件。那为什么说到spring cloud就要提到spring cloud的核心组件呢？

spring cloud都提供了分布式系统一整套解决方案。相信大家刚接触微服务，刚接触spring cloud的时候，经常会看到这句话吧。那这句话究竟是什么意思？什么叫分布式系统？什么又叫一整套解决方案呢？

什么是分布式系统？

简单来说，一个项目变的越来越大后，越来越难维护。然后就会把一个项目拆成多个项目或者叫服务。这样一个大项目大系统就变成了分布式系统。项目和服务间的差别大概是大小间的差别吧。微服务应该比分布式系统拆分的粒度更小吧。慢慢的，分布式系统和微服务差别不大吧，或者说微服务本来就是属于分布式系统。一个微服务也相当于是一个系统。

什么又叫一整套解决方案？

一整套解决方案是针对一个完整的系统来说的。一个大型的项目拆成多个服务，会涉及很多问题。比如说服务间如何调用？比如说知道服务的地址后，一个服务要自己写一大堆代码，跟其他服务建立网络连接，然后构造一个复杂的请求，接着发送请求过去，最后对返回的响应结果再写一大堆代码来处理吗？那这样，微服务不是复杂度还提高了吗？等等等。所以说一整套解决方案解决的就是多个服务间这一系列的问题。所以说，这也是为什么要提到spring cloud的核心组件，因为核心组件解决的就是这些问题。

假设一个大的项目我把它拆成了这些服务。

那么，问题1： 一个服务想要调其他服务时，不知道ip端口，我该怎么调用呢？而且其他服务这么多，该怎么记呢？

 Eureka

Eureka 是微服务架构中的注册中心，专门负责服务的注册与发现。

Eureka Client：负责将这个服务的信息注册到 Eureka Server 中。

Eureka Server：注册中心，里面有一个注册表，保存了各个服务所在的机器和端口号。

当所有服务共用一个Eureka Server时，每个服务对应的Eureka Client会把该服务信息注册到Eureka Server。然后一个服务想要调用其他服务时，该服务的Eureka Client 组件会找 Eureka Server 问一下要调用的服务信息，然后该服务就有其他服务的信息了，就可以进行调用了。

那么问题又来了，难道一个服务要自己写一大堆代码，跟其他服务建立网络连接，然后构造一个复杂的请求，接着发送请求过去，最后对返回的响应结果再写一大堆代码来处理吗？

Feign

前面的问题显然是不用的，因为框架的目的本来就是简化开发，要真那样的话，开发变的那么复杂，又何必要使用框架呢！

那解决方案呢，就是使用spring cloud的另一个组件Feign。直接就是用注解定义一个 Feign Client 接口，然后调用那个接口就可以了。

 Feign 的一个关键机制就是使用了动态代理。当对某个接口定义了 @FeignClient 注解，Feign 就会针对这个接口创建一个动态代理。如果要调用那个接口，本质就是会调用 Feign 创建的动态代理（Feign的动态代理会根据你在接口上的 @RequestMapping 等注解，来动态构造出你要请求的服务的地址），这是核心中的核心。针对动态代理的这个地址，发起请求、解析响应。相当于就解决了最开始提及的问题（难道一个服务要自己写一大堆代码，跟其他服务建立网络连接，然后构造一个复杂的请求，接着发送请求过去，最后对返回的响应结果再写一大堆代码来处理吗）。

Ribbon

所以说到这，还有什么问题吗，Feign能调服务，Eureka能找到服务。微服务间主要的调用问题解决全了吗？一个大型的服务，我可以部署到多台服务器上，一个挂了还能用另一个。那微服务呢？当然也是一样的。也可以把一个服务部署到多台机器上。那现在再想想，是不是又出现问题了，一个服务在多台机器上，我用哪个机器上的服务呢？Feign 怎么知道该请求哪台机器呢？

Ribbon 就是专门解决这个问题的。它的作用是负载均衡，会帮你在每次请求时选择一台机器，均匀的把请求分发到各个机器上。它有自己默认的算法，也可以自定义算法。其实Feign里是集成了Ribbon的，用的就是Ribbon默认的随机策略。

Ribbon  Feign  Eureka 工作

首先 Ribbon 会从 Eureka Client 里获取到对应的服务注册表，也就知道了所有的服务都部署在了哪些机器上，在监听哪些端口号。然后 Ribbon 就可以使用默认的 Round Robin 算法，从中选择一台机器。Feign 就会针对这台机器，构造并发起请求。

Hystrix

前面说到服务会挂。一个工程是由多个服务组合而成，那么服务调用过程中，某个服务出现故障时，会导致整个功能出现问题，那么怎么解决这个问题呢，就需要用到Hystrix组件。

服务熔断

服务调不通时，执行其他方法。

例子：

 @HystrixCommand(fallbackMethod = "getDefaultUser")@GetMapping("getUser")public String getUser(Integer id) {String url = "http://user-service/provider/getUser?id=" + id;return restTemplate.getForObject(url, String.class);}public String getDefaultUser(Integer id) {System.out.println("熔断，默认回调函数");return "{\"id\":-1,\"name\":\"熔断用户\",\"password\":\"123456\"}";}

服务降级

服务降级时在客户端实现完成，服务降级出现原因是：服务熔断会导致方法膨胀（与服务相关的方法都要有对应的服务熔断）。

服务降级目的：让客户端在服务端不可用时（把服务关掉，让其他服务用足够的资源）也会获得提示信息而不会挂起耗死服务器。

//表示"user-service"的服务，指定fallback
@FeignClient(value = "user-service", fallback = UserFeginFailBackImpl.class)
public interface UserFeginService {@RequestMapping(value = "/provider/getUser")public String getUser(@RequestParam("id") Integer id);
}

Fallback类会执行相应操作，让项目继续运行，不会导致系统耗死。

Zuul

前端调后端系统时，请求统一从 Zuul 网关进入，由 Zuul 网关转发请求给对应的服务（会进行配置）。现在一般都是前后端分离，一般不把真实路径暴露给前端，所以前端请求通过zuul网关转发到对应配置的具体服务就解决了这个问题。

但是如果后端服务多达十几个的时候，每一个都这样配置也挺麻烦的，spring cloud zuul已经帮我们做了默认配置。默认情况下，Zuul会代理所有注册到Eureka Server的微服务，并且Zuul的路由规则如下：http://ZUUL_HOST:ZUUL_PORT/微服务在Eureka上的serviceId/**会被转发到serviceId对应的微服务。

有一个网关之后，还有很多好处，比如可以做统一的降级、限流、认证授权、安全。

spring cloud组件协作图

今天写的全部都是理论，具体实现，下次吧。