微服务存在的问题

问题：微服务将原本的单体应用拆分成不同功能模块的小型服务，这些服务与服务之间产生了相互的依赖，可能会因为某种因素如系统负载过高，流量突发等异常情况，从而导致服务不可调用问题，最终产生“雪崩”，造成了连锁反应。
编程思想：针对以上可能发生的问题，我们以面向失败编程思想为指导，防止被内部服务(上下游服务)所拖垮，不被外界所影响(第三方服务)。

熔断降级

最危险的不是某个服务宕机，而是某个服务响应缓慢，导致资源一直被占用堆积，进而导致其他服务资源占用堆积，最终产生了雪崩。这是我们服务间相互依赖问题而导致服务整体不可用的主要原因。
熔断：在某个服务出现响应异常缓慢时，可以让服务的调用方快速失败返回，及时的释放掉本次的请求资源从而达到熔断。sentinel服务治理时熔断机制是通过在服务的调用的时候，产生的错误或者超时次数超过设定的阈值，后续的请求暂时不会发起，直接失败。后面具体介绍熔断使用方式。
降级：服务降级是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。

Sentinel流控防卫介绍

依赖引入与控制台的搭建

Sentinel分为两部分：核心库和控制台，核心库不依赖任何框架/库，能够运行于 Java 8 及以上的版本的运行时环境；控制台主要负责管理推送规则、监控、集群限流分配管理、机器发现等。

微服务整合sentinel

1. 核心库的依赖，为需要流控的微服务引入：

   <dependency>
       <groupId>com.alibaba.cloud</groupId>
       <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
   </dependency>

2. 配置文件

   spring:
       cloud:
           sentinel:
           transport:
           dashboard: 127.0.0.1:8080
           port: 9999

   port：999 服务与控制台通讯的端口，会在应⽤用对应的机器器上启动一个Http Server，该 Server 会与 Sentinel 控制台做交互。
   服务注册上去后，由于Sentinel是懒加载模式，所以需要访问相关的资源后才会在控制台出现。

控制台

注意：Sentinel 控制台⽬目前仅⽀支持单机部署

主要功能如下：

• 查看机器器列列表以及健康情况：收集 Sentinel 客户端发送的⼼心跳包，⽤用于判断机器器是否在线。
• 监控 (单机和集群聚合)通过 Sentinel 客户端暴暴露露的监控API，定期拉取并且聚合应⽤用监控信息，最终可以实现秒级的实时监控。
• 规则管理理和推送：统⼀管理理推送规则。

下载控制台jar 地址

1. 启动

   java -Dserver.port=8080 -Dcsp.sentinel.dashboard.server=localhost:8080 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard.jar

2. 访问
   http://127.0.0.1:8080 默认的账户名与密码 sentinel

登录后请求任意接口，在控制台会看到我们对应的服务名称以及请求的资源路径。
资源名：就是被保护的资源，比如 /api/order/findById这个资源。通过对相应资源的配置操作（流控、降级、热点规则、授权）完成对资源的配置保护。

sentinel的多种流控规则

流控规则

说明：监控应用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。

两种规则

• 基于统计并发线程数的流量量控制。
  通过统计当前请求上下文的线程数目，如果超过阈值，新的请求会被立即拒绝，从而保护业务线程池不不被慢调用耗尽。
• 基于统计QPS的流量量控制
  当 QPS 超过某个阈值的时候，则采取措施进⾏行行流量量控制

  控制面板介绍

• 资源名：默认是请求资源的路径，可⾃自定义
• 针对来源：对哪个微服务进行限流，默认是不区分来源，全部限流，这个是针对区分上游服务进行限流, 比如 A 被 B服务、C服务调用，就可以针对来源进行限流。

• 单机阈值：每秒大于N个请求就会被流控。

  

基于QPS的流控

点击对应资源的流控

连续刷新页面，保证每秒大于我们设置的请求数，就会触发流控保护。