SpringCloud NetFlix

遇到记录不完全的可以看看这个人的博客

学相伴SpringCloud

微服务架构的4个核心问题？

服务很多，客户端该怎么访问？
- 负载均衡、反向代理，用户请求的永远都只有一个
这么多服务？服务之间如何通信？
- http 、 RPC
这么多服务？如何治理？
- 服务注册与发现
服务挂了怎么办

解决方案：

SpringCloud 是一个生态！其实也就是解决上面四个问题的一个解决方案的合集

SpringCloud NetFlix 一站式解决方案
1. api 网关，zuul组件，
2. Feign --- HttpClient --- Http 通信方式，同步，阻塞
3. 服务注册发现：Eureka
4. 熔断机制：Hystrix
Apache Dubbo Zookeeper 半自动解决方案，需要整合
1. api：没有，找第三方组件，或者自己实现
2. Dubbo 因为它主要就是做rpc通信的
3. Zookeeper
4. 没有：可以借助 Hystrix
Spring Cloud Alibaba 一站式解决方案！更简单

提及一个新概念：服务网格~ Server Mesh

istio

其实都是为了解决这四个问题：

路由通信高可用服务降级

API （路由）
HTTP，RPC （通信）
注册与发现 （高可用）
熔断机制 （服务降级）

主要缘由就是网络不可靠：可能会掉包丢帧

常见面试题

什么是微服务？
微服务之间是如何独立通讯的？
SpringCloud和Dubbo有哪些区别?
SpringBoot和SpringCloud，请你谈谈对他们的理解
什么是服务熔断？什么是服务降级
微服务的优缺点是分别是什么？说下你在项目开发中遇到的坑
你所知道的微服务技术栈有哪些？请列举一二
eureka和zookeeper都可以提供服务注册与发现的功能，请说说两个的区别？

1.SpringCloud是什么?

	1.Spring Cloud就是微服务系统架构的一站式解决方案，是各个微服务架构落地技术的集合体,俗称微服务全家桶

	2.在平时我们构建微服务的过程中需要做如服务发现注册、配置中心、负载均衡、断路器、数据监控等操作,

  而Spring Cloud 为我们提供了一套简易的编程模型，使我们能在 Spring Boot 的基础上轻松地实现微服务项目的构建

2.什么是分布式?

	1.将各个组件分开部署,某个组件占一个服务器,互相独立,互相调用,可以将组件的功能发挥强大

	2.一个业务分拆多个子业务，部署在不同的服务器上(不同的服务器，运行不同的代码，为了同一个目的)

优点:

1.模块之间独立，各做各的事，便于扩展，复用性高

2.高吞吐量。某个任务需要一个机器运行20个小时，将该任务用10台机器的分布式跑

(将这个任务拆分成10个小任务)，可能2个小时就跑完了

3.什么是集群?

	同一个业务，部署在多个服务器上(不同的服务器运行同样的代码，干同一件事)

优点:

1.通过多台计算机完成同一个工作，达到更高的效率。

2.两机或多机内容、工作过程等完全一样。如果一台死机，另一台可以起作用。

4.分布式与集群

	集群和分布式并不冲突，可以有分布式集群

//我们可以把java，前端，测试看成是分布式,把都在做java的看成是集群

5.什么是微服务?

	1.简单来说微服务就是很小的服务，小到一个服务只对应一个单一的功能，只做一件事

	2.将一个大的项目,按照需求(业务服务)模块拆解成一个个独立小模块(微小服务),然后独立部署,它们之间独立又相互调用

缺点：

。开发人员要处理分布式系统的复杂性。多服务运维难度，随着服务的增加，运维的压力也在增大

。系统部署依赖

。服务间通信成本

。数据一致性

。系统集成测试

性能监控.....

SpringBoot和SpringCloud有啥关系?

	SpringBoot专注于快速、方便的开发单个微服务个体，SpringCloud关注全局的服务治理框架。

//区别:SpringBoot可以离开SpringCloud独立使用开发项目，但是SpringCloud离不开SpringBoot，属于依赖的关系.

