Spring Cloud的宏观理解·

SpringCloud 简单理解

spring cloud 可以认为是一种分布式服务的框架，它为开发人员提供了快速构建分布式系统的常用模式的一些工具，比如说配置管理、服务的注册与发现、服务调用的负载均衡、资源隔离、熔断降级等等，spring cloud为这些提供了一阵套完整的解决方案。

微服务

1.微服务的核心思想便是服务拆分与解耦,降低复杂性。微服务强调将功能合理拆解,尽可能保证每个服务的功能单一，按照单一责任原则（Single Responsibility Principle）明确角色。 将各个服务做轻，从而做到灵活、可复用，亦可根据各个服务自身资源需求，单独布署，单独作横向扩展。

服务注册与发现 Eureka

1.@EnableEurekaServer 注解启动一个服务注册中心提供给其他应用进行对话。这个注解放在启动类上方。

2. Eureka分为服务注册中心，服务提供者 ，服务消费者。服务提供者 、服务消费者都必须指定注册中心。服务提供者提供服务，而服务消费者可以调用提供者的服务。

3.服务发现的接口DiscoveryClient类是Spring Cloud对服务治理做的一层抽象。

@EanbleDiscoveryClient 注解，加在启动类main的上方，可以将应用注册为Eureka 客户端应用，以获取服务发现的能力。

4.Spring Cloud Consul项目： 可以将基于Spring Boot的微服务应用注册到Consul上，并通过此实现微服务架构中的服务治理。Consul的作用类似于Eureka。

负载均衡

负载均衡 Ribbon
1.LoadBalancerClient接口 ，是一个负载均衡客户端的接口。

Ribbon注解：@LoadBalanced。

2.RestTemplate对象，通过getForObject()等方法实现对服务提供者接口的调用。

注入方式如下：

   @Autowired
    private RestTemplate restTemplate;

3.将eureka-server(服务注册中心)、eureka-client(服务提供者)、eureka-consumer(服务消费者)都启动起来，然后访问 eureka-consumer的Controller层方法对应的请求，可以观察eureka-consumer服务是如何消费eureka-client服务的Controller层方法接口的。

4.使用Spring Cloud Ribbon可以作为服务消费者，实现服务的调用以及客户端负载均衡。

5.在Ribbon中可以采用服务名的方式进行请求，因为Ribbon有一个拦截器，它能够在这里进行实际调用的时候，自动的去选取服务实例，并将实际要请求的IP地址和端口替换这里的服务名，从而完成服务接口的调用。

服务名是application文件中的spring.application.name 属性。

6.Ribbon底层原理：负载均衡。轮询。

7.Ribbon：重试机制。

Eureka由于在可用性和一致性的取舍上，选择了可用性。所以服务调用遇到实例故障时，可以使用重试机制。Ribbon的重试机制可以通过简单的配置实现。

spring.cloud.loadbalancer.retry.enabled=true

服务消费者 Feign

1. Feign是一套基于Netflix Feign实现的声明式服务调用客户端。Feign可以做为服务消费者。需要通过创建接口并用注解来配置它既可完成对Web服务接口的绑定。

2.@EnableFeignClients注解在Application类上方，可以开启扫描Spring Cloud Feign客户端的功能

3.@FeignClient注解用在Feign接口上方，用来指定这个接口所要调用的服务名称。

2.Feign底层原理 ：动态代理。

3.Feign接口支持SpringMvc的注解。包括@RequestBody，@RequestParam等

4.重试机制：Feign自带Ribbon，默认实现了请求重试机制。当请求时间超过设置的超时时间时，Feign会发起重试。

5.使用Feign的時候，同時也會自动创建负载均衡的Ribbon，还会自动引入服务保护与容错的Hystrix。

6.Feign最终发送request请求以及接收response响应，都是由Client组件完成的，其中Client的实现类，只要有Client.Default，该类由HttpURLConnnection实现网络请求，另外还支持HttpClient、Okhttp。

断路器 Hystrix

1.服务熔断： 在分布式架构中，当某个服务单元发生故障（类似用电器发生短路）之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个错误响应，而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延。

