Cloud组件笔记_java

Spring Cloud综述

Spring Cloud是什么？

Spring Cloud解决了什么问题

Spring Cloud核心组件

Spring Cloud体系结构

Eureka服务注册中心

关于服务注册中心

服务注册中心组件Eureka

Ribbon负载均衡

关于负载均衡

Ribbon应用

Ribbon负载均衡策略

Ribbon工作原理

Feign组件

Feign对负载均衡的⽀持

Feign对熔断器的⽀持

GateWay⽹关组件

GateWay概念

GateWay工作过程（How It Works）

GateWay路由规则、动态路由

GateWay过滤器

GateWay⾼可⽤

SCA Nacos

Nacos介绍

Nacos服务注册中心X

Nacos 配置中⼼

Spring Cloud综述 Spring Cloud是什么？

[百度百科]Spring Cloud是⼀系列框架的有序集合。它利⽤Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中⼼、消息总线、负载均衡、断路器、数据监控等，都可以⽤ Spring Boot的开发⻛格做到⼀键启动和部署。Spring Cloud并没有重复制造轮⼦，它只是将⽬前各家公司开发的⽐较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot⻛格进⾏再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了⼀套简单易懂、易部署和易维护的分布式系统开发⼯具包。

Spring Cloud是⼀系列框架的有序集合（Spring Cloud是⼀个规范）

开发服务发现注册、配置中⼼、消息总线、负载均衡、断路器、数据监控等

利⽤Spring Boot的开发便利性简化了微服务架构的开发（⾃动装配）

Spring Cloud解决了什么问题

Spring Cloud 规范及实现意图要解决的问题其实就是微服务架构实施过程中存在的⼀些问题，⽐如微服务架构中的服务注册发现问题、⽹络问题（⽐如熔断场景）、统⼀认证安全授权问题、负载均衡问题、链路追踪等问题。

Spring Cloud核心组件

Spring Cloud ⽣态圈中的组件，按照发展可以分为第⼀代 Spring Cloud组件和第⼆代 Spring Cloud组件。

Spring Cloud体系结构

Spring Cloud中的各组件协同⼯作，才能够⽀持⼀个完整的微服务架构。⽐如

注册中⼼负责服务的注册与发现，很好将各服务连接起来
API⽹关负责转发所有外来的请求
断路器负责监控服务之间的调⽤情况，连续多次失败进⾏熔断保护。
配置中⼼提供了统⼀的配置信息管理服务,可以实时的通知各个服务获取最新的
配置信息

各组件整体结构：

Eureka服务注册中心关于服务注册中心

注意：服务注册中⼼本质上是为了解耦服务提供者和服务消费者。

对于任何⼀个微服务，原则上都应存在或者⽀持多个提供者，这是由微服务的分布式属性决定的。

更进⼀步，为了⽀持d性扩缩容特性，⼀个微服务的提供者的数量和分布往往是动态变化的，也是⽆法预先确定的。因此，原本在单体应⽤阶段常⽤的静态LB机制就不再适⽤了，需要引⼊额外的组件来管理微服务提供者的注册与发现，⽽这个组件就是服务注册中⼼。

服务注册中心一般原理

分布式微服务架构中，服务注册中⼼⽤于存储服务提供者地址信息、服务发布相关的属性信息，消费者通过主动查询和被动通知的⽅式获取服务提供者的地址信息，⽽不再需要通过硬编码⽅式得到提供者的地址信息。消费者只需要知道当前系统发布了那些服务，⽽不需要知道服务具体存在于什么位置，这就是透明化路由。

服务注册中心组件Eureka

Eureka基础架构
Eureka交互流程及原理

Eureka 包含两个组件：Eureka Server 和 Eureka Client，Eureka Client是⼀个Java客户端，⽤于简化与Eureka Server的交互；Eureka Server提供服务发现的能⼒，各个微服务启动时，会通过Eureka Client向Eureka Server 进⾏注册⾃⼰的信息（例如⽹络信息），Eureka Server会存储该服务的信息；