SpringCloud的基础功能

1.服务注册与发现：Eureka

2.客户端负载均衡： Ribbon

3.服务熔断与降级： Hystrix

4.声明式服务调用：Feign

5.API网关服务：Spring Cloud Zuul

6.分布式服务跟踪：Spring Cloud Sleuth&Zipkin

7.分布式配置中心：Spring Cloud Config

SpringCloud和Dubbo

最大的区别：

SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式
在社区的活跃度上面，SpringCloud更为活跃
SpringCloud的功能要比Dubbo更加强大，涵盖面更广，因为它能与Spring的其他框架完美融合

SpringCloud和Dubbo就类似于 品牌机和组装机的区别
解决的问题域不一样：

Dubbo的定位是一款RPC框架，SpringCloud的目标是微服务架构下的一站式解决方案

设计模式+微服务拆分思想：软实力：表达能力，硬实力：代码能力

SpringCloud正式学习

Nginx指向我们的前端页面，然后访问后端的网关，网关在帮我们分发到微服务中去

微服务各个模块介绍

NetFlix五大神兽：eureka ribbon feign hsytrix zull

一共编写了5种微服务对象：

springCloud-api（提供一些常用的类和接口，其他每一个微服务都需要导入这个依赖）

<dependency>

    <groupId>com.mao</groupId>

    <artifactId>springCloud-api</artifactId>

    <version>1.0-SNAPSHOT</version>

</dependency>

springCloud-provider 服务提供者，后续使用的Rest服务以及Eureka中的实例id，都是该服务的spring application name的名字
```
spring:

  application:

    name: springCloud-provider-userInfo-8081
```
springCloud-consumer 服务消费者

一、REST服务

提供了一个RestTemplate模板

首先需要将RestTemplate注入进IOC容器中

@Configuration

public class ConfigBean { //@Configuration 相当于 springApplication.xml 配置bean

    @Bean

    public RestTemplate getRestTemplate(){

        return new RestTemplate();

    }

}

然后就可以直接调用使用了

    // 消费者中 不应该有service层

    // 提供了一个RestTemplate模板 我们可以直接调用

    //(url,实体 map， Class<T> responseType) 参数

    @Autowired

    private RestTemplate restTemplate;

    /*

    首先要去 配置类 中将RestTemplate注册进去

    RestTemplate 提供了多种便捷访问的远程http服务的方法，类似于Dubbo中的Reference，他就是个简单的Restful服务模板

     */

	 /**

     * 服务端提供服务的url地址

     */

    private static final String REST_URL_PREFIX = "http://localhost:8081";

    @GetMapping("/getAllUser")

    public List<UserInfo> queryAllUser(){

        return restTemplate.getForObject(REST_URL_PREFIX+"/user/list",List.class);

    }

二、Eureka 服务注册与发现

什么是Eureka？

他是基于CS架构，也是导个包就可以了，通过EurekaServer作为服务注册功能的服务器，他是一个注册中心
Netflix在设计Eureka的时候，遵循的就是AP原则
Eureka是Netflix的一个子模块，也是核心模块之一。Eureka是一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移，服务注册与发现对于微服务来说是非常重要的，有了服务发现与注册，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了，功能类似于Dubbo的注册中心，比如Zookeeper;
而系统中的其他微服务，使用Eureka的客户端连接到EurekaServer并维持心跳连接（也就相当于监控中心）。这样系统的维护人员就可以通过EurekaServer来监控系统中各个微服务是否正常运行，SpringCloud的一些其他模块（比如Zuul)就可以通过EurekaServer来发现系统中的其他微服务，并执行相关的逻辑;

Eureka相关介绍

Eureka包含两个组件：Eureka Server和 Eureka Client
Eureka Server提供服务注册服务，各个节点启动后，会在EurekaServer中进行注册，这样Eureka Server中的服务注册表中将会村粗所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。
Eureka Client是一个Java客户端，用于简化EurekaServer的交互，客户端同时也具备一个内置的，使用轮询负载算法的负载均衡器。在应用启动后，将会向EurekaServer发送心跳（默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除掉（默认周期为90秒)
三大角色

