[java][SpringCloid]:SpringCloud相关技术介绍

Eureka服务注册与发现

是什么

Eureka是Netflix的一个子模块，也是核心模块之一。Eureka是一个基本REST的服务，用户定位服务，以实现云端中间层服务发现和故障转移。服务注册和发现对于微服务架构来说是非常重要的，有了服务发现与注册，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了，功能类似于doubo的注册中心，比如Zookeeper.
　　遵守AP原则

三大特色

1.Eureka Server提供服务注册和发现。
　　2.Service Provider服务提供方将自身服务注册到Eureka，从而使服务消费方能够找到。
　　3.Service Consumer服务消费方从Eureka获取注册服务列表，从而能够消费服务

基本构架

Spring Cloud封装了Netflix公司开发Eureka模块来 实现服务注册和发现(请对比Zookeeper)
　　Eureka采用了C-S的设计架构。Eureka Server作为服务注册功能的服务器，它是服务注册中心。
　　而系统中的其他微服务，使用Eureka的客户端连接到Eureka Server并维持心跳连接。这样系统的维护人员就可以通过Eureka Server来监控系统中各个微服务是否正常运行。SpringCloud的一些其他模块(比如Zuul)就可以通过Eureka Server来实现系统中的其他微服务，并执行相关的逻辑。

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

自我保护

导致原因：某时刻某一个微服务不可用了，eureka不会立刻清理，依旧会对该微服务的信息进行保存。

　　什么是自我保护模式？
　　默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例(默认90秒)。但是当前网络分区故障发生时，微服务与EurekaServer之间无法正常通信，以上行为可能变得非常危险了：因为微服务本身其实是健康的，此时本不应该注销这个微服务。
　　Eureka通过“自我保护模式”来解决这个问题：当EurekaServer节点在短时间内丢失过多客户端时(可能发生了网络分区故障)，那么这个节点就会进入自我保护模式。一旦进入该模式，EurekaServer就会保护服务注册中心的信息，不再删除服务注册表捉的数据(也就不会注销任何微服务)。当网络故障收复后，该EurekaServer节点会自动退出自我保护模式。
　　在自我保护模式中，EurekaServer会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阀值以上时，该EurekaServer节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。一句话讲：好死不如耐活着。
　　综上，自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有的微服务(健康的微服务和不健康的微服务都会保留)，也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加健壮、稳定。

　　在Spring Cloud中，可以使用eureka.server.enable-self-preservation = false 禁用自我保护模式，不建议关闭

与Dobbo比较

Eureka01.jpeg

Eureka02.jpeg

服务发现

对于注册进eureka里面的微服务，可以通过服务发现来获得该服务的信息 　　

作为服务注册中心，eureka比zookeeper好在哪里？

著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)，A(高可用), P(分区容错性)。由于分区容错性P在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。
　　Zookeeper保证了CP，Eureka保证了AP.
　　Eureka各个节点是平等的；Zookeeper：一个领导者（leader），多个跟随者（follower）组成的集群。集群中只要有半数以上(>)节点存活，Zookeeper集群就能正常服务。部署一般部署奇数台
　　1.Zookeeper保证了CP
　　当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的信息，但不能容忍直接down掉不可用。也就是说，服务注册功能对高可用性要求比较高，但zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新选leader。问题在于，选取leader时间过长，30 ~ 120s，且选取期间zk集群都不可用，这样就会导致选取期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够恢复，但是漫长的选取时间导致的注册长期不可用是不能容忍的。
　　2.Eureka保证了AP
　　Eureka保证了可用性，Eureka各个节点是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点仍然可以提供注册和查询服务。而Eureka的客户端向某个Eureka注册或发现是发生连接失败，则会自动切换到其他节点，只要有一台Eureka还在，就能保证注册服务可用，只是查到的信息可能不是最新的。除此之外，Eureka还有自我保护机制，如果在15分钟内超过85%的节点没有正常的心跳，那么Eureka就认为客户端与注册中心发生了网络故障，此时会出现以下几种情况：
　　　　①、Eureka不在从注册列表中移除因为长时间没有收到心跳而应该过期的服务。
　　　　②、Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点仍然可用）
　　　　③、当网络稳定时，当前实例新的注册信息会被同步到其他节点。
　　因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像Zookeeper那样使整个微服务瘫痪。
　　Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样整个注册服务瘫痪

