springcloud微服务一站式解决方案笔记整理

单体应用： model model1 --》mvc模式 model view  controller
垂直应用：相当于微服务项目，每个模块差分为服务：
rpc分布式应用：
soa流动是计算架构：微服务，查分的更加小

springcloid=分布式微服务架构的一站式解决方案，是多种微服务架构落地的集合体，速成微服务全家桶，之中包括多种技术
    服务的注册与发现，服务调用，服务熔断，负载均衡，服务降级，服务消息队列，配置中心，服务网关，服务监控，
    全链路追中，自动化构建部署，服务定时任务
springcloud 服务注册与发现第一代eureka，但是先在已经停更，替换注册中心的有zookeeper，consul(G语言开发)，nacos（阿里）
            服务调用：ribbon，feign，openfeign(推荐)
            服务降级：Hystrix(国内大部分使用),sentienl(阿里)
            服务网关：zuul(停更)  gateway（主流）
            服务配置：config（停更）Nacos(推荐)
            服务总线：Bus（停更） Nacos(推荐)
微服务创建：
    1创建module，2 改pom，3写application.yml ,4 启动类， 5业务类
        业务类：1 建表sql 2 实体类 3 dao 4 service 5 controller
什么是服务治理：
    Spring Cloud 封装了 Netflix 公司开发的 Eureka 模块来实现服务治理
    在传统的rpc远程调用框架中，管理每个服务与服务之间依赖关系比较复杂，管理比较复杂，所以需要使用服务治理，
    管理服务于服务之间依赖关系，可以实现服务调用、负载均衡、容错等，实现服务发现与注册。
什么是服务注册与发现：
    Eureka采用了CS的设计架构，Eureka Server 作为服务注册功能的服务器，它是服务注册中心。而系统中的其他微服务，
    使用 Eureka的客户端连接到 Eureka Server并维持心跳连接。这样系统的维护人员就可以通过 Eureka Server 来监控系统中各个微服务是否正常运行。
    在服务注册与发现中，有一个注册中心。当服务器启动的时候，会把当前自己服务器的信息 比如 服务地址通讯地址等以别名方式注册到注册中心上。
    另一方（消费者|服务提供者），以该别名的方式去注册中心上获取到实际的服务通讯地址，然后再实现本地RPC调用RPC远程调用框架核心设计思想：在于注册中心，因为使用注册中心管理每个服务与服务之间的一个依赖关系(服务治理概念)。
    在任何rpc远程框架中，都会有一个注册中心(存放服务地址相关信息(接口地址))
Eureka Server提供服务注册服务：
    各个微服务节点通过配置启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观看到。