o Eureka Server：提供服务的注册于发现。zookeeper

o Service Provider：将自身服务注册到Eureka中，从而使消费方能够找到。

o Service Consumer：服务消费方从Eureka中获取注册服务列表，从而找到消费服务。

使用：

配置注册中心

导入依赖：
```
<dependency>

    <groupId>org.springframework.cloud</groupId>

    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>

    <version>2.2.9.RELEASE</version>

</dependency>
```
如果出现Error creating bean with name 'traceFilterRegistration' 的报错，说明我们引入的SpringBoot和SpringCloud的依赖不匹配，可以去官网查看匹配的依赖包

Spring Cloud 官网

Spring Boot 官网

配置注册中心

server:

  port: 7001

#spring的配置

spring:

eureka:

  instance:

    hostname: localhost #Eureka服务端的实例名称

  client:

    register-with-eureka: false #表示是否想eureka注册中心注册自己

    fetch-registry: false #fetch-registry如果为false，则表示自己就是注册中心

    service-url:

      #这其实就是一个监控中心的地址，相当于Dubbo中的Dubbo-admin

      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/

${eureka.instance.hostname} 可以拿到配置文件中的值，活的，动态配置和静态配置的区别

在Eureka的启动类上加上@EnableEurekaServer注解，表示他是一个服务端的启动类，可以接受别人注册进来
http://localhost:7001/ 可以访问这个界面，也就是监控中心

注册服务

导入依赖同上

可以导入actuator依赖，并且在启动类上加上@EnableDiscoveryClient注解查看对应的已注册服务的相关信息（可忽略）@EnableDiscoveryClient和@EnableEurekaClient共同点就是：都是能够让注册中心能够发现，扫描到改服务。

不同点：@EnableEurekaClient只适用于Eureka作为注册中心，@EnableDiscoveryClient 可以是其他注册中心。

<!-- actuator完善监控信息 -->

<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-actuator</artifactId>

</dependency>

http://localhost:8081/actuator/info

//导入springcloud下面的discovery

/**

* 读取一些配置的信息，得到具体的微服务

*/

@Autowired

UserInfoService userInfoService;

    /**

     * 注册进来的微服务，获取一些信息

     * @return

     */

    @GetMapping("/discovery")

    public Object discovery(){

        // 获取所有的微服务清单

        List<String> services = client.getServices();

        System.out.println(services);

        // 得到一个具体的微服务信息，通过具体的微服务serviceId，applicationName

        List<ServiceInstance> instances = client.getInstances("SPRINGCLOUD-PROVIDER-USERINFO-8081");

        for (ServiceInstance instance : instances) {

            System.out.println(instance);

        }

        return this.client;

    }

配置eureka

#Eureka的配置，服务注册到哪里

eureka:

  client:

    service-url:

      defaultZone: http://localhost:7001/eureka/

  instance:

    instance-id: springcloud-provider-user8001 #修改eureka上的默认描述信息

#info配置

info:

  app.name: mao-springcloud

  company.name: maomao.com

在服务提供者的启动类上加上@EnableEurekaClient注解 // 他会在服务启动后自动注册到Eureka注册中心中
自我保护机制：
```
EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.
```
- 默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例（默认90秒)。但是当网络分区故障发生时，微服务与Eureka之间无法正常通行，以上行为可能变得非常危险了--因为微服务本身其实是健康的，此时本不应该注销这个服务。Eureka通过自我保护机制来解决这个问题--当EurekaServer节点在短时间内丢失过多客户端时（可能发生了网络分区故障)，那么这个节点就会进入自我保护模式。一旦进入该模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据〈也就是不会注销任何微服务）。当网络故障恢复后，该EurekaServer节点会自动退出自我保护模式。
- 在自我保护模式中，EurekaServer会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该EurekaServer节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。一句话: 服务挂了也当你还活着
- 综上，自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留)，也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮和稳定
- 在SpringCloud中，可以使用eureka.server.enable-se1f-preservation = false 禁用自我保护模式【不推荐关闭自我保护机制】

