SpringCloud

官方解释：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) 长时间没收到提供者的信息，那么中介会将他的房屋信息给下架(服务剔除)。

当然，可以充当服务发现的组件有很多：Zookeeper ，Consul（spring自己的注册中心）， Eureka 等。

补充：QC—问题中心（我们将代码上传到gitlab后，测试和运维会将问题反馈到问题中心）。QA—项目质量（提测）。

补充：注册中心在项目中的意义：

实现应用程序解耦，项目之间不是直接进行通信。项目A把自己服务器的IP地址、端口等信息注册到注册中心，项目B从项目中心获取项目A的信息后再进行访问项目A。

项目发布所在服务器地址可以随意变化。如果在项目B进行编码写项目A的IP和端口，当项目A上午服务器地址发生变化或项目重新部署到其他服务器上时，重新编码项目B中IP和端口。而有了注册中心之后就不需要重新编码，依旧是访问注册中心的IP和端口。

借助注册中心可以实现负载均衡等效果。（如果没有注册中心，负载均衡等那些也不好实现）。

补充：Eureka中分为两个角色：Eureka Server（Eureka服务）和Eureka Client（Eureka客户端）（又细分为两个角色，一个是applicationServer（被调用者），另一个是applicationClient（调用者））。例子：中介就是Eureka服务，租客以及房东就是Eureka客户端。

补充：Eureka满足的CAP理论（分布式一致性定理）

C—强一致性（强调立即同步，达到数据一致性）、A—可用性（个别节点出问题是否会影响整体可用性）、P—分区容错性（有限时间内达到数据一致性）

补充：Eureka存储的是全量信息（意思是每一个Eureka内容都是一样的），Eureka是弱一致性，后面慢慢进行同步（就是你先把数据信息登记到一台服务器上，过一段时间后把这台服务器信息完全复制到别的服务器上，而不是当时立马要求别的服务器和你是一样的数据。）Eureka保证AP。Eureka默认端口号是8761。

补充：@EnableEurekaClient是默认的，@EnableDiscoveryClient和前面效果一样，但它是个万能注解，意思就是不管springCloud支持哪个注册中心，都可以使用这个注解。

Eureka如何部署在项目中：

首先新建springboot项目，选择eureka，接着引入pom.xml依赖

<dependency>

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

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

</dependency>

写入配置文件

启动，如果可以成功访问defaultZone，说明eureka加载成功。

Eureka如何优雅关机：

是springboot中的，只要是springboot的项目，就得有这个东西

Actuator和Eureka没有任何关系，放在这除了实现Eureka的关机效果之外，也是讲解一下Actuator的用法。

Actuator—监视器，监控中心（可以实现springboot的关机功能，刷新功能，获取项目功能等等），它的所有功能只提供了post方式。

spring-cloud-starter-netflix-eureka-client依赖中默认依赖了Actuator，就不需要导入额外包。

负载均衡之 Ribbon（netflix）

为什么需要 Ribbon？

Ribbon 是 Netflix 公司的一个开源的负载均衡项目，是一个客户端/进程内负载均衡器，运行在消费者端。它不需要单独部署，但是却存在于整个微服务中。前面学习的eureka中有Ribbon，后面学习的OpenFeign也是基于Ribbon实现的。

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

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

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

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

使用Ribbon的工作原理：

所有的项目都会注册到eureka中，eureka允许不同项目的spring.application.name是相同的。当相同时会认为这些项目是一个集群。所以同一个项目部署多次时都是设置应用程序名相同。Application Client会从Eureka中根据spring.application.name加载Application Service的列表。根据设定的负载均衡算法，从列表中取出一个URL，到此Ribbon的事情就结束了。

Nginx 和 Ribbon 的对比：

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

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

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

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

Ribbon 的几种负载均衡算法：

负载均衡，不管 Nginx（集中式负载均衡—客户端和服务端之间使用独立的负载均衡设施—nginx是软件设施，也可以使用硬件设施，比如F5）还是 Ribbon （进程内负载均衡—将负载均衡集成到客户端组件中，客户端组件从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选出一个合适的服务端发起请求）都需要其算法的支持，如果我没记错的话 Nginx 使用的是轮询和加权轮询算法。而在 Ribbon 中有更多的负载均衡调度算法，其默认是使用的 RoundRobinRule 轮询策略。

RoundRobinRule：轮询策略（挨个来）。Ribbon 默认采用的策略。若经过一轮轮询没有找到可用的 provider，其最多轮询 10 轮。若最终还没有找到，则返回 null。