Ribbon负载均衡(客户端)

配置完成后：完成真正的通知微服务名字从eureka上找到并访问

是什么

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

能干嘛

LB(负载均衡)，在微服务或分布式集群中经常用到的一种应用。负载均衡简单的说就是将用户的请求平摊到多个服务上，从而达到系统的HA(高可用)。
　　常见的负载均衡有软件Nginx，LVS，硬件F5等。
　　相应的中间件，如doubbo和SpringCloud中均给我们提供了负载均衡，SpringCloud的负载均衡算法可自定义。

　　1.集中式LB
　　即在服务的消费方和提供方之间使用独立的LB设施(可以是硬件，如F5，也可以是软件，如nginx)，由该设施负责把访问请求通过某种策略转发至服务的提供方。

　　2.进程内LB
　　将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的服务器。
　　Ribbon属于进程内LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址。

负载均衡

架构说明

Ribbon01.jpeg

Ribbon在工作时分成两步：
　　1.先选择EurekaServer，它优先选择在同一个区域内负载较少的server。
　　2.再根据用户指定的策略，在从server取到的服务注册列表中选择一个地址。
　　其中Ribbon提供了多种策略：如轮询、随机等。

　　总结：Ribbon其实就是一个软负载均衡的客户端组件，它可以和其他所需请求的客户端结合使用，和eureka结合只是其中的一个实例

核心组件IRule：负载均衡算法

IRule: 根据特定算法从服务列表中选取一个要访问的服务
　　默认有7种算法：
　　1.RoundRobinRule：轮询
　　2.RandomRule：随机
　　3.AvailabilityFilteringRule
　　4.WeightedResponseTimeRule
　　5.RetryRule：先按照RoundRobinRule的策略获取服务，如果获取服务失败则在指定时间内会进行重试，获取可用的服务
　　6.BestAvailableRule
　　7.ZoneAvoidanceRule

　　自定义算法：
　　自定义MySelfRule类不能在该主启动类当前包及子包下。也就是不能放在@ComponentScan所扫描的当前包下及子包下，（@SpringBootApplication 注解里有@ComponentScan）

Feign负载均衡

Feign是什么