Eureka通过⼼跳检测、健康检查和客户端缓存等机制，提⾼系统的灵活性、可伸缩性和可⽤性。

Ribbon负载均衡关于负载均衡

负载均衡⼀般分为服务器端负载均衡和客户端负载均衡

所谓服务器端负载均衡，⽐如Nginx、F5这些，请求到达服务器之后由这些负载均衡器根据⼀定的算法将请求路由到⽬标服务器处理。

所谓客户端负载均衡，⽐如我们要说的Ribbon，服务消费者客户端会有⼀个服务器地址列表，调⽤⽅在请求前通过⼀定的负载均衡算法选择⼀个服务器进⾏访问，负载均衡算法的执⾏是在请求客户端进⾏。

Ribbon是Netflflix发布的负载均衡器。Eureka⼀般配合Ribbon进⾏使⽤，Ribbon利⽤从Eureka中读取到服务信息，在调⽤服务提供者提供的服务时，会根据⼀定的算法进⾏负载。

Ribbon应用

代码中使⽤，在RestTemplate上添加对应注解即可，比如@LoadBalanced

Ribbon负载均衡策略

Ribbon内置了多种负载均衡策略，内部负责复杂均衡的顶级接⼝为com.netflflix.loadbalancer.IRule

负载均衡策略	描述
RoundRobinRule：轮询策略	默认超过10次获取到的server都不可⽤，会返回⼀个空的server
RandomRule：随机策略	如果随机到的server为null或者不可⽤的话，会while不停的循环选取
RetryRule：重试策略	⼀定时限内循环重试。默认继承RoundRobinRule，也⽀持⾃定义注⼊，RetryRule会在每次选取之后，对选举server进⾏判断，是否为null，是否alive，并且在500ms内会不停的选取判断。⽽RoundRobinRule失效的策略是超过10次，RandomRule是没有失效时间的概念，只要serverList没都挂。
BestAvailableRule：最⼩连接数策略	遍历serverList，选取出可⽤的且连接数最⼩的⼀个server。该算法⾥⾯有⼀个LoadBalancerStats的成员变量，会存储所有server的运⾏状况和连接数。如果选取到的server为null，那么会调⽤RoundRobinRule重新选取。1（1） 2（1）3（1）
AvailabilityFilteringRule：可⽤过滤策略	扩展了轮询策略，会先通过默认的轮询选取⼀个server，再去判断该server是否超时可⽤，当前连接数是否超限，都成功再返回。
ZoneAvoidanceRule：区域权衡策略（默认策略）	扩展了轮询策略，继承了2个过滤器：ZoneAvoidancePredicate和AvailabilityPredicate，除了过滤超时和链接数过多的server，还会过滤掉不符合要求的zone区域⾥⾯的所有节点，AWS --ZONE 在⼀个区域/机房内的服务实例中轮询

Ribbon工作原理

重点：Ribbon给restTemplate添加了⼀个拦截器LoadBalancerInterceptor

思考：Ribbon在做什么：

服务当我们访问服务的时候，ribbon应该根据服务名获取到该服务的实例列表并按照⼀定的负载均衡策略从实例列表中获取⼀个实例Server，并最终通过RestTemplate进⾏请求访问

Feign组件

Feign = RestTemplate + Ribbon + Hystrix

Feign是⼀个轻量级RESTful的HTTP服务客户端（⽤它来发起请求，远程调⽤的），是以Java接⼝注解的⽅式调⽤Http请求，⽽不⽤像Java中通过封装HTTP请求报⽂的⽅式直接调⽤

本质：封装了Http调⽤流程，更符合⾯向接⼝化的编程习惯，类似于Dubbo的服务调用

Feign可帮助我们更加便捷，优雅的调⽤HTTP API：不需要我们去拼接url然后呢调⽤restTemplate的api，在SpringCloud中，使⽤Feign⾮常简单，创建⼀个接⼝（在消费者--服务调⽤⽅这⼀端），并在接⼝上添加⼀些注解，代码就完成了
SpringCloud对Feign进⾏了增强，使Feign⽀持了SpringMVC注解（OpenFeign）