集群环境配置

就是类似于你在 hosts文件中配置了自己的 host一样

文件的位置：‪C:\Windows\System32\drivers\etc\hosts

127.0.0.1       eureka7001

127.0.0.1       eureka7002

127.0.0.1       eureka7003

你只需要多起几个注册中心，每个注册中心的配置以及导包都是一样的，只是端口不同

然后这几个eureka互相挂载就可以了，这样就可以称之为集群（就算你在运行的时候，一个注册中心挂了还有其他的可以用）

如何挂载?：在注册中心的配置文件中的defaultZone属性，输入其他的eureka服务，多个就用逗号隔开

注册中心的配置：

eureka:

  instance:

    hostname: eureka7002 #Eureka服务端的实例名称

#    hostname: eureka7002 #Eureka服务端的实例名称

  client:

    register-with-eureka: false # 表示是否想eureka注册中心注册自己

    fetch-registry: false # fetch-registry如果为false，则表示自己就是注册中心

    service-url:  # 监控界面

      # 单机：      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/

      # 集群（关联）互相挂载

      defaultZone: http://eureka7001:7001/eureka/

      # 如果是有多个的话 可以使用逗号隔开

      # defaultZone: http://eureka7002:7002/eureka/，http://eureka7003:7003/eureka/

服务提供者的配置：（我们还需要将服务发布到所有的注册中心上）

eureka:

  client:

    service-url:

      #	将服务发布到所有注册中心上

      defaultZone: http://eureka7001:7001/eureka/,http://eureka7002:7002/eureka/，http://eureka7003:7003/eureka/

回顾CAP原则

RDBMS（Mysql、Oracle、SQLServer） ===》ACID

NoSQL（Redis、MongoDB） ===》CAP

ACID是什么？

A（Atomicity）原子性
C（Consistency）一致性
I（Isolation）隔离性
D（Durability）持久性

CAP是什么？

C（Consistency）强一致性
A（Availability）可用性
P（Partition tolerance）分区容错性

CAP的三进二：CA、AP、CP

一个分布式系统只能满足两个特性，不可能三者兼得

Eureka和Zookeeper区别

CAP理论：一个分布式系统不可能同时满足C（一致性），A（可用性），P（容错性）

由于P（分区容错性）在分布式系统中是必须要保证的，所以我们只能在A和C之间权衡

区别：zookeeper需要调用同名接口，而Eureka只需要通过链接即可

Zookeeper保证的是CP （一致性和分区容错性）
- 当master主节因为网络故障与其他节点失去联系的时候，剩余的节点会进行leader选举，
  
  由于选举leader的时间太长，且选举期间整个zookeeper集群都是不可用的，会导致注册服务瘫痪
Eureka保证的是AP （可用性和分区容错性）
- Eureka的各个节点都是平等的，某个节点挂掉并不会影响其他的正常节点的工作，并且在Eureka客户端在向某个Eureka注册的时候如果失败会自动切换到其他节点。
  
  此外：Eureka有一种自我保护机制来应对Eureka出现了网络故障的情况

Conclusion：因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪

三、Ribbon负载均衡

Ribbon是什么

Spring Cloud Ribbon是基于Netflix Ribbon实现的一套 客户端负载均衡的工具
简单的说，Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将NetFlix的中间云服务连接在一起。Ribbon的客户端组件提供一系列完整的配置项如: 连接超时、重试等等。简单的说，就是在配置文件中列出LoadBalancer (简称LB: 负载均衡)后面所有的机器，Ribbon会自动的帮助你基于某种规则(如简单轮询，随机连接等等)去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法!

Ribbon的作用