EurekaClient通过注册中心进行访问：
    是一个Java客户端，用于简化Eureka Server的交互，客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，
    将会向Eureka Server发送心跳(默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除（默认90秒）
创建eurekaServer注册中心（相当于物业）
    1 添加modul 2修改pom  3创建application.yml 4 编写启动类，启动类上添加@EnableEurekaServer注解，说明是eureka注册中心
    2 在微服务客户端需要添加配置（yml）  通过服务的名称惊醒注册spring.application.name="xxx"每个服务都会有自己的名称
问题：微服务RPC远程服务调用最核心的是什么：
    高可用，试想你的注册中心只有一个only one， 它出故障了那就呵呵(￣▽￣)"了，会导致整个为服务环境不可用，所以
    解决办法：搭建Eureka注册中心集群 ，实现负载均衡+故障容错
集群原理说明：
    服务注册：将服务信息注册到注册中心  服务发现：冲注册中心获取服务信心     
*****实质：注册中心存取服务  实质上时用map进行存储  key（服务器名称）value（调用地址）    
举例说明：
    1先启动eureka注册中心
    2启动服务提供者（支付服务）
    3支付服务会把自己的信心注册到eureka（比如服务地址一别名的方式进行注入）
    4消费者订单服务需要调用接口时，使用服务别名去注册中心获取实际的远程调用rpc地址
    5消费者获取地址后，底层实际用的时httpclient技术实现远程调用
    6消费者获取远程地址后会存储在jvm中，默认30秒个更新一次服务调用地址
如果eureka是集群，需要在每个微服务的yml配置多个eureka的注册地址，用“，”隔开
    defaultZone: http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka  # 集群版
同一个服务布置多个实例（微服务集群） 支付集群
    1：开两个服务  服务名称一样，端口号不同，在eurekaserver中可见
    2：订单服务远程调用支付服务时默认是轮询的方式
@EnableDiscoveryClient//发现服务，可以发现eureka中的服务信息（名称，url，端口等）
eureka自我保护机制：
    保护模式主要用于一组客户端和Eureka Server之间存在网络分区场景下的保护。一旦进入保护模式，
    Eureka Server将会尝试保护其服务注册表中的信息，不再删除服务注册表中的数据，也就是不会注销任何微服务。
    一句话每个时刻一个微服务不可以了，rureka不会立刻清理，一就会对该服务信息进行保存
    默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例（默认90秒）。
    但是当网络分区故障发生(延时、卡顿、拥挤)时，微服务与EurekaServer之间无法正常通信，以上行为可能变得非常危险了——因为微服务本身其实是健康的，
    此时本不应该注销这个微服务。Eureka通过“自我保护模式”来解决这个问题——当EurekaServer节点在短时间内丢失过多客户端时（可能发生了网络分区故障），
    那么这个节点就会进入自我保护模式
zookeeper：作为注册中心，秩序要在pom中添加依赖，修改application.yml即可，储存到zookeeper中的服务为临时节点
eureka zookeeper consule 特点：  C是强一致性  A可用性  p分区容错性
    eureka java开发 对外暴漏http接口（控制面板） springcloud以集成  AP
    consul Go语言开发  http dns  以集成  CP
    zookeeper java  客户端  以集成    CP
最多只能同时较好的满足两个。
     CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，
    因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：
    CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
    CP - 满足一致性，分区容忍必的系统，通常性能不是特别高。
    AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
AP架构（eureka）
当网络分区出现后，为了保证可用性，系统B可以返回旧值，保证系统的可用性。
结论：违背了一致性C的要求，只满足可用性和分区容错，即AP
CP架构（zookeeper和consul）
当网络分区出现后，为了保证一致性，就必须拒接请求，否则无法保证一致性
结论：违背了可用性A的要求，只满足一致性和分区容错，即CP
解释Ap(可用性)：
    1当没有网络分区时，系统a和系统b数据保持一致  x=1
    2将系统a的x数据改成  x=2
    3当出现网络分区后，系统a和系统b之间的数据同步失败，系统b  x数据还是x=1
    4当客户端请求系统b时为了保证可用性，此时系统b返回旧值 x=1
解释Cp(一致性)：
    1当没有网络分区时，系统a和系统b数据保持一致  x=1
    2将系统a的x数据改成  x=2
    3当出现网络分区后，系统a和系统b之间的数据同步失败，系统b  x数据还是x=1
    4当客户端请求系统b时为了保证一致性，此时系统b拒绝服务请求，返回错误代码或信息
Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端       负载均衡的工具。
   简单的说，Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法和服务调用。
   Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等。简单的说，就是在配置文件中列出Load Balancer（简称LB）
   后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接等）去连接这些机器。
   我们很容易使用Ribbon实现自定义的负载均衡算法。
LB负载均衡(Load Balance)是什么？
    简单的说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA（高可用）。
    常见的负载均衡有软件Nginx，LVS，硬件 F5等。
Ribbon本地负载均衡客户端 VS Nginx服务端负载均衡区别？
    Nginx是服务器负载均衡，客户端所有请求都会交给nginx，然后由nginx实现转发请求。即负载均衡是由服务端实现的。
    Ribbon本地负载均衡，在调用微服务接口时候，会在注册中心上获取注册信息服务列表之后缓存到JVM本地，
     从而在本地实现RPC远程服务调用技术。
rabbin解释：rabbin就是负载均衡+rstTemplete（远程调用）
    服务的消费者（微服务）注册到eurekaserver注册中心，同时查询可用的服务列表（微服务）缓存到jvm中，
    当这个微服务调用其他微服务时使用策论进行调用，Ribbon在工作时分成两步，第一步先选择 EurekaServer ,它优先选择在同一个区域内负载较少的server.
    第二步再根据用户指定的策略，在从server取到的服务注册列表中选择一个地址。
        其中Ribbon提供了多种策略：比如轮询、随机和根据响应时间加权
面试问题rabbin默认的负载均衡规则，还有什么股则，怎么替换
    答：默认为轮询的负载均衡规则，在IRule接口中可以查看共7中，轮询，随机，权重等
    替换 换成随机轮询规则：不能建在启动类能扫描到的包下，在启动类上添加@RibbonClient，
                            创建随机轮询格则的配置类，类上添加@configration注解
    @Bean
    public IRule myRule()
    {
        return new RandomRule();//定义为随机
    }
负载均衡算法：rest接口第几次请求数 % 服务器集群总数量 = 实际调用服务器位置下标  ，
              每次服务重启动后rest接口计数从1开始。    
              List instances = discoveryClient.getInstances("CLOUD-PAYMENT-SERVICE");
              如：   List [0] instances = 127.0.0.1:8002
　　　                 List [1] instances = 127.0.0.1:8001
        8001+ 8002 组合成为集群，它们共计2台机器，集群总数为2， 按照轮询算法原理
当总请求数为1时： 1 % 2 =1 对应下标位置为1 ，则获得服务地址为127.0.0.1:8001
当总请求数位2时： 2 % 2 =0 对应下标位置为0 ，则获得服务地址为127.0.0.1:8002
当总请求数位3时： 3 % 2 =1 对应下标位置为1 ，则获得服务地址为127.0.0.1:8001
当总请求数位4时： 4 % 2 =0 对应下标位置为0 ，则获得服务地址为127.0.0.1:8002
如此类推......
openfeign是什么？
    是一个生命式的web服务客户端，只需创建一个接口并在接口上添加注解即可@FeignClient，启动类上添加@EnableFeignClients
feign远程调用时间默认为1秒
  默认Feign客户端只等待一秒钟，但是服务端处理需要超过1秒钟，导致Feign客户端不想等待了，直接返回报错。
为了避免这样的情况，有时候我们需要设置Feign客户端的超时控制    ，在yml中设置超时时间ribbon:ReadTimeout: 5000（5秒）
Hystrix：
分布式系统面临的问题
    复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免地失败。
服务雪崩：
    多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。
    如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”.
    对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，
    备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。
    所以，通常当你发现一个模块下的某个实例失败后，这时候这个模块依然还会接收流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，
    或者叫雪崩
Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，
避免级联故障，以提高分布式系统的弹性。
“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，
从而避免了故障在分布式系统中的蔓延，乃至雪崩
hystrix(断路器)能干什么？
    服务降级（fallback），服务熔断，接近实视监控，服务限流
    服务降级：调用服务不可用时，你需要给我一个兜底的解决方法，比如友好的提示，像调用方返回一个符合预期的可处理的备选相应fallback
        产生原因：程序运行异常，超时，服务熔断产生服务降级，线程池/信号量打满也会产生服务降级
    服务熔断：类比保险丝达到最大服务访问后，直接拒绝访问，拉闸限电，然后调用服务降级方法并返回友好提示
    服务限流：秒杀等高并发操作，严谨一窝蜂的过来拥挤，大家排队，一秒钟n个，有序进行
    yml配置hystrix，业务类上添加@HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler",commandProperties = {
            @HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value="3000")
    })
    重写paymentInfo_TimeOutHandler方法，标识如果遇到超时，服务器故障，宕机等情况不至于客户端等待或者错误页面，给一个友好提示
    yml添加配置feign.hystrix.enabled: true(层级)标识开启服务降级
  问题如果每个方法都添加服务降级方法会出现臃肿，所以在一些不需要特殊处理的方法上使用一个全局降级方法，在controller上添加注解@DefaultProperties(defaultFallback = "payment_Global_FallbackMethod")