RandomRule: 随机策略，从所有可用的 provider 中随机选择一个。

RetryRule: 重试策略。先按照 RoundRobinRule 策略获取 provider，若获取失败，则在指定的时限内重试。默认的时限为 500 毫秒。

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

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

具体实现：（可以写在实现类里面）

RestTemplate

什么是 RestTemplate?

RestTemplate是Spring提供的一个访问Http服务的客户端类（HttpClient也可以访问），也就是说导入spring-boot-starter-web的项目我们就可以直接使用RestTemplate，就是基于模板方法设计模式的，封装了所有需要使用的API。也就是微服务之间的调用是使用的 RestTemplate 。比如这个时候我们消费者B 需要调用提供者A 所提供的服务我们就需要这么写。如我下面的伪代码。postForObject、getForObject是它的方法，返回的是响应头。还有postForEntity、getForEntity方法，这两个方法里面返回的是响应体数据。它们的写法都是类似的。Post比get参数多了一个request数据。

exchange方法：

当请求的控制器返回的是List<xxx>、Set<xxx>等带有泛型类型的类型时，就不能使用上面那四个方法，因为它们都是只能设置返回值类型，不能设置泛型的类型，这就需要使用exchange方法。除此之外，如果需要设置请求头参数情况也需要使用exchange方法。下面还使用了匿名类。

Eureka 框架中的注册、续约等，底层都是使用的 RestTemplate 。

补充：post支持请求体（发送的是字节流），get不支持（发送的是字符流）。

补充：新的字符串拼接方法，用占位符：{1}{2}是占位符，后面name，age表示放的顺序和内容。还有一个map的方式，此时{}里面存放的是key值。

补充：Ribbon还可以这样使用，到时候如果使用RestTemplate的话，可以直接使用DI注入。使用方法和上面一样，唯一区别是restTemplate.getForObject中的参数的url中的IP地址要改为名称。比如说是上面的localhost:8080改为eureka的名称。

HttpClient

和RestTemplate是一样的用途，具体用法：

接着导入它的工具包，下面这个超链接。

HttpClientUtils.txt

Hystrix（服务容错）

Hystrix 就是一个能进行熔断和降级的库，通过使用它能提高整个系统的弹性。

那么什么是熔断和降级呢？再举个，此时我们整个微服务系统是这样的。服务A调用了服务B，服务B再调用了服务C，但是因为某些原因，服务C顶不住了，这个时候大量请求会在服务C阻塞。

服务C阻塞了还好，毕竟只是一个系统崩溃了。但是请注意这个时候因为服务C不能返回响应，那么服务B调用服务C的请求就会阻塞，同理服务B阻塞了，那么服务A也会阻塞崩溃。这就叫服务雪崩。

所谓熔断就是服务雪崩的一种有效解决方案。当指定时间窗内的请求失败率达到设定阈值时，系统将通过断路器直接将此请求链路断开。也就是我们上面服务B调用服务C在指定时间窗内，调用的失败率到达了一定的值，那么 Hystrix 则会自动将服务B与C 之间的请求都断了，以免导致服务雪崩现象。

如何防止雪崩现象：

降级和熔断

其实这里所讲的熔断就是指的 Hystrix 中的断路器模式，是指当失败率达到一定阈值就会自动触发降级，熔断就是具有特定条件的降级。熔断和降级都是使用同一个注解。你可以使用简单的 @HystrixCommand 注解来标注某个方法，这样 Hystrix 就会使用断路器来“包装”这个方法，每当调用时间超过指定时间时(默认为1000ms)，断路器将会中断对这个方法的调用。

当然你可以对这个注解的很多属性进行设置，比如设置超时时间，像这样。

@HystrixCommand(

    commandProperties = {@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "1200")}

)

public List<Xxx> getXxxx() {

    // ...省略代码逻辑

}

所谓降级，超时降级，资源不足时（线程或信号量）降级，降级后可以配合降级接口返回托底数据，实现一个fallback方法返回的值，以此来保证，服务出现问题整个项目还可以正常运行。降级是为了更好的用户体验，当一个方法调用异常时，通过执行另一种代码逻辑来给用户友好的回复。这也就对应着 Hystrix 的后备处理模式。你可以通过设置 fallbackMethod 来给一个方法设置备用的代码逻辑。比如这个时候有一个热点新闻出现了，我们会推荐给用户查看详情，然后用户会通过id去查询新闻的详情，但是因为这条新闻太火了(比如最近什么*易对吧)，大量用户同时访问可能会导致系统崩溃，那么我们就进行服务降级，一些请求会做一些降级处理比如当前人数太多请稍后查看等等。