LB，即负载均衡（Load Balance），在微服务或者分布式集群常用的一种应用
负载均衡简单的说就是将用户的请求按需分配到多个服务器上，从而达到HA（高可用）
常见的负载均衡软件Nginx，LVS等等
dubbo、SpringCloud中均给我们提供了负载均衡，Springcloud的负载均衡算法可以自定义
负载均衡简单分类:
- 集中式LB
  - 即在服务的消费方和提供方之间使用独立的LB设施，如Nginx（反向代理服务器），由该设施负责把访问请求通过某种策略转发至服务的提供方!
- 进程式LB
  - 将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选出一个合适的服务器。
  - Ribbon就属于进程内LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方地址

Ribbon的简单使用

在消费者的微服务中使用 Consumer

导入依赖，Eureka里面自带了Ribbon

        <dependency>

            <groupId>org.springframework.cloud</groupId>

            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>

            <version>2.2.9.RELEASE</version>

        </dependency>

在消费者的启动类上加上@EnableEurekaClient注解

编写Eureka配置

#Eureka配置

eureka:

  client:

    register-with-eureka: false

    service-url:

      defaultZone: http://eureka7001:7001/eureka/,http://eureka7002:7002/eureka/

在我们的配置类中的 RestTemplate方法上加上@LoadBalanced //Ribbon 注解，就可以使用了
修改Rest服务的前缀地址：在我们使用了Ribbon之后，Rest服务的地址不再是之前的写死的提供者的地址，而是使用服务提供者在Eureka中的id来作为Rest服务的前缀
- ```
private static final String REST_URL_PREFIX = "http://SPRINGCLOUD-PROVIDER-USERINFO-8081";
```
- 记得这个时候就需要在服务提供者那里配置
  
  prefer-ip-address: true才能自动获取本机url
  
  不然会报： No instances available for xxx服务的报错
```
eureka:

  instance:

    instance-id: springcloud-provider-user8081 #修改eureka上的默认描述信息

    prefer-ip-address: true
```
可以启动测试了。。。
在这之后，用户每次调用接口，都只需要在消费端中配置好对应服务在Eureka中注册使用的ID就可以

避坑：

P6-P11

我是很后面才来看狂神的视频的稍微说几个点，给那些版本和我一样高的人躲一些坑：

我的springboot版本时2.5.3的，eureka依赖用的是spring-cloud-starter-netflix-eureka-client和spring-cloud-starter-netflix-eureka-server都是3.0.3版本的。

1.首先狂神视频用的spring-cloud-starter-eureka和spring-cloud-starter-eureka-server已经被丢弃了，官方推荐使用spring-cloud-starter-netflix-eureka-client和spring-cloud-starter-netflix-eureka-server，并且spring-cloud-starter-netflix-eureka-client3.0.x版本（2.2.9版本的不太清楚）是包含对ribbon的依赖的，所以你就不用ribbon原来的依赖了。出ServerPropertiesAutoConfiguration.class] cannot be opened和no instances available…报错可以尝试将原来的那些包替换成我的，原来的代码不用变

2.在ribbon的视频里，@RibbonClient注解在3.0.3版本里已经没有，可以用@LoadBalancerClient替换

然后我找了一下源代码，没有找到IRule类，且官方的负载均衡算法好像也只有轮询和随机了（我只找到这两个），两者实现ReactorServiceInstanceLoadBalancer接口可以用@Bean注解来保存我们自定义的负载均衡算法。

由于本人代码能力比较差，很多地方还不太理解，看源代码也存在很多问题，比如代码中的Mono类看不懂，IRule类不见了应该用什么替换？希望有大佬能指点一下，如果上文有错误的地方，也希望大家能指出。

Ribbon负载均衡的简单实现

多注册几个提供相同服务的服务提供者，但是每个服务提供者的服务Id不同，服务端口不同，访问的数据库也不同（每个数据库内的数据表都是相同的，都是在配置文件中修改一下即可），然后注册进去Eureka，就可以了，消费者在请求的时候Ribbon就会自动帮我们轮询找到合适的服务提供者

自定义负载均衡算法

IRule（策略），这是一个接口（网关），也就是一些实现这个接口的一些类就是Ribbon为我们提供的一些负载均衡算法