熔断机制概述：
    熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务出错不可用或者响应时间太长时，
    会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。
    当检测到该节点微服务调用响应正常后，恢复调用链路。
    在Spring Cloud框架里，熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，
    当失败的调用到一定阈值，缺省是5秒内20次调用失败，就会启动熔断机制。熔断机制的注解是@HystrixCommand。
    @HystrixCommand(fallbackMethod = "paymentCircuitBreaker_fallback",commandProperties = {
        @HystrixProperty(name = "circuitBreaker.enabled",value = "true"),
        @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",value = "10"), 
        @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",value = "10000"),
        @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",value = "60"),
    })
熔断类型分为三种：
    当打到上边注解里的条件时，熔断打开，请求不在进行调用微服务，内部设置时钟一般为MTTR（平均故障处理时间），当熔断时长打到锁舌时钟则进入版熔断状态
    熔断关闭：熔断关闭不会对服务进行熔断
    熔断半开：部分请求根据规则调用当前服务，如果请求成功并且符合认定当前规则，则认为当前服务恢复正常，官兵熔断
    服务熔断会触发服务降级，类似于先拉闸，然后再调用服务降级方法callback返回友好提示（备用方法），然后恢复链路（自我恢复）
hystrix试试监控（有监控界面）：创建监控服务，在启动雷伤添加@EnableHystrixDashboard//图形化展示注解，在其他要被监控的服务琼雷伤也需要添加这个注解，并添加pom依赖，通过http可以监控视图
gateway网关：
    Cloud全家桶中有个很重要的组件就是网关，在1.x版本中都是采用的Zuul网关；
    但在2.x版本中，zuul的升级一直跳票，SpringCloud最后自己研发了一个网关替代Zuul，
    那就是SpringCloud Gateway一句话：gateway是原zuul1.x版的替代
    Gateway是在Spring生态系统之上构建的API网关服务，基于Spring 5，Spring Boot 2和 Project Reactor等技术。
