springcloud全局概述

来源：尚硅谷(周阳老师) https://www.bilibili.com/video/BV18E411x7eT

一.微服务的概述

1.什么是微服务
微服务(Microservice Architecture) 是近几年流行的一种架构思想，关于它的概念很难一言以蔽之。究竟什么是微服务呢？我们在此引用ThoughtWorks 公司的首席科学家 Martin Fowler 于2014年提出的一段话：

原文：https://martinfowler.com/articles/microservices.html
汉化：https://www.cnblogs.com/liuning8023/p/4493156.html

就目前而言，对于微服务，业界并没有一个统一的，标准的定义。但通常而言，微服务架构是一种架构模式，或者说是一种架构风格，它体长将单一的应用程序划分成一组小的服务，每个服务运行在其独立的自己的进程内，服务之间互相协调，互相配置，为用户提供最终价值，服务之间采用轻量级的通信机制(HTTP)互相沟通，每个服务都围绕着具体的业务进行构建，并且能狗被独立的部署到生产环境中，另外，应尽量避免统一的，集中式的服务管理机制，对具体的一个服务而言，应该根据业务上下文，选择合适的语言，工具(Maven)对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。

再来从技术维度角度理解下：
微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事情，从技术角度看就是一种小而独立的处理过程，类似进程的概念，能够自行单独启动或销毁，拥有自己独立的数据库。

2.微服务与微服务架构
微服务：强调的是服务的大小，它关注的是某一个点，是具体解决某一个问题/提供落地对应服务的一个服务应用，狭义的看，可以看作是IDEA中的一个个微服务工程，或者Moudel。

IDEA 工具里面使用Maven开发的一个个独立的小Moudel，它具体是使用SpringBoot开发的一个小模块，专业的事情交给专业的模块来做，
一个模块就做着一件事情。强调的是一个个的个体，每个个体完成一个具体的任务或者功能。

微服务架构：一种新的架构形式，Martin Fowler 于2014年提出。
微服务架构是一种架构模式，它体长将单一应用程序划分成一组小的服务，服务之间相互协调，互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务之间采用轻量级的通信机制(如HTTP)互相协作，每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境中，另外，应尽量避免统一的，集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具(如Maven)对其进行构建。

3.微服务优缺点
优点：

- 单一职责原则；
- 每个服务足够内聚，足够小，代码容易理解，这样能聚焦一个指定的业务功能或业务需求；
- `开发简单，开发效率高，一个服务可能就是专一的只干一件事`；
- 微服务能够被小团队单独开发，这个团队只需2-5个开发人员组成；
- 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的；
- 微服务能使用不同的语言开发；
- 易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如jenkins，Hudson，bamboo；
- 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果，无需通过合作才能体现价值；
- 微服务允许利用和融合最新技术；
- 微服务只是业务逻辑的代码，不会和HTML，CSS，或其他的界面混合;
- 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库；

缺点：

- 开发人员要处理分布式系统的复杂性；
- 多服务运维难度，随着服务的增加，运维的压力也在增大；
- 系统部署依赖问题；
- 服务间通信成本问题；
- 数据一致性问题；
- 系统集成测试问题；
- 性能和监控问题；

二.springcloud概述及版本说明

概述：

1.SpringCloud是什么

Spring Cloud为开发人员提供了快速构建分布式系统中的一些常见模式的工具(例如配置管理、服务发现、断路器、智能
路由、微代理、控制总线、一次性令牌、全局锁、领导人选举、分布式会话、集群状态)。分布式系统的协调导致了锅炉
板模式，而使用Spring Cloud开发人员可以快速建立实现这些模式的服务和应用程序。它们在任何分布式环境中都能很
好地工作，包括开发人员自己的笔记本电脑、裸金属数据中心和云计算等托管平台。

架构图：

2.SpringCloud和SpringBoot的关系

1.SpringBoot专注于开苏方便的开发单个个体微服务；
2.SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务，整合并管理起来，为各个微服务之间提供：
配置管理、服务发现、断路器、路由、为代理、事件总栈、全局锁、决策竞选、分布式会话等等集成服务；
3.SpringBoot可以离开SpringCloud独立使用，开发项目，但SpringCloud离不开SpringBoot，属于依赖关系；
4.SpringBoot专注于快速、方便的开发单个个体微服务，SpringCloud关注全局的服务治理框架；

