spring cloud概念总结

1.eureka(注册与发现)

Eureka是由Netflix(公司)开发的服务发现框架，本身是一个基于RESTful的服务，主要用于定位运行在亚马逊域中的中间层服务

由两个组件组成：Eureka Server和Eureka Client。Eureka Server提供服务注册服务，各个节点启动后，会在Eureka Server中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。Eureka Client即为微服务节点

Eureka Client启动后，将会注册到Eureka Server中，同时会定时发送心跳（默认无配置情况下为30s），如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，那么Eureka Server将会从服务注册表中把这个节点移除(默认90s)


Eureka Server之间通过复制的方式完成数据同步，Eureka还提供了客户端缓存机制，即使所有的Eureka Server都挂掉，客户端依然可以利用缓存中的信息消费其他服务的API。


综上，Eureka通过心跳检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性。



进入自我保护模式时，此时会出现以下几种情况:
① Eureka Server 不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。
② Eureka Server 仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上，保证当前节点依然可用。
③ 当网络稳定时，当前Eureka Server新的注册信息会被同步到其它节点中。
自我保护机制通过配置 eureka.server.enable-self-preservation 来开启/关闭，默认开启


eureka.instance.lease-renewal-interval-in-seconds: 30 --服务和注册中心的心跳间隔时间，默认为30s
eureka.instance.lease-expiration-duration-in-seconds: 90  --服务和注册中心的心跳超时时间，默认为90s

2.Hystrix(断路器容错)

如果服务提供者相应非常慢，那么消费者对提供者的请求就会被强制等待，知道提供者响应或超时。在高负载场景下，如果不作任何处理，此类问题可能会导致服务消费者的资源耗竭甚至整个系统崩溃。
微服务架构的应用系统通常包含多个服务层。微服务之间通过网络进行通信，从而支撑起整个应用系统，因此，微服务之间难免存在依赖关系。而这种由于"基础服务故障"导致"级联故障"的现象称为雪崩效应

如果A最为服务提供者（基础服务），B为A的服务消费者，C和D是B的服务消费者。当A不可用引起了B的不可用，并将不可用像滚雪球一样放大到C和D时，雪崩效应就形成了

使用断路器模式：断路器可理解为对容易导致错误操作的代理。这种代理能够统计一段时间内调用失败的次数，并决定是正常请求依赖的服务还是直接返回；断路器可以实现快速失败，如果它在一段时间内检测到许多类似的错误(例如超时)，就会在之后的一段时间内，强迫对该服务的调用快速失败，即不请求所依赖的服务。这样，应用程序就无须再浪费CPU时间去等待长时间的超时。断路器也可以自动诊断依赖的服务是否已经恢复正常，如果发现依赖的服务已经恢复正常，那么就会恢复请求该服务



流程:
正常情况下，断路器关闭，可以正常请求依赖的服务；

当一段时间内，请求失败率达到一定阈值（例如错误率达到50%，或100次/分钟等），断路器就会打开，此时，就不会再去请求依赖的服务；
断路器打开一段时间后，会自动进入"半开"状态。此时，断路器允许一个请求访问依赖的服务。如果请求能够调用成功，则关闭断路器；否则继续保持打开状态

3.Ribbon(负载均衡器)

Ribbon(负载均衡器)的作用正是提供负载均衡机制，当为Ribbon配置服务提供者地址列表后，Ribbon就可以基于某种负载均衡算法，自动地帮助服务消费者去请求。


Ribbon提供的负载均衡算法有多种，例如轮询、加权响应时间、随机和区域感知轮询。


Ribbon与Eureka配合使用时，Ribbon可自动从Eureka Server获取服务提供者地址列表，并基于负载均衡算法，请求其中一个服务提供者示例。

4.Zuul(微服务网关)

微服务架构经过前几个组件的组合，已经有了基本的雏形了，那么我们为什么还要使用微服务网关呢？我们可以想象，一般情况下我们一个业务并不是只调用一个接口就可以完成一个业务需求

不使用Zuul的问题如下:
客户端会多次请求不同的微服务，增加了客户端的复杂性；

存在跨域请求，在一定场景下处理相对复杂；

认证复杂，每个服务都需要独立认证；

难以重构，随着项目的迭代，可能需要重新划分微服务，如果直接与微服务通信，那么重构会很难实施

使用Zuul的优点如下:
易于监控；
易于认证：
可在微服务网关上进行认证，然后再将请求转发到后端的微服务，而无须在每个微服务中进行认证；
减少了客户端与各个微服务之间的交互次数，微服务网关封装了应用程序的内部结构，客户端只须跟网关交互，而无须直接调用特定微服务接口

zuul的核心是一系列的filters, 其作用可以类比Servlet框架的Filter，或者AOP