Gateway旨在提供一种简单而有效的方式来对API进行路由，以及提供一些强大的过滤器功能， 例如：熔断、限流、重试等
   SpringCloud Gateway 是 Spring Cloud 的一个全新项目，基于 Spring 5.0+Spring Boot 2.0 和 Project Reactor 等技术开发的网关，
   它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式
   Spring Cloud Gateway的目标提供统一的路由方式且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/指标，和限流
   gatewa能干什么？
            反向代理，鉴权，流量监控，熔断，限流
 微服务中用在了哪里？
    外部请求（手持终端，html5，open接口）打到nginx（负载均衡服务器），请求转发到微服务网关（集群部署），通过微服务网关把请求分发到指定的微服务上
为什么选择gatewat于zuul相比有什么优势？
    1zuul进入维护阶段，zuul2还没有鉴权，gateway是spring研发，Gateway是基于异步非阻塞模型上进行开发的，性能方面不需要担心。虽然Netflix早就发布了最新的 Zuul 2.x，
    但 Spring Cloud 貌似没有整合计划。而且Netflix相关组件都宣布进入维护期；不知前景如何？多方面综合考虑Gateway是很理想的网关选择。
Spring Cloud Gateway 具有如下特性：
    基于Spring Framework 5, Project Reactor 和 Spring Boot 2.0 进行构建；
    动态路由：能够匹配任何请求属性；
    可以对路由指定 Predicate（断言）和 Filter（过滤器）；
    集成Hystrix的断路器功能；
    集成 Spring Cloud 服务发现功能；
    易于编写的 Predicate（断言）和 Filter（过滤器）；
    请求限流功能；
    支持路径重写。