3.Dubbo 和 SpringCloud对比

对比图：

最大区别：Spring Cloud 抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式严格来说，这两种方式各有优劣。虽然从一定程度上来说，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这个优点在当下强调快速演化的微服务环境下，显得更加合适。
总结：二者解决的问题域不一样：Dubbo的定位是一款RPC框架，而SpringCloud的目标是微服务架构下的一站式解决方案，并且springcloud提供了一套完整的组件，相当于一个整机，而dubbo相当于散件，所以大型项目一般用springcloud。

版本适配以及2020更新后各组件情况：
1.2020更新后各组件情况
之前：

更新后：

总结：更新后会发现很多组件都不再维护了，Nacos取代了Eureka，Config，Bus组件，Nacos可以作为注册中心也可以作为配置中心，Feign服务间的远程调用被OpenFeign取代，Hystrix熔断降级限流被sentinel取代，Zuul网关被gateway网关取代，Ribbon目前还可以使用，以前的架构一般是：Eureka +Ribbon/Feign+Hystrix+Zuul+config+Bus+Stream；现在的架构：Nacos+OpenFeign/Ribbon+sentinel+gateway。

2.版本适配
springboot与springcloud:进入springcloud的Reference Doc直接能看到适配版本

1.首页就能看到目前两者版本的大概匹配：

2.更详细的查看方法(转换成json格式)：https://start.spring.io/actuator/info

springcloud与springcloud alibaba：https://github.com/alibaba/spring-cloud-alibaba/blob/master/README-zh.md

本次工程选用的版本：以后可以自己更换

三.微服务架构编码构建

IDEA新建project工作空间构建

1.微服务cloud整体聚合父工程Project：

1.New Project：构建一个maven项目，不用选骨架看，父工程只要有一个pom文件就ok
2.聚合总工程名字：springcloud
3.Maven选版本：maven选择我们本地配了镜像的
4.字符编码：全部选择UTF-8

5.注解生效激活：

6.java编译版本选8：

7.File Type过滤：*.hprof;*.idea;*.iml;*.pyc;*.pyo;*.rbc;*.yarb;*~;.DS_Store;.git;.hg;.svn;CVS;__pycache__;_svn;vssver.scc;vssver2.scc;

2.父工程POM：

<!-- 统一管理jar包版本 -->
  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
    <junit.version>4.12</junit.version>
    <log4j.version>1.2.17</log4j.version>
    <lombok.version>1.16.18</lombok.version>
    <mysql.version>5.1.47</mysql.version>
    <druid.version>1.1.16</druid.version>
    <druid.spring.boot.starter.version>1.1.10</druid.spring.boot.starter.version>
    <spring.boot.version>2.2.2.RELEASE</spring.boot.version>
    <spring.cloud.version>Hoxton.SR1</spring.cloud.version>
    <spring.cloud.alibaba.version>2.1.0.RELEASE</spring.cloud.alibaba.version>
    <mybatis.spring.boot.version>1.3.0</mybatis.spring.boot.version>
    <mybatis-spring-boot-starter.version>2.1.1</mybatis-spring-boot-starter.version>
    <hutool-all.version>5.1.0</hutool-all.version>
  </properties>

  <!-- 子模块继承之后，提供作用：锁定版本 + 子module不用谢groupId和version -->
  <dependencyManagement>
    <dependencies>
      <!--spring boot 2.2.2-->
      <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-dependencies</artifactId>
        <version>2.2.2.RELEASE</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <!--spring cloud Hoxton.SR1-->
      <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-dependencies</artifactId>
        <version>Hoxton.SR1</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <!--Spring cloud alibaba 2.1.0.RELEASE-->
      <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-alibaba-dependencies</artifactId>
        <version>2.1.0.RELEASE</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <version>${mysql.version}</version>
      </dependency>
      <dependency>
        <groupId>com.alibaba</groupId>
        <artifactId>druid</artifactId>
        <version>${druid.version}</version>
      </dependency>
      <dependency>
        <groupId>com.alibaba</groupId>
        <artifactId>druid-spring-boot-starter</artifactId>
        <version>${druid.spring.boot.starter.version}</version>
      </dependency>
      <dependency>
        <groupId>org.mybatis.spring.boot</groupId>
        <artifactId>mybatis-spring-boot-starter</artifactId>
        <version>${mybatis-spring-boot-starter.version}</version>
      </dependency>
      <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>${lombok.version}</version>
      </dependency>
    </dependencies>
  </dependencyManagement>

