SpringCloud的基本组件和作用的简单介绍

SpringCloud基本组件及其作用

SpringCloud集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用体验。
SpringCloud是一系列框架的有序集合。它利用SpringBoot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等，都可以用SpringBoot的开发风格做到一键启动和部署。
通过SpringBoot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

1. 注册中心：Eureka、Nacos、Consul、Zookeeper、ETCD
   关于注册中心：
   （1）zookeeper：
   zookeeper提供了“心跳检测”功能：它会定时向各个服务提供者发送一个请求（实际上建立的是一个 socket 长连接），如果长期没有响应，服务中心就认为该服务提供者已经“挂了”，并将其剔除。
   作为一个分布式协同服务，ZooKeeper非常好，但是对于Service发现服务来说就不合适了。很多时候不能接受服务直接down掉不可用。
   在 CAP 模型中，Zookeeper整体遵循一致性（CP）原则，即在任何时候对 Zookeeper 的访问请求能得到一致的数据结果，但是当机器下线或者宕机时，不能保证服务可用性。
   Zookeeper的核心算法是ZAB，所有设计都是为了强一致性。这个对于分布式协调系统，完全没没有毛病，但是你如果将Zookeeper为分布式协调服务所做的一致性保障，用在注册中心，或者说服务发现场景，这个其实就不是很合适。
   （2）Eureka 特点
   a.可用性（AP原则）
   b.去中心化架构
   c.请求自动切换
   d.节点间操作复制
   e.自动注册&心跳
   f.自动下线
   g.保护模式
   Eureka 为了保障注册中心的高可用性，容忍了数据的非强一致性，服务节点间的数据可能不一致， Client-Server 间的数据可能不一致。比较适合跨越多机房、对注册中心服务可用性要求较高的使用场景。
   (3)Nacos特点：
   a.服务发现和服务健康监测：Nacos 支持基于 DNS 和基于 RPC 的服务发现。Nacos提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 (PING 或 TCP)和应用层 (如 HTTP、MySQL、用户自定义）的健康检查。对于复杂的云环境和网络拓扑环境中（如 VPC、边缘网络等）服务的健康检查，Nacos 提供了 agent 上报模式和服务端主动检测2种健康检查模式。
   b.动态配置服务
   c.动态DNS服务
   (4)Consul
   a.CP模型，使用 Raft 算法来保证强一致性，不保证可用性；
   c.支持服务注册与发现、健康检查、KV Store功能;
   d.支持多数据中心
   e.支持安全服务通信
   f.支持http和dns协议接口
   (5)ETCD
   etcd是一个Go言编写的分布式、高可用的一致性键值存储系统，用于提供可靠的分布式键值存储、配置共享和服务发现等功能。
   ETCD特点：
   a.易使用:基于HTTP+JSON的API
   b.易部署:使用Go语言编写
   c.强一致:使用Raft算法充分保证了分布式系统数据的强一致性。
   d.高可用:具有容错能力，假设集群有n个节点，当有(n-1)/2节点发送故障，依然能提供服务。
   e.持久化:数据更新后，会通过WAL格式数据持久化到磁盘，支持Snapshot快照。
   f.快速：每个实例每秒支持一千次写操作，极限写性能可达10K QPS。
   g.安全：可选SSL客户认证机制。
   1.2、Feign
   用于实现微服务之间的声明式调用,不用自己再写http请求。Feign可以使用Feign注解或者JAX-RS注解，还支持热插拔的编码器和解码器。Spring Cloud为Feign添加了Spring MVC的注解支持，并整合了Ribbon和注册中心来为使用Feign时提供负载均衡。
   1.3、Ribbon
   服务间发起请求的时候，基于Ribbon做负载均衡，从多台机器中选择一台。
   Ribbon就属于进程内LB负载均衡，它只是一个类库，集成于消费方进程。
   根据用指定的策略，在从server取到的服务注册列表中选择一个地址。
   策略：
   （1）轮询（RoundRobinRule）：按照服务列表的顺序依次进行轮询。
   （2）随机（RandomRule）：从服务列表中随机选择一个服务实例。
   （3）最少连接数（BestAvailableRule）：是一种根据服务实例当前的连接数来选择最空闲实例的负载均衡策略。
   （4）带权重的轮询（WeightedResponseTimeRule）：根据服务实例的响应时间和权重来选择最优服务实例的负载均衡策略。响应时间越短、权重越高的服务实例被选择的概率越大。
   （5）区域敏感策略（ZoneAvoidanceRule）：基于分区下的服务器的可用性选出可用分区列表，再从可用分区列表中随机选择一个分区，采用轮询的策略选择该分区的一个服务器。
   （6）重试策略（RetryRule）：按照轮询策略来获取服务，如果获取的服务实例为 null 或已经失效，则在指定的时间之内不断地进行重试来获取服务，如果超过指定时间依然没获取到服务实例则返回 null。
   （7）可用性敏感策略（AvailabilityFilteringRule）：先过滤掉非健康的服务实例，然后再选择连接数较小的服务实例。
   1.4、Hystrix
   在微服务架构中，服务与服务之间可以相互调用（RPC），为了保证其高可用，单个服务通常会集群部署。如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet 容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的 “雪崩” 效应。
   Hystrix能够保证在一个服务出问题的情况下，避免级联故障，以提高分布式系统的弹性。
   提供服务降级、服务熔断、服务限流。
   在运行过程中，Hystrix 会根据接口的执行状态（成功、失败、超时和拒绝），收集并统计这些数据，根据这些信息来实时决策是否进行熔断。
   ・提供 fail-fast（快速失败）和快速恢复的支持。
   ・提供 fallback 优雅降级的支持。
   ・支持近实时的监控、报警以及运维操作。
   ・通过近实时的统计 / 监控 / 报警功能，来提高故障发现的速度。
   1.5、Gateway/Zuul
   （1）Spring Cloud Gateway用"Netty + Webflux"实现
   优点：①Webflux模式替换了旧的Servlet线程模型。用少量的线程处理request和response io操作，这些线程称为Loop线程，而业务交给响应式编程框架处理，响应式编程是非常灵活的，用户可以将业务中阻塞的操作提交到响应式框架的work线程中执行，而不阻塞的操作依然可以在Loop线程中进行处理，大大提高了Loop线程的利用率。
   即Webflux中的Loop线程不仅可以处理请求和响应请求，还可以对业务中不阻塞的操作进行处理，从而提高它的利用率。阻塞的操作由work线程进行处理。
   ②Webflux虽然可以兼容多个底层的通信框架，但是一般情况下，底层使用的还是Netty，毕竟，Netty是目前业界认可的最高性能的通信框架。
   Netty 是一个基于NIO的客户、服务器端的编程框架。提供异步的、事件驱动的网络应用程序框架和工具，用以快速开发高性能、高可靠性的网络服务器和客户端程序。
   特点：❶易于编写谓词( Predicates )和过滤器（ Filters ) 。其Predicates和Filters
   可作用于特定路由。
   ❷支持路径重写。
   ❸支持动态路由。
   三个术语：
   ①Filter（过滤器）：
   和Zuul的过滤器在概念上类似，可以使用它拦截和修改请求，并且对上游的响应，进行二次处理。过滤器为org.springframework.cloud.gateway.filter.GatewayFilter类的实例。
   ②Route（路由）：
   网关配置的基本组成模块，和Zuul的路由配置模块类似。一个Route模块由一个 ID，一个目标 URI，一组断言和一组过滤器定义。如果断言为真，则路由匹配，目标URI会被访问。
   ③Predicate（断言）：
   这是一个 Java 8 的 Predicate，可以使用它来匹配来自 HTTP 请求的任何内容，例如 headers 或参数。断言的输入类型是一个 ServerWebExchange。
   作用：
   ①请求路由：根据请求本身的属性把请求转发到不同的微服务是微服务网关的基本功能之一。业务运维人员需要针对不同的服务配置路由，使网关能够根据请求的 header、路径、参数、协议等属性将其转发到对应的服务。
   服务发现：网关是微服务环境的请求入口。支持服务发现能使网关在转发请求到目标服务时充分利用服务注册中心动态管理服务实例的优势，在配置路由转发的目标地址时也会更加方便。
   ②修改请求响应：网关在收到外部请求，将其转发到目标服务之前，可以根据需求对请求进行修改，比如果更改请求 header、参数等。类似地，也可以在获取到业务服务响应之后，返回给用户前对响应进行修改。
   ③权限校验：某些业务场景在处理用户请求时需要先对用户进行权限校验，这部分逻辑也可以由网关来负责。请求在到达网关时，由网关根据请求要访问的业务接口先对用户鉴权，只有校验通过的请求才会转发到对应的服务，而校验不通过的请求会被网关直接拒绝。这样做能够把拒绝无效请求这一步提前到网关这一层，减少无效的流量进入到业务服务。
   ④限流熔断：网关可以通过添加限流、熔断等机制来对业务服务起保护作用，提升系统整体的可用性。根据业务服务的吞吐量，网关可以限制转发到该服务的请求数量，超出限制的请求直接拒绝或降级，这样可以避免因为过多的请求导致业务服务负载过高的情况。当业务服务异常时，还可以通过熔断的方式到达快速失败的效果。
   ⑤请求重试：对于一些幂等的请求，当网关转发目标服务失败时，可以在网关层做自动重试。对于一些多实例部署服务，重试时还可以考虑把请求转发到不同的实例，以提高请求成功的概率。
   ⑥响应缓存：当用户请求获取的是一些静态的或更新不频繁的数据时，一段时间内多次请求获取到的数据很可能是一样的。对于这种情况可以将响应缓存起来。这样用户请求可以直接在网关层得到响应数据，无需再去访问业务服务，减轻业务服务的负担。
   ⑦响应聚合：某些情况下用户请求要获取的响应内容可能会来自于多个业务服务。网关作为业务服务的调用方，可以把多个服务的响应整合起来，再一并返回给用户。
   ⑧监控统计：因为网关是请求入口，所以在网关这一层可以方便地对外部的访问请求做监控和统计，同时还可以对业务服务的响应做监控，方便发现异常情况。
   ⑨灰度流量：网关可以用来做服务流量的灰度切换。比如某个业务服务上线了新版本，那可以在网关这一层按照灰度策略，把一部分请求流量切换到新版本服务上，以达到验证新版本业务服务的功能和性能的效果。
   ⑩异常响应处理：对于业务服务返回的异常响应，可以在网关层在返回给用户之前做转换处理。这样可以把一些业务侧返回的异常细节隐藏，转换成用户友好的错误提示返回。
   （2）Zuul是一个微服务网关
   ①支持动态路由与过滤功能。
   ②实现了请求路由、负载均衡、校验过滤、服务容错、服务聚合等功能。
   ③ 本质上是一个web servlet应用。
   ④过滤器机制：A、zuul的核心是一系列的filters, 其作用可以类比Servlet框架的Filter，或者AOP。
   B、zuul把Request route到 用户处理逻辑 的过程中，这些filter参与一些过滤处理，比如Authentication，Load Shedding等。
   C、Zuul提供了一个框架，可以对过滤器进行动态的加载，编译，运行。
   D、Zuul的过滤器之间没有直接的相互通信，他们之间通过一个RequestContext的静态类来进行数据传递的。RequestContext类中有ThreadLocal变量来记录每个Request所需要传递的数据。
   E、Zuul的过滤器是由Groovy写成，这些过滤器文件被放在Zuul Server上的特定目录下面，Zuul会定期轮询这些目录，修改过的过滤器会动态的加载到Zuul Server中以便过滤请求