总结：降级的话每个请求都会访问另外的项目，访问的时候如果出现超时和资源不足就会返回特定数据；熔断是达到一定条件后，在一定时间内就不再返回，直接返回托底数据。

请求缓存（A调用B，在A中添加请求缓存，第一次请求后走缓存了，就不再访问服务B了）
请求合并（A调用B时，设定将5ms内所有请求合并到一起，对于服务B的负载会大大减少）（高并发情况下需要请求合并）（必须设置返回值为Future）
隔离（分为线程池隔离和信号量隔离，通过判断线程池或信号量是否已满，超出容量的请求直接降级，从而达到限流的作用）

请注意，为什么阻塞会崩溃。因为这些请求会消耗占用系统的线程、IO 等资源，消耗完你这个系统服务器不就崩了么。

降级步骤：

首先添加依赖（谁调用另一个，就放在谁的pom里）

<dependency>

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

   <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>

</dependency>

在启动类添加注解（简言之，就是让代码中的hystrix相关注解生效）

如果出现连接超时或者别的，就会执行降级或熔断方法。

当请求时间为20s内，请求数出现了10个，这10个请求失败率达到了30%，那么就会触发熔断，20s内不再请求远程服务。

@HystrixCommand(fallbackMethod = "方法名",commandProperties = {

@HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",value = "10"),-----------------------------------------------------请求数

      @HystrixProperty(name = HystrixPropertiesManager.EXECUTION_ISOLATION_THREAD_TIMEOUT_IN_MILLISECONDS,value = "20000"),---请求时间

      @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",value = "30"),---失败率

@HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",value = "20000")---开启熔断后，20s内不再请求远程服务

})

请求合并的例子：

模拟两个客户端去请求服务器端，用了@HystrixCollapser后，就会把这两个请求合并为一个，返回的结果也是[张三、李四]，这样一个合并后的结果。淘宝双十一请求人流量特别大的时候就可以用这个。

隔离：

线程池隔离：没有线程池隔离的时候可能因为某个接口的高并发而导致其它接口也出现问题。当使用线程池的时候，不同接口有着自己独立的线程池。

优点：解决了限流的问题，解决了高并发的问题。

缺点：增加了CPU的开销。

例子：此时两个线程就使用了不同的线程池，一个是hystrix创建的，一个是自带的。

补充：gateway—限流，是第三方的，不是netflix的，也是服务网关。比zuul用的多。

补充：spring是一个容器，里面包含有IOC和AOP，IOC是控制反转，就是由容器来负责控制对象的生命周期和对象之间的关系。（控制对象生命周期的不再是引用它的对象，而是容器。对具体对象，以前是它控制其它对象，现在所有对象都被容器控制）所以是控制反转。DI(依赖注入，它指的是容器在实例化对象的时候把它依赖的类注入给它)是IOC的补充和实现。

信号量隔离：用来控制可同时并发的线程数。（就是计数器）

例子：

Hystrix-dashboard：

可以查看Hystrix实例的执行情况，（把文字转换成图片）支持查看单个实例和查看集群实例，但是需要结合spring-boot-actuator一起使用。Hystrix-dashboard能够让Actuator从json转换为界面。Hystrix Dashboard主要用来实时监控Hystrix的各项指标信息。Hystrix Dashboard可以有效地反映出每个Hystrix实例的运行情况，帮助我们快速发现系统中的问题，从而采取对应措施。 Hystrix的主要优点之一是它收集的有关每个HystrixCommand的一组指标。

实现步骤：

加入下面依赖

<dependency>

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

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

</dependency>

<!--引入hystrix dashboard 依赖-->

<dependency>

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

   <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>

</dependency>

启动器添加注解

@EnableHystrix

@EnableHystrixDashboard

修改配置文件

management:

endpoints:

    web:

      exposure:

        include: hystrix.stream

Zuul（服务网关）

微服务网关，这个组件是负责网络路由的。如果前端后端移动端调用后台系统（降低耦合度），统一走zull（Netflix下的）网关进入，由zuul网关转发请求给相应的服务。

例子：就像我们想要调用百度的某个东西，我们只要记得百度的端口就行，至于它内部有多少接口，是怎么实现的，我们都不用管。

网关的核心：路由和过滤，路由类似于统一的接入后由网关转发到具体的微服务去。