3.父工程创建完成执行mvn:install将父工程发布到仓库方便子工程继承

Rest微服务工程构建：构建工程主要有建module，修改pom文件，写xml，主启动，业务类这几步。

以下的内容通过脑图操作，下面只给出原理与概念：

四.Eureka服务注册与发现

1.什么是服务治理

2.什么是服务注册

3.Eureka两组件

4.三个注册中心的区别
CAP：C:Consistency(强一致性) A:Availability(可用性) P:Partition tolerance(分区容错)
Zookeeper和Consul作为注册中心主要保证的是CP(数据强一致性及分区容错性)
Eureka作为注册中心主要保证的是AP(高可用性和分区容错性)

五.Zookeeper服务注册与发现概述

六.Consul服务注册与发现概述

七.Ribbon负载均衡服务调用概述

1.是什么 https://github.com/Netflix/ribbon/wiki/Getting-Started

2.能干什么
LB（负载均衡）：

1.集中式LB：

2.进程内LB：
3.Ribbon的负载均衡：
RoundRobinRule轮询（默认）：第一次到A，第二次就到B，第三次又到A，第四次又到B…
具体实现是一个负载均衡算法：第N次请求 % 服务器集群的总数 = 实际调用服务器位置的下标那么怎么保证线程安全问题呢？因为N次请求次数会自增，怎么保证不会多次请求都拿到同一个N进行自增？答案就是简单的CAS：

public class RoundRobinRule extends AbstractLoadBalancerRule {
    private AtomicInteger nextServerCyclicCounter;
    private static final boolean AVAILABLE_ONLY_SERVERS = true;
    private static final boolean ALL_SERVERS = false;

    private static Logger log = LoggerFactory.getLogger(RoundRobinRule.class);
    public RoundRobinRule() {
        nextServerCyclicCounter = new AtomicInteger(0);
    }
    public RoundRobinRule(ILoadBalancer lb) {
        this();
        setLoadBalancer(lb);
    }

    public Server choose(ILoadBalancer lb, Object key) {
        if (lb == null) {
            log.warn("no load balancer");
            return null;
        }

        Server server = null;
        int count = 0;
        while (server == null && count++ < 10) {
            List<Server> reachableServers = lb.getReachableServers();
            List<Server> allServers = lb.getAllServers();
            int upCount = reachableServers.size();
            int serverCount = allServers.size();

            if ((upCount == 0) || (serverCount == 0)) {
                log.warn("No up servers available from load balancer: " + lb);
                return null;
            }

            int nextServerIndex = incrementAndGetModulo(serverCount);
            server = allServers.get(nextServerIndex);

            if (server == null) {
                /* Transient. */
                Thread.yield();
                continue;
            }

            if (server.isAlive() && (server.isReadyToServe())) {
                return (server);
            }

            // Next.
            server = null;
        }

        if (count >= 10) {
            log.warn("No available alive servers after 10 tries from load balancer: "
                    + lb);
        }
        return server;
    }

    /**
     * Inspired by the implementation of {@link AtomicInteger#incrementAndGet()}.
     *
     * @param modulo The modulo to bound the value of the counter.
     * @return The next value.
     */
    private int incrementAndGetModulo(int modulo) {
        for (;;) {
            int current = nextServerCyclicCounter.get();
            int next = (current + 1) % modulo;
            if (nextServerCyclicCounter.compareAndSet(current, next))
                return next;
        }
    }

    @Override
    public Server choose(Object key) {
        return choose(getLoadBalancer(), key);
    }