Feign对负载均衡的⽀持

Feign 本身已经集成了Ribbon依赖和⾃动配置，因此我们不需要额外引⼊依赖，可以通过 ribbon.xx 来进⾏全局配置,也可以通过服务名.ribbon.xx 来对指定服务进⾏细节配置配置

Feign默认的请求处理超时时⻓1s，有时候我们的业务确实执⾏的需要⼀定时间，那么这个时候，我们就需要调整请求处理超时时⻓，Feign⾃⼰有超时设置，如果配置Ribbon的超时，则会以Ribbon的为准

Feign对熔断器的⽀持

在Feign客户端⼯程配置⽂件（application.yml）中开启Feign对熔断器的⽀持

当前有两个超时时间设置（Feign/hystrix），熔断的时候是根据这两个时间的最⼩值来进⾏的，即处理时⻓超过最短的那个超时时间了就熔断进⼊回退降级逻辑

GateWay⽹关组件

旨在为微服务架构提供⼀种简单有效的统⼀的API路由管理⽅式。

GateWay概念

Spring Cloud GateWay不仅提供统⼀的路由⽅式（反向代理）并且基于 Filter(定义过滤器对请求过滤，完成⼀些功能) 链的⽅式提供了⽹关基本的功能，例如：鉴权、流量控制、熔断、路径重写、⽇志监控等。

Spring Cloud GateWay天⽣就是异步⾮阻塞的，基于Reactor模型

路由（route）：⽹关最基础的部分，也是⽹关⽐较基础的⼯作单元。路由由⼀个ID、⼀个⽬标URL（最终路由到的地址）、⼀系列的断⾔（匹配条件判断）和Filter过滤器（精细化控制）组成。如果断⾔为true，则匹配该路由。
断⾔（predicates）：参考了Java8中的断⾔java.util.function.Predicate，开发⼈员可以匹配Http请求中的所有内容（包括请求头、请求参数等）（类似于nginx中的location匹配⼀样），如果断⾔与请求相匹配则路由。
过滤器（fifilter）：⼀个标准的Spring webFilter，使⽤过滤器，可以在请求之前或者之后执⾏业务逻辑。

其中，Predicates断⾔就是我们的匹配条件，⽽Filter就可以理解为⼀个⽆所不能的拦截器，有了这两个元素，结合⽬标URL，就可以实现⼀个具体的路由转发。

GateWay工作过程（How It Works）

客户端向Spring Cloud GateWay发出请求，然后在GateWay Handler Mapping中找到与请求相匹配的路由，将其发送到GateWay Web Handler；Handler再通过指定的过滤器链来将请求发送到我们实际的服务执⾏业务逻辑，然后返回。过滤器之间⽤虚线分开是因为过滤器可能会在发送代理请求之前（pre）或者之后（post）执⾏业务逻辑。

Filter在“pre”类型过滤器中可以做参数校验、权限校验、流量监控、⽇志输出、协议转换等，在“post”类型的过滤器中可以做响应内容、响应头的修改、⽇志的输出、流量监控等。

GateWay核⼼逻辑：路由转发+执⾏过滤器链

GateWay路由规则、动态路由

GateWay 帮我们内置了很多 Predicates功能，实现了各种路由匹配规则（通过 Header、请求参数等作为条件）匹配到对应的路由。

GateWay⽀持⾃动从注册中⼼中获取服务列表并访问，即所谓的动态路由

pom.xml中添加注册中⼼客户端依赖（因为要获取注册中⼼服务列表，eureka客户端已经引⼊）

GateWay过滤器

从过滤器⽣命周期（影响时机点）的⻆度来说，主要有两个pre和post：

pre	这种过滤器在请求被路由之前调⽤。我们可利⽤这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。
post	这种过滤器在路由到微服务以后执⾏。这种过滤器可⽤来为响应添加标准的 HTTP Header、收集统信息和指标、将响应从微服务发送给客户端等。

从过滤器类型的⻆度，Spring Cloud GateWay的过滤器分为GateWayFilter和GlobalFilter两种