Spring Cloud Gateway 与 Zuul的区别？
1    、Zuul 1.x，是一个基于阻塞 I/ O 的 API Gateway（相当于tomcat容器，没进来一个请求需要使用一个线程，性能不高）
2、Zuul 1.x 基于Servlet 2. 5使用阻塞架构它不支持任何长连接(如 WebSocket) Zuul 的设计模式和Nginx较像，每次 I/ O 操作都是从工作线程中选择一个执行，
    请求线程被阻塞到工作线程完成，但是差别是Nginx 用C++ 实现，Zuul 用 Java 实现，而 JVM 本身会有第一次加载较慢的情况，使得Zuul 的性能相对较差。
3、Zuul 2.x理念更先进，想基于Netty非阻塞和支持长连接，但SpringCloud目前还没有整合。 Zuul 2.x的性能较 Zuul 1.x 有较大提升。在性能方面，根据官方提供的基准测试，
   Spring Cloud Gateway 的 RPS（每秒请求数）是Zuul 的 1. 6 倍。但是出来的比springcloud gateway慢，所以用的不多
4、Spring Cloud Gateway 建立 在 Spring Framework 5、 Project Reactor 和 Spring Boot 2 之上， 使用非阻塞 API。
5、Spring Cloud Gateway 还 支持 WebSocket， 并且与Spring紧密集成拥有更好的开发体验

springcloud gateway三大核心：
    route（路由）：路由是构建网关的基本模块，他有id，目标url一系列的断言和过路器组成，如果断言为true则匹配改路由
    predicate(断言)：参考java8特性，开发人员可以匹配http请求所有内容（列如请求头货请求参数），如果请求和断言匹配则进行路由
    filter（过滤）：指的是spring框架中GatewatFilter的实例，使用过路器，可以在请求北路由前或者后队请求进行修改
 总体：web请求，通过一些匹配条件，定位到真正的服务节点。并在这个转发过程的前后，进行一些精细
       predicate就是我们的匹配条件；
       而filter，就可以理解为一个无所不能的拦截器。有了这两个元素，再加上目标uri，就可以实现一个具体的路由了
srpingcloud gateway工作流程：
    客户端向 Spring Cloud Gateway 发出请求。然后在 Gateway Handler Mapping 中找到与请求相匹配的路由，将其发送到 Gateway Web Handler。
     Handler 再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。
    过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前（“pre”）或之后（“post”）执行业务逻辑。
    Filter在“pre”类型的过滤器可以做参数校验、权限校验、流量监控、日志输出、协议转换等，
    在“post”类型的过滤器中可以做响应内容、响应头的修改，日志的输出，流量监控等有着非常重要的作用。
什么是SpringCloudStream?
    官方定义 Spring Cloud Stream 是一个构建消息驱动微服务的框架。相当于一个适配器，秩序调用里边的方法，就可以发送消息，集成了rabbitmq和kafka
    应用程序通过 inputs 或者 outputs 来与 Spring Cloud Stream中binder对象交互。
    通过我们配置来binding(绑定) ，而 Spring Cloud Stream 的 binder对象负责与消息中间件交互。
    所以，我们只需要搞清楚如何与 Spring Cloud Stream 交互就可以方便使用消息驱动的方式。
    通过使用Spring Integration来连接消息代理中间件以实现消息事件驱动。
    Spring Cloud Stream 为一些供应商的消息中间件产品提供了个性化的自动化配置实现，引用了发布-订阅、消费组、分区的三个核心概念。
 自我理解，目前有三种数据库，oralce，mysql，sqlserver，但是不要要掌握三种数据库的语法，只需要使用habernater就可以草做三种数据库