    @Override
    public void initWithNiwsConfig(IClientConfig clientConfig) {
    }
}

RandomRule随机：
RetryRule轮询重试（重试采用的默认也是轮询）
WeightedResponseTimeRule响应速度决定权重：
BestAvailableRule最优可用（底层也有RoundRobinRule）：
AvailabilityFilteringRule可用性过滤规则（底层也有RoundRobinRule）：
ZoneAvoidanceRule区域内可用性能最优：

总结：负载均衡+RestTemplate调用

八.OpenFeign服务接口调用概述

官网：https://github.com/spring-cloud/spring-cloud-openfeign

OpenFeign是什么：Feign是一个声明式的web服务客户端，让编写web服务客户端变得非常容易，只需创建一个接口并在接口上添加注解即可。

能干嘛：

Feign和OpenFeign两者区别：

九.Hystrix断路器概述

概述：
官网：https://github.com/Netflix/Hystrix/wiki/How-To-Use

分布式系统面临的问题：复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候会不可避免的失败。

上图中需要调用APHI四个服务，一切顺利调用没有问题，当I服务出现问题，而P服务依赖于I服务，这时候P服务也会超时阻塞，这时候资源越占越多，容易引起雪崩。

雪崩：

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

Hystrix是什么：

能干嘛：服务降级，服务熔断，接近实时的监控
Hystrix重要概念：
服务降级：服务器忙，请稍候再试，不让客户端等待并立刻返回一个友好提示，fallback
哪些情况会出发降级：程序运行异常，超时，服务熔断触发服务降级，线程池/信号量打满也会导致服务降级

服务熔断：类比保险丝达到最大服务访问后，直接拒绝访问，拉闸限电，然后调用服务降级的方法并返回友好提示，服务的降级->进而熔断->恢复调用链路
哪些情况会出发熔断：

服务限流：秒杀高并发等操作，严禁一窝蜂的过来拥挤，大家排队，一秒钟N个，有序进行

Hystrix工作流程：

十.zuul路由网关概述

十一.Gateway新一代网关概述：https://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.2.1.RELEASE/reference/html/

Gateway是什么？：

Gateway能干什么？：反向代理，鉴权，流量控制，熔断，日志监控

Gateway三大核心概念：

Route(路由)：路由是构建网关的基本模块，它由ID，目标URI，一系列的断言和过滤器组成，如果断言为true则匹配该路由

Predicate（断言）：参考的是java8的java.util.function.Predicate开发人员可以匹配HTTP请求中的所有
内容（例如请求头或请求参数），如果请求与断言相匹配则进行路由

Filter(过滤)：指的是Spring框架中GatewayFilter的实例，使用过滤器，可以在请求被路由前或者之后对请求进行修改。

Route(路由)，Predicate（断言），Filter(过滤)具体使用：
Route(路由)：路由是由一系列的断言和过滤器组成。
Predicate（断言）：满足断言条件会进行跳转，有一个lb负载均衡，当一个注册中心下有多个相同服务名的服务，会进行负载均衡调用。
Filter(过滤)：