在配置类中注入一个Bean（写在启动类所在包同级的配置类中，就是放到@ComponentScan扫描的包外面）

可以使用

@RibbonClient(name = "xxx",configuration = XxxRibbonConfig.class)

注解在启动类上，加载指定我Ribbon配置类

@Bean

Public IRule myRule(){

	return new RandomRule();

    return 返回自己重写的策略就可以了;

}

四、Feign负载均衡

简介：

Ribbon 和 Feign 目的：都是为了解决微服务的远程调用

feign是声明式的web service客户端，它让微服务之间的调用变得更简单了，类似controller调用service。SpringCloud集成了Ribbon和Eureka，可在使用Feign时提供负载均衡的http客户端。

只需要创建一个接口，然后添加注解即可!

feign，主要是社区，大家都习惯面向接口编程。这个是很多开发人员的规范。调用微服务访问两种方法

微服务名字 [ribbon]
接口和注解[feign]

Feign的作用

Feign旨在使编写java Http客户端更加简单
前面在使用Ribbon + RestTemplate时，利用RestTemplate对Http请求的封装处理，形成了一套模板化的调用方法。但是在实际开发中，由于对服务依赖的调用可能不止一处，往往一个接口会被多处调用，所以通常都会针对每个微服务自行封装一些客户端类来包装这些依赖服务的调用。所以，Feign在此基础上做了进一步封装，由他来帮助我们定义和实现依赖服务接口的定义，在Feign的实现下，我们只需要创建一个接口并使用注解的方式来配置它(类似于以前Dao接口上标注Mapper注解，现在是一个微服务接口上面标注一个Feign注解即可。)即可完成对服务提供方的接口绑定，简化了使用Spring loud Ribbon时，自动封装服务调用客户端的开发量。
Feign集成了Ribbon

利用Ribbon维护了MicroserviceCloud-Dept的服务列表信息，并且通过轮询实现了客户端的负载均衡，而与Ribbon不同的是，通过Feign只需要定义服务绑定接口且以声明式的方法，优雅而且简单的实现了服务调用。

Feign的简单运用

创建一个微服务springCloud-consumer-user-feign，导入之前消费者一样的依赖

注意区分Feign提供的sevice接口和Feign的controller控制器

导入依赖

Feign停更闭源了，openFeign 是官方的而且是增强版的Feign并集成了Ribbon，支持SpringMVC注解。Alibaba 用的是Dubbo RPC

在springCloud-api和springCloud-consumer-user-feign中导入Feign依赖
```


<dependency>

    <groupId>org.springframework.cloud</groupId>

    <artifactId>spring-cloud-starter-openfeign</artifactId>

    <version>2.2.9.RELEASE</version>

</dependency>
```
编写消费者接口（类似于Dubbo中的Reference）

使用@FeignClient(value = "Eureka中服务提供者的id")

重点就在使用映射注解写的url地址：一定要跟服务提供者provider的controller的url映射地址一致，不然会报错

在springCloud-api中写一个接口在Service中，UserClientService

接口中的方法跟我们方法提供者中的Service接口内的方法一致

Feign为我们做的就是让我们编写的这个接口类似于之前消费者中的controller
```
@Component

// 有了这个注解，就类似于之前Dubbo的reference一样，可以直接调用

@FeignClient(value = "SPRINGCLOUD-PROVIDER-USERINFO-8081")

public interface UserClientService {

    @GetMapping("/user/list")

    List<UserInfo> queryAllUser();

}
```

在Fiegn模块的controller中，注入springCloud-api中提供的UserClientService接口

@RestController

@RequestMapping("/consumer")

public class UserConsumerController {

    // 注入我们的springCloud-api中提供的UserClientService接口

    @Autowired

    private UserClientService service = null;

    @GetMapping("/getAllUser")

    public List<UserInfo> queryAllUser(){

        return this.service.queryAllUser();

    }

}

最后在Feign模块的启动类上使用注解

@EnableFeignClients(basePackages = "com.mao.springcloud")

为了扫描到引入的springcloud-api模块中我们写的Feign接口UserClientService

