Spring Cloud 学习汇总

小咪咪 2022-05-10 04:48 123阅读 0赞

以下是学习 Spring Cloud 的一些细节汇总

--------------------

## 1 yml  ##

Spring Boot 和 Spring Cloud 支持使用properties 和 yml 格式的文件 作为配置文件。

yml : 是（Yet Another Markup Language） 编写的文件格式

yml 比 properties 文件更加简洁，清晰，可读性强（相较于xml）。

--------------------

## 2 actuator ##

Actuator 提供了很多监控端点。可使用http://\{ip\}:\{port\}/\{endpoint\} 的形式访问这些端点，从而了解应用程序的运行情况

常用的端点及描述

![20180925221245836][]

添加maven

<dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
        <version>2.0.5.RELEASE</version>
    </dependency>

启动程序后访问：

[http://localhost:8082/health][http_localhost_8082_health]

[http://localhost:8082/info][http_localhost_8082_info]

看到如下界面

![20180925220830284][]

![20180925220846926][]

这里info 的展示信息是在配置文件自己配置的

info:
      app:
        name: @project.artifactId@

--------------------

## 3 Eureka Server 默认也是Eureka Client ##

默认情况下，Eureka Server 也是Eureka Client，它会向Eureka server 集群中的每个server 进行注册。

多个Eureka Server 实例，**互相之间通过复制的方式**，来实现服务注册表中数据的同步。

当然这个可以通过配置eureka.clien.registerWithEureka:false 来关闭注册，在单Eureka 模式下。

--------------------

## 4 Eureka 的高可用 ##

单Eureka 模式，在Eureka server 宕机的时候，会导致整个服务不可用，（当然，Erueka 客户端会缓存服务列表，仍然可用，但是如果此时服务提供者也宕调，那么就会出现不一致的现象）

--------------------

## 5 Eureka 的自我保护模式 ##

Eureka Server 默认在90s 如果没有收到 Eureka Client 的心跳，那么会在服务列表中移除这个服务，也就是**注销该服务**。

但是在一些特殊的情况下，比如网络不好时，微服务与Eureka Server 之间无法正常通信，此时如果Eureka Server 直接将Eureka Client 注销，那将出现不可预测的后果，移除后可能并不是实际想要的效果。

这个时候Eureka Server 通过开启“自我保护”，在短时间内，如果丢失大量的 Eureka Client 时。就会保护服务注册列表中的信息，不再删除服务注册列表中的数据。当网络故障恢复后，会自动退出“自我保护”模式。

当然这里默认开启的自我保护模式，可以可以通过eureka.server.enable-self-preservation = false 进行配置的。

--------------------

## 6 Ribbon 负载均衡 ##

Ribbon 负载均衡可以依赖 Eureka 使用，也可以独立使用

使用Erueka 时，架构如下

![20180927101904978][]

独立使用时，架构如下

![20180927101920115][]

--------------------

## 7 Ribbon 是客户端负载均衡 ##

Ribbon 主要是配置的客户端，在调用服务提供者时，采用负载均衡策略。因为同一个服务，可能有多个服务实例。

服务调用者采用负载均衡策略提高调用效率。

--------------------

## 8 Feign 声明式Rest 调用 ##

传统的Rest 调用，使用RestTemplate 的方式，在参数比较多的时候，代码很低效，冗余，不可复用。

Spring Cloud 体系中的Feign 就是封装的 Rest 客户端，Feign 可让我们更加方便，优雅的使用Rest API。

--------------------

## 9 自定义Feign 配置 ##

可以自定义Feign 的Configuration ，指定一些默认的契约。

然后再创建FeignClient 指定这个配置类即可。

--------------------

## 10 当依赖的服务不可用时，服务自身会不会拖垮 ##

在调用依赖的服务崩掉后，不断的去请求依赖的服务，如果没有返回，或者响应超时，在大并发时，自身会不会被拖垮？

--------------------

## 11 微服务的雪崩效应 ##

各个微服务不一定百分百可用，网络也不能保证一直是稳定的，当出现这种**由一个微服务不可用，导致多个微服务不可用的情况就是微服务中的雪崩效应**。服务提供者不可用导致了服务调用者不可用，并将这中效应不断放大。

--------------------

## 12 微服务的容错机制 ##

如何防止上面微服务的雪崩效应？在出现一个服务不可用，需要一个好的容错机制。

一方面需要对**请求设置超时时间**，因为每一个调用，每一个请求，都会对应一个进程/线程。如果在网络不好时，大量的请求，没有返回就会同时开启大量的进程/线程，都是对应着cpu 资源，这样会耗尽资源。

另一方面，当服务能都检测到短时间内有大量的失败请求时，说明此服务可能出了故障，没有必要再继续进行请求了。**在一段时间后，可以再适当的让请求分到此服务**，如果能正常调用，说明此服务恢复了故障，这也是微服务的"自我修复"。这个就**是断路器模式**。

--------------------

## 13 Hystrix 实现容错 ##

这里的Hystrix 实现容错就是，封装了上面的，**实现超时时间和断路器模式的类库**。

实现容错的主要是通过一下几点：

（1）包裹请求

（2）跳闸机制

（3）资源隔离

（4）监控

（5）回退机制

（6）自我修复

--------------------

## 14 Hystrix 的监控 ##

通过/hystrix.tream 实现单个微服务的监控

通过Turbine 的/turbine.stream 实现对多个微服务的监控

引入Turbine 后的架构

![20181009185823282][]

--------------------

## 15 zuul 路由时，忽略指定的微服务 ##

在zuul 做微服务的路由时，如果有些微服务不需要zuul 进行路由，可以进行zuul.ignored-services 配置需要忽略的服务。多个用逗号进行分隔。

--------------------

## 16 zuul 的高可用 ##

因为现在所有的请求都是先到zuul 进行处理，所以需要高可用的zuul。

--------------------

## 17 Spring Cloud Config ##

Config Client 是Config Server 的客户端，用于操作存储在Config server 中的配置属性。如下所示，所有的微服务都指向Config Server 。各个微服务在启动时向Config Server 请求所需要的配置属性。然后缓存这些属性来提高性能。

![20181011183112940][]

--------------------

## 18 Spring Cloud 引导上下文 ##

在Spring Cloud 中存在引导上下文的概念，这里的引导上下文是代表当前应用程序的父上下文。

它的主要功能是**从配置服务器加载配置，以及解密外部配置文件中的属性**。

和主应用程序加载application.\*配置文件不同，引导上下文加载bootstrap.\*配置文件。配置在bootstrap.\*中的配置属性具有更高的优先级。

如果要禁用引导上下文，可以通过spring.cloud.bootstrap.enable=false来进行配置。

--------------------

## 19 Spring Cloud Bus 架构 ##

在微服务之间进行消息通信的时候，如果各个微服务之间进行单一的通信，效率会很低。

那这里的Bus 就是一个消息总线，比如可以统一广播修改后的配置。

架构如下：

![2018101118505642][]

--------------------

## 20 Spring Cloud Sleuth ##

各个微服务之间是通过网路进行通信，如果能够跟踪每个请求，了解请求经过了哪些微服务，请求耗费时间，网络延迟，业务逻辑耗费时间等指标，那么就能更好的分析性能瓶颈，解决系统问题。

Sleuth 为 Spring Cloud 提供了分布式跟踪的解决方案。

--------------------

## 21 Zipkin ##

Zipkin 是Twitter 开源的分布式跟踪系统，基于Dapper 的论文设计而来。

它的主要功能是收集系统的时序数据，从而追踪微服务架构的延时等问题。Zipkin 也提供了一个非常友好的界面，用户帮助分析追踪数据。

--------------------

**参考：**

方志鹏   [https://blog.csdn.net/forezp/article/details/70148833][https_blog.csdn.net_forezp_article_details_70148833]

[20180925221245836]: /images/20220510/df0056d61bb0483cbaea9118cc5c237c.png
[http_localhost_8082_health]: http://localhost:8082/health
[http_localhost_8082_info]: http://localhost:8082/info
[20180925220830284]: /images/20220510/581d35cc68c141f4800838731d74e766.png
[20180925220846926]: /images/20220510/6aa703e46d394c4c9aa8d14f278210d2.png
[20180927101904978]: /images/20220510/4769a7425c3d4c4b9d432458af85227b.png
[20180927101920115]: /images/20220510/c17095ca12544c0a89dbce20b61374f5.png
[20181009185823282]: /images/20220510/5b4a06c6354b4d74bd7edab8ae85580e.png
[20181011183112940]: /images/20220510/645c1944f14747e8b8829253c02b020e.png
[2018101118505642]: /images/20220510/45d5c8fe70054fbcbd30c1fcc04f16fa.png
[https_blog.csdn.net_forezp_article_details_70148833]: https://blog.csdn.net/forezp/article/details/70148833