为什么用SpringCloudStream？
    比方说我们用到了RabbitMQ和Kafka，由于这两个消息中间件的架构上的不同，
    像RabbitMQ有exchange，kafka有Topic和Partitions分区，这些中间件的差异性导致我们实际项目开发给我们造成了一定的困扰，我们如果用了两个消息队列的其中一种，
    后面的业务需求，我想往另外一种消息队列进行迁移，这时候无疑就是一个灾难性的，一大堆东西都要重新推倒重新做，因为它跟我们的系统耦合了，
    这时候springcloud Stream给我们提供了一种解耦合的方式。
重复消费问题：
    比如在如下场景中，订单系统我们做集群部署，都会从RabbitMQ中获取订单信息，
    那如果一个订单同时被两个服务获取到，那么就会造成数据错误，我们得避免这种情况。
    这时我们就可以使用Stream中的消息分组来解决，注意在Stream中处于同一个group中的多个消费者是竞争关系，就能够保证消息只会被其中一个应用消费一次。
    不同组是可以全面消费的(重复消费)，同一组内会发生竞争关系，只有其中一个可以消费.
@EnableBinding(Source.class) // 可以理解为是一个消息的发送管道的定义,写在发送类上， @Resource   private MessageChannel output; // 消息的发送管道  使用output.send（）方法
@Component//不属于controller  service时就需要这个注解  @EnableBinding(Sink.class) 写在接受消息的类上，在方法上添加@StreamListener(Sink.INPUT)注解，标识接受消息

springcloud sleuth(链路跟踪)：
     在微服务框架中，一个由客户端发起的请求在后端系统中会经过多个不同的的服务节点调用来协同产生最后的请求结果，每一个前段请求都会形成一条复杂的分布式服务调用链路，
     链路中的任何一环出现高延时或错误都会引起整个请求最后的失败。
     spingcloud从F版本就不需要自己构建Zipkin Server了，只需要调用jar包即可，可以通过zeipkin的端口访问页面，最终到微服务的调用过程，在yml中添加配置

springcloudalibaba：是springcloud第二个版本，之前是springcloud H版 ，应为很多都停更（netfix）
    服务限流降级：默认支持 Servlet、Feign、RestTemplate、Dubbo 和 RocketMQ 限流降级功能的接入，可以在运行时通过控制台实时修改限流降级规则，还支持查看限流降级 Metrics 监控。
    服务注册与发现：适配 Spring Cloud 服务注册与发现标准，默认集成了 Ribbon 的支持。
    分布式配置管理：支持分布式系统中的外部化配置，配置更改时自动刷新。
    消息驱动能力：基于 Spring Cloud Stream 为微服务应用构建消息驱动能力。
    阿里云对象存储：阿里云提供的海量、安全、低成本、高可靠的云存储服务。支持在任何应用、任何时间、任何地点存储和访问任意类型的数据。
    分布式任务调度：提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。同时提供分布式的任务执行模型，如网格任务。网格任务支持海量子任务均匀分配到所有 Worker（schedulerx-client）上执行。
Nacos是什么？
    一个更易于构建云原生应用的动态服务发现，配置管理和服务管理的平台
    nacos就是注册中心+配置中心的组合 等价于 Nacos=Eureka+Config+Bus
    替代eureka做注册中心，替代config做服务配置中心，同时支持ap和cp可以切换
nacos自带负载均衡，请求可以通过负载均衡规则自动转发给微服务，因为nacos集成了rabbin
nacos作为配置中心，需要创建配置中心微服务，把服务注册到nacos中，这里秩序引入jar饱即可，按照规则创建配置列表的名称
        spring-cloud-starter-alibaba-nacos-config //依赖
    配置中心需要两个配置文件，application.yml和bootstrap.yml
    Nacos同springcloud-config一样，在项目初始化时，要保证先从配置中心进行配置拉取，拉取配置之后，才能保证项目的正常启动。
    springboot中配置文件的加载是存在优先级顺序的，bootstrap优先级高于application
