以下是学习 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} 的形式访问这些端点，从而了解应用程序的运行情况
常用的端点及描述
添加maven
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
<version>2.0.5.RELEASE</version>
</dependency>
启动程序后访问：
看到如下界面
这里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 时，架构如下
独立使用时，架构如下
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 后的架构
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 请求所需要的配置属性。然后缓存这些属性来提高性能。
18 Spring Cloud 引导上下文
在Spring Cloud 中存在引导上下文的概念，这里的引导上下文是代表当前应用程序的父上下文。
它的主要功能是从配置服务器加载配置，以及解密外部配置文件中的属性。
和主应用程序加载application.*配置文件不同，引导上下文加载bootstrap.*配置文件。配置在bootstrap.*中的配置属性具有更高的优先级。
如果要禁用引导上下文，可以通过spring.cloud.bootstrap.enable=false来进行配置。
19 Spring Cloud Bus 架构
在微服务之间进行消息通信的时候，如果各个微服务之间进行单一的通信，效率会很低。
那这里的Bus 就是一个消息总线，比如可以统一广播修改后的配置。
架构如下：
20 Spring Cloud Sleuth
各个微服务之间是通过网路进行通信，如果能够跟踪每个请求，了解请求经过了哪些微服务，请求耗费时间，网络延迟，业务逻辑耗费时间等指标，那么就能更好的分析性能瓶颈，解决系统问题。
Sleuth 为 Spring Cloud 提供了分布式跟踪的解决方案。
21 Zipkin
Zipkin 是Twitter 开源的分布式跟踪系统，基于Dapper 的论文设计而来。
它的主要功能是收集系统的时序数据，从而追踪微服务架构的延时等问题。Zipkin 也提供了一个非常友好的界面，用户帮助分析追踪数据。
参考：
989
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