五、Hystrix

功能：

服务熔断
服务降级
dashboard流监控

服务雪崩

注：雪崩的时候没有一片雪花是无辜的

A、B、C、D四个服务

A->B->C->D 他们在调用过程中某一个微服务的调用响应时间过长或者不可用

会导致其资源紧张。

什么是Hystrix

Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时，异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。

“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝)，向调用方返回一个服务预期的，可处理的备选响应(FallBack)，而不是长时间的等待或者抛出调用方法无法处理的异常，这样就可以保证了服务调用方的线程不会被长时间，不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩

举例：这里有多个服务

A->B->C1->D，结果此时C1崩了，这时候Hystrix就会调出一个备选方案C2用来顶替C1

Hystrix的功能

服务降级
服务熔断
服务限流
接近实时的监控
。。。

服务熔断

服务熔断是什么

熔断机制：是对应雪崩效应的一种微服务链路保护机制。

当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand。

Hystrix服务熔断简单使用

起一个微服务，内容与服务提供者大致相同，就是在controller层中多加了几个Hystrix方法

导入依赖

spring-cloud-start-hystrix

加上两个注解

在该方法调用异常时调用指定方法，类似重定向@HystrixCommand(fallbackMethod = "xxx方法")
添加对熔断的支持 @EnableCircuitBreaker

Dashboard流监控

导入依赖，启动类上加@EnableHystrixDashboard注解

六、Zuul路由网关

API Gateway

什么Zuul

Zuul包含了对请求的路由和过滤两个最主要的功能：

其中路由功能负责将外部请求转发到具体的微服务实例上（也就是将原有的真实请求地址localhost:8080隐藏，修改成类似于www.xxx.com的地址），是实现外部访问统一入口的基础，而过滤器功能则负责对请求的处理过程进行干预，是实现请求校验，服务聚合等功能的基础。Zuul和Eureka进行整合，将Zuu自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他微服务的消息，也即以后的访问微服务都是通过Zuul跳转后获得。

注意: Zuul服务最终还是会注册进Eureka，也要注册进Eureka中

提供:代理 + 路由 + 过滤三大功能！

Zuul能干嘛

路由
过滤

Zuul简单使用

导入依赖
```
spring-cloud-start-zuul
```
写好配置类

配置Spring相关信息，将zuul注册进Eureka
启动类上加@EnableZuulProxy注解支持Zuul
修改zuul的相关配置，即可做到路由和过滤的功能（访问的时候，服务的id大写不起作用就用小写）

路由：

输入指定的路由地址，就可以访问到服务

zuul:

  routes:

    mydept.serviceId: springcloud-provider-dept

    mydept.path: /mydept/**

过滤：

忽略掉指定的地址，在请求的时候就会报错，就不能在使用该路径访问了

zuul:

  ignored-services: "*"

  # 这是设置公共的前缀，访问的路径前必须加上前缀

  prefix: /mao

七、SpringCloud Config 分布式配置

什么是config

因为分布式微服务有很多配置，我们就可以提供一个东西，把所有的配置放到里面，在需要的时候就去里面拿就可以

Spring Cloud Config 为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环节提供了一个中心化的外部配置。

Spring Cloud Config 分为服务端和客户端两部分服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密，解密信息等访问接口。

客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。配置服务器默认采用gt来存储配置信息，这样就有助于对环境配置进行版本管理。并且可以通过git客户端工具来方便的管理和访问配置内容。

SpringCloud config分布式配置中心能干嘛

集中管理配置文件
不同环境，不同配置，动态化的配置更新，分环境部署，比如 /dev /test/ /prod /beta /release
运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息。
当配置发生变动时，服务不需要重启，即可感知到配置的变化，并应用新的配置将配置
信息以REST接口的形式暴露

SpringCloud config分布式配置中心与github整合

由于Spring Cloud Config 默认使用Git来存储配置文件(也有其他方式，比如支持SVN和本地文件)，但是最推荐的还是Git ，而且使用的是 http / https 访问的形式