网关具有身份认证与安全、审查与监控、动态路由、负载均衡、缓存、请求分片与管理、静态响应处理等功能。

常用网关解决方案：

Nginx + Lua 作为服务端的负载均衡网关的方案存在的
Zuul 业务层网关就是把我们的微服务聚合起来 zuul1.0不支持异步，zuul2.0支持。
Kong 基于Nginx + Lua,但提供了比Nginx更简单的配置方式
Traefik 基于Go语言（并发优秀）开发的，为部署微服务更加便捷而诞生
Spring cloud gateway

Spring cloud gateway

提供了微服务网关功能，包含权限安全、监控/指标等功能。

涉及到的名词：

路由：Route，是gateway的核心

谓词：predicate，路由规则、简单的校验逻辑

过滤：filter

入门案例：

Gateway依赖eureka，需要从eureka中获取真实代理的地址后，在进行访问，所以需要准备一个eureka server

首先需要加入依赖

<dependency>

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

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

</dependency>

<dependency>

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

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

</dependency>

写入配置文件

商业开发中，enabled一般不设置，使用默认false，避免不必要的自动转发规则。

下面-Path=/api/**,才是对的

谓词判断请求参数，只判断请求头传递的参数。请求体参数不判断

Filter：

<filter>

<filter-name>sensitive</filter-name>

   <filter-class>com.google.code.lightssh.project.filter.SensitiveFilter</filter-class>

</filter>

<filter-mapping>

   <filter-name>sensitive</filter-name>

   <url-pattern>*.do</url-pattern>

</filter-mapping>

Filter 过滤器它只关心请求的地址是否匹配，不关心请求的资源是否存在(只看后缀名是否等于，不关心后缀名在现实中是否真的存在)！！！

<filter>

<filter-name>sitemesh</filter-name>

   <filter-class>com.opensymphony.sitemesh.webapp.SiteMeshFilter</filter-class>

</filter>

<filter-mapping>

   <filter-name>sitemesh</filter-name>

   <url-pattern>/*</url-pattern>

   <dispatcher>FORWARD</dispatcher>

   <dispatcher>REQUEST</dispatcher>

</filter-mapping>

Feign（服务调用）（openFeign）

什么是 Open Feign

有了 Eureka，RestTemplate，Ribbon 我们就可以愉快地进行服务间的调用了，但是使用 RestTemplate 还是不方便，我们每次都要进行这样的调用。

这样每次都调用 RestTemplate 的 API 是否太麻烦，我能不能像调用原来代码一样进行各个服务间的调用呢？

聪明的小朋友肯定想到了，那就用映射呀，就像域名和IP地址的映射。我们可以将被调用的服务代码映射到消费者端，这样我们就可以 “无缝开发”啦。

OpenFeign 也是运行在消费者端的，使用 Ribbon 进行负载均衡，所以 OpenFeign 直接内置了 Ribbon。

在导入了 Open Feign 之后我们就可以进行愉快编写 Consumer 端代码了。

然后我们在 Controller 就可以像原来调用 Service 层代码一样调用它了。

Feign的降级处理：

当使用OpenFeign调用远程服务超时会出现500错误，如果不希望出现500可以使用OpenFeign自带的Hystrix进行降级处理。

步骤：

首先需要开启feign

feign:

hystrix:

    enabled: true

加注解，fallback定义容错的处理类，也就是回退逻辑，fallback的类必须实现Feign Client的接口，否则无法知道熔断的异常信息。

@FeignClient(value = "zl-core-mall",fallbackFactory =

MallFeignClientFallbackFactory.class /* ,fallback = Hystric.class */)

记得加@Component注解

Config（配置管理）

补充：SMS--短信服务

Sleuth（链路追踪服务）

（1）微服务架构是一个分布式架构，它按业务划分服务单元

（2）一个分布式系统往往有很多个服务单元

<1>由于服务单元数量众多，业务的复杂性，如果出现了错误和异常，很难去定位

<2>主要体现在:

2.1.一个请求可能需要调用很多个服务

2.2.而内部服务的调用复杂性，决定了问题难以定位

<3>所以微服务架构中，必须实现分布式链路追踪

<4>去跟进一个请求到底有哪些服务参与，参与的顺序又是怎样的

<5>从而达到每个请求的步骤清晰可见，出了问题，很快定位

<6>Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案

（3）链路追踪开源组件：

<1>Google的Dapper，Twitter的Zipkin，以及阿里的Eagleeye （鹰眼）等

<2>Spring Cloud Sleuth集成了zipkin组件