spring:
  application:
    name: cloud-gateway
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true # 开启从注册中心动态创建路由的功能，利用微服务名称进行路由,默认开启
      routes:
        - id: payment_routh1
          uri: lb://cloud-payment-service
          predicates:
            - Path=/payment/get/**   #断言,路径相匹配的进行路由
            - Cookie=username,zgw

        - id: payment_routh2
          uri: lb://cloud-payment-service
          predicates:
            - Path=/payment/lib/**   #断言,路径相匹配的进行路由

        - id: payment_routh4
          uri: http://localhost:8001
          predicates:
            - Path=/payment/lb/**   #断言,路径相匹配的进行路由

        - id: baidu-guoji
          uri: http://news.baidu.com
          predicates:
            - Path=/guoji/** #断言,路径相匹配的进行路由

Gateway工作流程总结：路由转发+执行过滤器链

十二.SpringCloud config分布式配置中心概述

分布式系统面临的配置问题：微服务架构就是把一个大型项目拆分成多个模块，每个模块都是一个独立的服务，会有独立的配置文件，所以我们会有很多配置文件，很难维护。
SpringCloud Config是什么：提供了微服务所有模块的配置中心，实现配置文件的统一管理。
组成图：

分析：SpringCloud Config主要有两个部分，分别是服务端和客户端，服务端也叫分布式配置中心，主要用来连接云上的配置，一般都是通过git连接github或者gitee，拿到上面的配置；客户端主要用来指定具体的配置中心，从中获取配置信息。

SpringCloud Config能做到什么：

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

Config客户端之动态刷新:我们会发现我们更改了github中的配置文件，刷新访问发现并没有更新过来，我们需要运维人员发送post请求来手动刷新：curl -X POST "http://localhost:3355/actuator/refresh"

广播动态刷新：这时候我们发现还有问题，当我们有多个客户端都使用了这个配置中心，发现需要一个一个的去刷新，非常麻烦，这时候就出现了广播，引出了SpringCloud Bus消息总线，详细看下一节的SpringCloud Bus 消息总线介绍。

十三.SpringCloud Bus 消息总线概述

前言：Spring Cloud Bus配合Spring Cloud Config使用可以实现配置的广播式动态刷新，Bus支持两种消息代理：RabbitMQ和Kafka；

实现原理：Config服务端客户端都监听MQ中的同一个Topic，只要已修改，其他监听这个Topic的都能接收到信息并且修改，两种方法实现刷新所有客户端的配置：

1) 利用消息总线触发一个客户端/bus/refresh,而刷新所有客户端的配置
2) 利用消息总线触发一个服务端ConfigServer的/bus/refresh端点,而刷新所有客户端的配置（更加推荐）

十四.SpringCloud Stream消息驱动概述

十五.SpringCloud Sleuth分布式请求链路追踪概述：https://github.com/spring-cloud/spring-cloud-sleuth

为什么会出现这个技术？能解决什么问题：在微服务架构中，一个有客户端发起的请求在后端系统中会经过多个不同的服务节点调用来协同产生醉胡的请求结果，每一个前端请求都会形成一条复杂的分布式服务调用链路，链路中的任何一环出现高延迟时或者错误都会引起整个请求最后的失败，所以我们需要Sleuth分布式请求链路追踪来分析在哪一个环节耗时情况来进行优化。

使用：主要是使用zipkin来分析，详细操作看脑图。

十六.SpringCloud Alibaba入门简介概述：https://github.com/alibaba/spring-cloud-alibaba/blob/master/README-zh.md

SpringCloud Alibaba带来了什么：

Alibaba生态：

Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
Nacos：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
RocketMQ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。
Dubbo：Apache Dubbo™ 是一款高性能 Java RPC 框架。
Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。
Alibaba Cloud ACM：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。
Alibaba Cloud OSS: 阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成
本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。

Alibaba Cloud SchedulerX: 阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时
（基于 Cron 表达式）任务调度服务。
Alibaba Cloud SMS: 覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。

十七.SpringCloud Alibaba Nacos服务注册和配置中心概述：添加链接描述

是什么,能干嘛：Nacos就是注册中心+配置中心的结合体，Nacos=Eureka + Bus + Config，替代Eureka做服务注册中心，替代Config做服务配置中心

与各大注册中心的对比：Nacos支持CP与AP的切换，当要求高可用性时使用AP，当要求强一致性时使用CP

十八.SpringCloud Alibaba Sentinel实现熔断与限流概述https://github.com/alibaba/Sentinel/wiki/%E4%BB%8B%E7%BB%8D

下载：https://github.com/alibaba/Sentinel/releases
是什么：Sentinel就是用来取代之前的Hystrix，也是用来做服务熔断降级限流这些。

详细解释Sentinel的几个功能：
流控规则：

重点讲解：
流控模式：有直接，关联，链路三个选项

直接：直接+快速失败，快速点击地址，超过阈值，会有fallback的兜底方法报错->Blocked by Sentinel (flow limiting)
关联：关联+快速失败，A，B两个资源，A关联B，快速点击B，超过阈值，A出错，A关联B，B惹事，A出问题
链路：多个请求调用同一个微服务

流控效果：有快速失败，预热，排队等待

快速失败：直接失败，抛出异常，源码：com.alibaba.csp.sentinel.slots.block.flow.controller.DefaultController
预热：阈值除以coldFactor（默认值为3），经过预热时长后才会达到阈值，默认coldFactor为3，即请求QPS从
threshold/3开始，经预热时长逐渐升至设定的QPS阈值，主要为了防止瞬间流量爆发导致冲垮服务器，给服务器一个缓冲。
排队等待：主要用来处理间隔性突发流量，就像消息队列，某一刻有大量的流量进来，我们不应该直接拒绝，而应该在
接下来的空闲时间慢慢处理这些流量

预热配置：

排队等待配置：

降级规则：

降级策略实战：有三个重要指标，分别是RT，异常比例，异常数
前提：每秒请求数QPS>=5
RT：RT平均响应时间，若这个响应时间内没有处理完，在时间窗口后会启动熔断器，直到能处理完才会关闭熔断器。

异常比例：

结论：当1秒内的请求量QPS>=5，并且超过我们的异常比例，熔断器开启，服务降级，不报我们定义的error了。

异常数：时间窗口必须大于60s且1min内异常数大于我们规定的值会发现熔断降级

热点key限流：https://github.com/alibaba/Sentinel/wiki/热点参数限流
注意：我们可以限流某个资源路径，包括可以指定下面的参数。

@GetMapping("/testHotKey")
@SentinelResource(value = "testHotKey",blockHandler = "deal_testHotKey")
public String testHotKey(@RequestParam(value = "p1",required = false) String p1,
@RequestParam(value = "p2",required = false) String p2) {
	//int age = 10/0;
	return "------testHotKey";
}
//兜底方法
public String deal_testHotKey (String p1, String p2, BlockException exception){
return "------deal_testHotKey,o(╥﹏╥)o";  
}

参数例外项：高级选项有一个参数例外项，我们期望p1参数当它是某个特殊值时，它的限流值和平时不一样，假如当p1的值等于5时，它的阈值可以达到200

总结：拿上面例子来说，当QPS超过每秒1次，马上降级处理，会调用我们自定义的方法，能返回友好的页面，@SentinelResource(value = “testHotKey”,blockHandler = “deal_testHotKey”)非常重要，通过这个配置来使用我们自己的兜底方法。

系统规则：https://github.com/alibaba/Sentinel/wiki/%E7%B3%BB%E7%BB%9F%E8%87%AA%E9%80%82%E5%BA%94%E9%99%90%E6%B5%81

系统保护规则是从应用级别的入口流量进行控制，从单台机器的 load、CPU 使用率、平均 RT、入口 QPS 和并发线程数
等几个维度监控应用指标，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。

系统保护规则是应用整体维度的，而不是资源维度的，并且仅对入口流量生效。入口流量指的是进入应用的流量
（EntryType.IN），比如 Web 服务或 Dubbo 服务端接收的请求，都属于入口流量。

系统规则支持以下的模式：
* Load 自适应（仅对 Linux/Unix-like 机器生效）：系统的 load1 作为启发指标，进行自适应系统保护。当系统 load1 超过
设定的启发值，且系统当前的并发线程数超过估算的系统容量时才会触发系统保护（BBR 阶段）。系统容量由系统的 
maxQps * minRt 估算得出。设定参考值一般是 CPU cores * 2.5。
* CPU usage（1.5.0+ 版本）：当系统 CPU 使用率超过阈值即触发系统保护（取值范围 0.0-1.0），比较灵敏。
* 平均 RT：当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护，单位是毫秒。
* 并发线程数：当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。
* 入口QPS：当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护。

@SentinelResource：需要具体操作一遍

服务熔断功能：
熔断框架对比：


规则持久化：一旦我们重启应用，Sentinel规则将消失，生产环境需要将配置规则进行持久化
怎么玩：将限流配置规则持久化进Nacos保存，只要刷新8401某个rest地址，sentinel控制台的流控规则就能看到，只要Nacos里面的配置不删除，针对8401上Sentinel上的流控规则持续有效，具体步骤看脑图。

十九.SpringCloud Alibaba Seata处理分布式事务概述