Feign是一个声明式WebService客户端。使用Feign能让编写Web Service客户端更加简单，这的使用方法是定义一个接口，然后在上面添加注解，同时也支持JAX-RS标准的注解。Feign也支持可拔插式的编码器和解码器。SpringCloud对Feign进行了封装，使其支持了Spring MVC标准注解和HttpMessageConverters。Feign可以与Eureka和Ribbon组合使用以支持负载均衡。
　　Feign是一个声明式的Web服务客户端，使得编写Web服务客户端变得非常容易，**只需要创建一个接口，然后在上面添加注解即可**。也就是面向接口编程
　　[官网资料](https://github.com/OpenFeign/feign)

Feign能干嘛

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

实例说明

Feign集成了Ribbon
　　利用Ribbon维护了SrpingCloud-dept的服务列表信息，并且通过轮询实现了客户端的负载均衡。而与Ribbon不同的是，**利用feign只需要定义服务绑定接口且以声明式的方法**，优雅而简单的实现了服务调用。
　　Feign通过接口的方法调用Rest服务(之前是Ribbon + RestTemplate)，该请求发送给Eureka服务器([http://Spring-cloud-dept/dept/list)，通过Feign直接找到服务接口，由于在进行服务调用的时候融合了Ribbon技术，所以也支持负载均衡作用。](http://spring-cloud-dept/dept/list)%EF%BC%8C%E9%80%9A%E8%BF%87Feign%E7%9B%B4%E6%8E%A5%E6%89%BE%E5%88%B0%E6%9C%8D%E5%8A%A1%E6%8E%A5%E5%8F%A3%EF%BC%8C%E7%94%B1%E4%BA%8E%E5%9C%A8%E8%BF%9B%E8%A1%8C%E6%9C%8D%E5%8A%A1%E8%B0%83%E7%94%A8%E7%9A%84%E6%97%B6%E5%80%99%E8%9E%8D%E5%90%88%E4%BA%86Ribbon%E6%8A%80%E6%9C%AF%EF%BC%8C%E6%89%80%E4%BB%A5%E4%B9%9F%E6%94%AF%E6%8C%81%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1%E4%BD%9C%E7%94%A8%E3%80%82)

Hystrix断路器

概述

分布式系统面临的问题

复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系某些时候不可避免地失败
　　服务雪崩：
　　多个微服务之前调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微微服务C又调用其他的微服务，这就是所谓的”扇出“.如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的”雪崩效应”。
　　对于高流量的应用来说，单一的后端依赖可能会导致所有的服务器上的所有资源都会在几秒内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。

是什么

Hystrix是一个用于处理分布式系统 **延迟** 和 **容错** 的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时，异常等，Hystrix能够保证在一个依赖出问题的情况下，**不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性**。
　　“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控(类似熔断保险丝)，**向调用方法回一个符合预期的、可处理的备选响应(FallBack)，而不是长时间的等待或者抛出调用方式无法处理的异常**，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，及至雪崩。
　　[官网资料](https://github.com/Netflix/Hystrix/wiki)

能干嘛

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

服务熔断

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

服务降级

是什么：整体资源快不够了，忍痛将某些服务先关掉，待渡过难关，再开启回来
　　服务降级处理是在 客户端实现完成的，与服务端没什么关系。
　　此时服务端provider已经down了，但是我们做了服务降级处理，让客户端在服务端不可用时也会获得提示信息而不会挂起耗死服务器

服务熔断与服务降级总结

熔断机制 是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务降级，进而熔断该节点微服务的调用，快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现，Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内调用20次，如果失败，就会启动熔断机制。熔断机制的注解是@HystrixCommand
　　服务降级，一般是从整体负荷考虑。就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。这样做，虽然水平下降，但好歹可用，比直接挂掉强。
　　
　　服务熔断：一般是某个服务故障或者异常引起，类似现实世界中的”保险丝”，当某个异常条件被触发，直接熔断整个服务，而不是一直等到此服务超时。
　　服务降级：所谓降级，一般是从整体负荷考虑。就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallbask回调，返回一个缺省值。这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强。

服务监控HystrixDashboard

是什么

除了隔离依赖服务的调用以外，Hystrix还提供了 准实时的调用监控(Hystrix Dashboard)，Hystrix会持续记录所有通过Hystrix发送的请求的执行信息，并以统计报表的图形的形式展示给用户，包括每秒执行多少请求、多少成功、多少失败等。Netflix通过hystrix-metrics-event-stream项目实现了对以上指标的监控。SpringCloud也提供了Hystrix Dashboard的整合，对监控内容转化成可视化界面。

观察监控窗口

启动后，http://localhost:9001/hystrix,可以看到页面如下

hystrix.png

监控http://localhost:8001/hystrix.stream。如果看：7色、1圈、1线
　　7色：

hystrix01.png.jpeg

1圈：实心圆：共有两种含义。
　　　　颜色：代表实例的健康程度，健康度从绿色<黄色<橙色<红色递减。
　　　　大小：根据实例的请求流量发生变化，流量越大该实心圆越大。
　　　　通过该实心圆的展示，可以在大量的实例中快速的发现 故障实例和高压力实例。

hystrix02.png.jpeg

zuul路由网关

概述

是什么：
　　zuul包含了对请求的 **路由** 和 **过滤** 两个最主要的功能：
　　其中路由功能能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础。而过滤器功能则对请求的处理过程进行干预，是实现请求检验、服务聚合等功能的基础。Zuul和Eureka进行整合，将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他微服务的消息，也即以后的访问微服务都是通过Zuul跳转后获得。
　　注意：**Zuul服务最终还是会注册进Eureka**
　　**提供=代理 + 路由 + 过滤三大功能**

　　能干嘛：路由、过滤
　　[官网资源](https://github.com/Netflix/zuul/wiki)

分布式配置中心

概述

分布式系统面临的：配置问题

微服务意味着要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行，所以一套集中式、动态的配置管理设施是必不可少的。SpringCloud提供了ConfigServer来解决这个问题，我们每一个微服务自己带着一个application.yml，上百个配置文件的管理无法想象。

是什么

springCloudConfig.jpeg

SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为 各个不同微服务应用 的所有环境提供了　一个中心化的外部配置.
　　SpringCloud Config分为 服务端和客户端两部分。
　　服务端也称为 分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提供获得配置信息，加密/解密信息等访问接口。
　　客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理，并且可以通过git客户端工具来方便的管理和访问配置内容。

能干嘛

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