雪崩效应：是一种因服务提供者的不可用导致服务调用者的不可用,并将不可用逐渐放大的过程。

熔断可以避免服务雪崩。

2.Spring Cloud中使用了Hystrix 来实现断路器的功能。Hystrix具备拥有回退机制和断路器功能的线程和信号隔离，请求缓存和请求打包，以及监控和配置等功能。Hystrix具有融断机制。

Hystrix可以进行服务降级、服务隔离、服务熔断。

3.在Ribbon中需要引入Hystrix依赖。否则服务不可用时，会返回404。

而Feign中已经依赖了Hystrix，不需要再引入，会直接返回内部错误(500) 。

4.当服务提供者不可用时，断路器Hystrix会返回错误响应。

5.使用了@HystrixCommand来将某个函数包装成了Hystrix命令，这里除了定义服务降级之外，Hystrix框架就会自动的为这个函数实现调用的隔离。所以，依赖隔离、服务降级在使用时候都是一体化实现的.

@HystrixCommond，顾名思义，使用了“命令模式”。

Hystrix一般都是和Feign一起使用，使用@HystrixCommond的较少。

6.服务隔离： Hystrix使用"舱壁模式"实现线程池的隔离，它会为每一个Hystrix命令创建一个独立的线程池，这样就算某个在Hystrix命令包装下的依赖服务出现延迟过高的情况，也只是对该依赖服务的调用产生影响，而不会拖慢其他的服务。
通过对依赖服务实现线程池隔离，应用更加健壮，不会因为个别依赖服务出现问题而引起非相关服务的异常。

7.服务降级：当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。

为了保证重要或基本的服务能正常运行，我们可以将一些不重要或不紧急的服务或任务进行服务的延迟使用或暂停使用。

8.思考：服务降级和服务熔断有什么区别？

熔断是直接返回一个错误响应，降级是延迟使用或暂停使用。

9.Hystix隔离机制：线程池隔离、信号量隔离。

10.可以在熔断的FallBack方法中，将Throwable异常作为参数，并显示熔断的异常信息。

11.Hystrix-dashboard，可以对服务进行监控，展示数据。

服务网关Zuul

1.服务网关：通过服务网关统一向外系统提供REST API的过程中，具备服务路由、均衡负载、权限控制等功能。Spring Cloud Netflix中的服务网关为Zuul。

一般微服务架构中都必然会设计一个网关在里面，像android、ios、pc前端、微信小程序、H5等等，不用去关心后端有几百个服务，就知道有一个网关，所有请求都往网关走，网关会根据请求中的一些特征，将请求转发给后端的各个服务。而且有了网关之后，还有很多好处，比如可以做统一的降级、限流、认证授权、安全，等等。

2.服务路由：通过服务路由的功能，在对外提供服务的时候，只需要通过暴露Zuul中配置的调用地址就可以让调用方统一的来访问我们的服务，而不需要了解具体提供服务的主机信息了。

3.服务过滤：在服务网关中定义过滤器只需要继承ZuulFilter抽象类实现其定义的四个抽象函数就可对请求进行拦截与过滤。

4.网关Zuul自带Ribbon和Hystrix。

分布式配置中心 Config

1.分布式配置中心，集中管理配置，“一次配置，随处可用”。

2.在SpringCloudConfig中，程序中bootstrap.yml中的配置优先级高于application.yml的配置。。

3.SpringCloudConfig主要由基于Git仓库的配置中心服务端 、 使用配置中心的客户端组成。

spring cloud优势与不足

优势：
spring cloud 是基于spring boot，大大简化开发。spring cloud提供了一套较为完整的分布式系统化解决方案，这也是为什么很多的中小型公司现在比较倾向于使用spring cloud来作为分布式开发框架。

不足：
服务的注册发现的通信采用的也是http，这就导致了服务故障下线的延迟，从而导致请求调用发送到了已经下线的节点，导致调用失败。
服务之间的调用采用的也是http协议，因此这对网络调用的性能有一定的影响