nacos配置分组：
    类似Java里面的package名和类名，最外层的namespace是可以用于区分部署环境的，Group和DataID逻辑上区分两个目标对象。
    Nacos默认的命名空间是public，Namespace主要用来实现隔离。
    比方说我们现在有三个环境：开发、测试、生产环境，我们就可以创建三个Namespace，不同的Namespace之间是隔离的。    
nacos支持三种部署： 单机，集群，多集群模式
    默认Nacos使用嵌入式数据库实现数据的存储。所以，如果启动多个默认配置下的Nacos节点，数据存储是存在一致性问题的。
    为了解决这个问题，Nacos采用了集中式存储的方式来支持集群化部署，目前只支持MySQL的存储。
Sentinel:分布式服务的流量方卫兵，相当于hystrix（相似度98%）
    区别hystrix：1 需要我们自己手动搭建监控平台
     2 没有一套web界面给我们进行更加细粒度的配置，流控，速率，服务熔断，服务降级等
     sentinel：1 单独的一个组件，可以独立出来
            2 直接界面化的细粒度统一配置
    在sentinel监控界面（8080端口）：可以设置流控规则
    流控模式：1 直接（默认）--》快速失败  系统默认   | qps和线程数可以手动设置，按照自己的需求来
              2 关联：当关联的自乱打到阈值时，就先留自己，当于a关联的资源b打到阈值后，就限流a自己，b惹事a挂了，举例：支父接口打到阈值，则限流订单接口
              3 链路
    流控效果：1 直接快速失败
              2 预热  就是给你一个缓冲的场景，公式：阈值初一默认值（3），经过多长时间才会打到阈值，应用场景 秒杀活动，大量请求不至于使系统泵鬼
              3 排队等待 就是匀速排队，让请求匀速通过，阈值类型必须设置成qps，否则无效，对应的是漏桶算法
Sentinel服务降级：
    1： RT（平均响应时间，秒级）
        平均响应时间   超出阈值  且   在时间窗口内通过的请求>=5，两个条件同时满足后触发降级，窗口期过后关闭断路器
            RT最大4900（更大的需要通过-Dcsp.sentinel.statistic.max.rt=XXXX才能生效）
    2：异常比列（秒级）
     QPS >= 5 且异常比例（秒级统计）超过阈值时，触发降级；时间窗口结束后，关闭降级，必须同时满足
    3：异常数（分钟级）
    异常数（分钟统计）超过阈值时，触发降级；时间窗口结束后，关闭降级，时间窗口一定要大于60秒
    Sentinel 熔断降级会在调用链路中某个资源出现不稳定状态时（例如调用超时或异常比例升高），对这个资源的调用进行限制，
        让请求快速失败，避免影响到其它的资源而导致级联错误
    当资源被降级后，在接下来的降级时间窗口之内，对该资源的调用都自动熔断（默认行为是抛出 DegradeException）。
    **** sentinel的断路器没有半开状态，hystrix有
sentinel系统规则限流：是针对整个系统而言，不是针对每个方法或每个服务，相当于系统的入口
    系统规则支持以下模式：
    1 load自适应 2 cpu 3 平均rt 4 并发线程数 5入口qps
    Sentinel服务降级，使用 @SentinelResource注解添加到方法上，如果达到限流规则，则进入到兜底方法给客户端响应
sentinel和hystrix一样，不可能每个方法都写兜底的降级按方法，所以这里，我们用一个类标识服务降级类，在服务将及时
    通过注解@SentinelResourcel里面设置属性来实现，blockhandleClass=服务降级类.class,blockhandler="服务降级类中的方法"
    在使用@SentinelResourcel注解是，其中属性 fallback管的事java运行时异常，并给出兜底方法
        blockhandle管的事sentinel控制台配置违规，这是两种不同的概念    
sentinel规则持久化： 把sentinel配置信心注入到nacos中，这样在重启服务是，之前配置的规则信息就不会消失