Spring Cloud Alibaba全家桶——Sentinel控制台规则配置

Posted 小新要变强

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Spring Cloud Alibaba全家桶——Sentinel控制台规则配置相关的知识，希望对你有一定的参考价值。

前言

本文小新为大家带来 Sentinel控制台规则配置 相关知识，具体内容包括流控规则（包括：QPS流控规则，并发线程数流控规则），BlockException统一异常处理，流控模式（包括：直接流控模式，关联流控模式，链路流控模式，预热流控效果），熔断降级规则（包括：熔断降级规则说明，熔断策略），热点参数限流，系统规则，授权控制规则，集群规则等进行详尽介绍~

不积跬步，无以至千里；不积小流，无以成江海。每天进步一点点，在成为强者的路上，小新与大家共同成长！

📌博主主页：小新要变强 的主页
👉Java全栈学习路线可参考：【Java全栈学习路线】最全的Java学习路线及知识清单，Java自学方向指引，内含最全Java全栈学习技术清单~
👉算法刷题路线可参考：算法刷题路线总结与相关资料分享，内含最详尽的算法刷题路线指南及相关资料分享~
👉Java微服务开源项目可参考：企业级Java微服务开源项目（开源框架，用于学习、毕设、公司项目、私活等，减少开发工作，让您只关注业务！）

↩️本文上接：Spring Cloud Alibaba全家桶（六）——微服务组件Sentinel介绍与使用

目录

Sentinel控制台规则配置

一、流控规则

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

同一个资源可以创建多条限流规则。FlowSlot 会对该资源的所有限流规则依次遍历，直到有规则触发限流或者所有规则遍历完毕。一条限流规则主要由下面几个因素组成，我们可以组合这些元素来实现不同的限流效果。

Field说明默认值
resource资源名，资源名是限流规则的作用对象
count限流阈值
grade限流阈值类型，QPS 模式（1）或并发线程数模式（0）QPS 模式
limitApp流控针对的调用来源default，代表不区分调用来源
strategy调用关系限流策略：直接、链路、关联根据资源本身（直接）
controlBehavior流控效果（直接拒绝/WarmUp/匀速+排队等待），不支持按调用关系限流直接拒绝
clusterMode是否集群限流否

参考文档：https://github.com/alibaba/Sentinel/wiki/流量控制

1️⃣QPS流控规则

QPS（Query Per Second）：每秒请求数，就是说服务器在一秒的时间内处理了多少个请求。

进入簇点链路选择具体的访问的API，然后点击流控按钮。

测试：

2️⃣并发线程数流控规则

并发数控制用于保护业务线程池不被慢调用耗尽。例如，当应用所依赖的下游应用由于某种原因导致服务不稳定、响应延迟增加，对于调用者来说，意味着吞吐量下降和更多的线程数占用，极端情况下甚至导致线程池耗尽。为应对太多线程占用的情况，业内有使用隔离的方案，比如通过不同业务逻辑使用不同线程池来隔离业务自身之间的资源争抢（线程池隔离）。这种隔离方案虽然隔离性比较好，但是代价就是线程数目太多，线程上下文切换的 overhead 比较大，特别是对低延时的调用有比较大的影响。

Sentinel 并发控制不负责创建和管理线程池，而是简单统计当前请求上下文的线程数目（正在执行的调用数目），如果超出阈值，新的请求会被立即拒绝，效果类似于信号量隔离。并发数控制通常在调用端进行配置。

可以利用jmeter测试：

二、BlockException统一异常处理

springwebmvc接口资源(BlockException异常统一处理)限流入口在HandlerInterceptor的实现类AbstractSentinelInterceptor的preHandle方法中，对异常的处理是BlockExceptionHandler的实现类，sentinel 1.7.1 引入了sentinel-spring-webmvc-adapter.jar 。

自定义BlockExceptionHandler 的实现类统一处理BlockException：

@Slf4j
@Component
public class MyBlockExceptionHandler implements BlockExceptionHandler 
  @Override
  public void handle(HttpServletRequest request, HttpServletResponse response,    BlockException e) throws Exception 
    log.info("BlockExceptionHandler BlockException================"+e.getRule());

    R r = null;

    if (e instanceof FlowException) 
      r = R.error(100,"接口限流了");
     else if (e instanceof DegradeException) 
      r = R.error(101,"服务降级了");
     else if (e instanceof ParamFlowException) 
      r = R.error(102,"热点参数限流了");
     else if (e instanceof SystemBlockException) 
      r = R.error(103,"触发系统保护规则了");
     else if (e instanceof AuthorityException) 
      r = R.error(104,"授权规则不通过");
    

    //返回json数据
    response.setStatus(500);
    response.setCharacterEncoding("utf‐8");
    response.setContentType(MediaType.APPLICATION_JSON_VALUE);
    new ObjectMapper().writeValue(response.getWriter(), r);

测试：

三、流控模式

基于调用关系的流量控制。调用关系包括调用方、被调用方；一个方法可能会调用其它方法，形成一个调用链路的层次关系。

1️⃣直接流控模式

资源(直接 )调用达到设置的阈值后直接被流控抛出异常。

2️⃣关联流控模式

当两(关联)个资源之间具有资源争抢或者依赖关系的时候，这两个资源便具有了关联。比如对数据库同一个字段的读操作和写操作存在争抢，读的速度过高会影响写得速度，写的速度过高会影响读的速度。如果放任读写操作争抢资源，则争抢本身带来的开销会降低整体的吞吐量。可使用关联限流来避免具有关联关系的资源之间过度的争抢，举例来说，read_db 和 write_db 这两个资源分别代表数据库读写，我们可以给 read_db 设置限流规则来达到写优先的目的：设置 strategy 为 RuleConstant.STRATEGY_RELATE 同时设置 refResource 为 write_db。这样当写库操作过于频繁时，读数据的请求会被限流。

3️⃣链路流控模式

根据(链路)调用链路入口限流。

下面中记录了资源之间的调用链路，这些资源通过调用关系，相互之间构成一棵调用树。这棵树的根节点是一个名字为 getUser 的虚拟节点，调用链的入口都是这个虚节点的子节点。

一棵典型的调用树如下图所示：

getUser
/ \\
/ \\
/order/test1 /order/test2

上图中来自入口 /order/test1 和 /order/test2的请求都调用到了资源 getUser，Sentinel 允许只根据某个入口的统计信息对资源限流。

测试会发现链路规则不生效。

注意，高版本此功能直接使用不生效，如何解决？

  • 从1.6.3 版本开始，Sentinel Web filter默认收敛所有URL的入口context，因此链路限流不生效。
  • 1.7.0 版本开始（对应SCA的2.1.1.RELEASE)，官方在CommonFilter 引入了WEB_CONTEXT_UNIFY 参数，用于控制是否收敛context。将其配置为 false 即可根据不同的URL 进行链路限流。
  • SCA 2.1.1.RELEASE之后的版本,可以通过配置spring.cloud.sentinel.web-context-unify=false即可关闭收敛。
spring.cloud.sentinel.web‐context‐unify: false

测试：

此场景拦截不到BlockException，对应@SentinelResource指定的资源必须在@SentinelResource注解中指定 blockHandler处理BlockException。

总结：

为了解决链路规则引入ComonFilter的方式，除了此处问题，还会导致更多的问题，不建议使用ComonFilter的方式。 流控链路模式的问题等待官方后续修复，或者使用AHAS。

4️⃣预热流控效果

（RuleConstant.CONTROL_BEHAVIOR_DEFAULT）方式是默认的流量控制方式，当QPS超过任意规则的阈值后，新的请求就会被立即拒绝，拒绝方式为抛出FlowException。这种方式适用于对系统处理能力确切已知的情况下，比如通过压测确定了系统的准确水位时。

🍀（1）Warm Up（激增流量 ）

Warm Up（RuleConstant.CONTROL_BEHAVIOR_WARM_UP）方式，即预热/冷启动方式。当系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮。

冷加载因子: codeFactor 默认是3，即请求 QPS 从 threshold / 3 开始，经预热时长逐渐升至设定的 QPS 阈值。通常冷启动的过程系统允许通过的 QPS 曲线如下图所示：

测试用例：

@RequestMapping("/test")
public String test() 
  try 
    Thread.sleep(100);
   catch (InterruptedException e) 
    e.printStackTrace();
  
    return "========test()========";

编辑流控规则：

jmeter测试：

查看实时监控，可以看到通过QPS存在缓慢增加的过程：

🍀（2）匀速排队（脉冲流量）

匀速排队（RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER）方式会严格控制请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。

该方式的作用如下图所示：

这种方式主要用于处理间隔性突发的流量，例如消息队列。想象一下这样的场景，在某一秒有大量的请求到来，而接下来的几秒则处于空闲状态，我们希望系统能够在接下来的空闲期间逐渐处理这些请求，而不是在第一秒直接拒绝多余的请求。

注意： 匀速排队模式暂时不支持 QPS > 1000 的场景。

jemeter压测：

查看实时监控，可以看到通过QPS为5，体现了匀速排队效果。

四、熔断降级规则

除了流量控制以外，对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。我们需要对不稳定的弱依赖服务调用进行熔断降级，暂时切断不稳定调用，避免局部不稳定因素导致整体的雪崩。熔断降级作为保护自身的手段，通常在客户端（调用端）进行配置。

1️⃣熔断降级规则说明

熔断降级规则（DegradeRule）包含下面几个重要的属性：

Field说明默认值
resource资源名，即规则的作用对象
grade熔断策略，支持慢调用比例/异常比例/异常数策略慢调用比例
count慢调用比例模式下为慢调用临界 RT（超出该值计为慢调用）；异常比例/异常数模式下为对应的阈值
timeWindow熔断时长，单位为 s
minRequestAmount熔断触发的最小请求数，请求数小于该值时即使异常比率超出阈值也不会熔断（1.7.0 引入）5
statIntervalMs统计时长（单位为 ms），如 60*1000 代表分钟级（1.8.0 引入）1000 ms
slowRatioThreshold慢调用比例阈值，仅慢调用比例模式有效（1.8.0 引入）

2️⃣熔断策略

🍀（1）慢调用比例

慢调用比例 (SLOW_REQUEST_RATIO)：选择以慢调用比例作为阈值，需要设置允许的慢调用 RT（即最大的响应时间），请求的响应时间大于该值则统计为慢调用。当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目，并且慢调用的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF­OPEN 状态），若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断，若大于设置的慢调用 RT 则会再次被熔断。

测试用例：

@RequestMapping("/test")
public String test() 
  try 
    Thread.sleep(100);
   catch (InterruptedException e) 
    e.printStackTrace();
  
  return "========test()========";

jemeter压测/test接口，保证每秒请求数超过配置的最小请求数：

查看实时监控，可以看到断路器熔断效果：

此时浏览器访问会出现服务降级结果：

🍀（2）异常比例

异常比例 (ERROR_RATIO)：当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目，并且异常的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF­OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。异常比率的阈值范围是 [0.0, 1.0]，代表 0% ­ 100%。

测试用例：

@RequestMapping("/test2")
public String test2() 
  atomicInteger.getAndIncrement();
  if (atomicInteger.get() % 2 == 0)
    //模拟异常和异常比率
    int i = 1/0;
  
  return "========test2()========";

配置降级规则：

查看实时监控，可以看到断路器熔断效果：

🍀（3）异常数

异常数 (ERROR_COUNT)：当单位统计时长内的异常数目超过阈值之后会自动进行熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF­OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。

注意：异常降级仅针对业务异常，对 Sentinel 限流降级本身的异常（BlockException）不生效。

配置降级规则：

jemeter测试：

查看实时监控，可以看到断路器熔断效果：

整合openfeign进行降级：

引入依赖：

<dependency>
  <groupId>com.alibaba.cloud</groupId>
  <artifactId>spring‐cloud‐starter‐alibaba‐sentinel</artifactId>
</dependency>
<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring‐cloud‐starter‐openfeign</artifactId>
</dependency>

application.yml：

#对Feign的支持
feign:
  sentinel:
    enabled: true # 添加feign对sentinel的支持

openfegin接口：

@FeignClient(value = "nacos‐payment‐provider",fallback =ConsumerFallBackService.class )
public interface ConsumerService 

  @GetMapping(value = "/paymentSQL/id")
  public CommonResult<Payment> paymentSQL(@PathVariable("id") Long id);

openfegin的fallback实现类：

@Component
public class ConsumerFallBackService implements ConsumerService 
  @Override
  public CommonResult<Payment> paymentSQL(Long id) 
    return new CommonResult<Payment>("500","进入兜底方法‐‐‐ConsumerFallBackService",null);

五、热点参数限流

热点参数限流 热点识别流控何为热点？热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的数据，并对其访问进行限制。比如：

热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制，仅对包含热点参数的资源调用生效。

注意：

  1. 热点规则需要使用@SentinelResource(“resourceName”)注解，否则不生效
  2. 参数必须是7种基本数据类型才会生效

测试用例：

@RequestMapping("/info/id")
@SentinelResource(value = "userinfo",blockHandlerClass = CommonBlockHandler.class,blockHandler = "handleException2",fallbackClass = CommonFallback.class,fallback = "fallback")
public R info(@PathVariable("id") Integer id)
  UserEntity user = userService.getById(id);
  return R.ok().put("user", user);

单机阈值： 针对所有参数的值进行设置的一个公共的阈值

  1. 假设当前 参数 大部分的值都是热点流量， 单机阈值就是针对热点流量进行设置， 额外针对普通流量进行参数值流控
  2. 假设当前 参数 大部分的值都是普通流量， 单机阈值就是针对普通流量进行设置， 额外针对热点流量进行参数值流控

配置热点参数规则：

注意： 资源名必须是@SentinelResource(value=“资源名”)中 配置的资源名，热点规则依赖于注解。

具体到参数值限流，配置参数值为3,限流阈值为1。

测试：

http://localhost:8800/user/info/1 限流的阈值为3 ；
http://localhost:8800/user/info/3 限流的阈值为1。

![在这里插入图片描述](https://img-blog.csdnimg.cn/ec667e76c7844353a0dc7322d2368f90.png#pic_center 400x)

六、系统规则

Sentinel 系统自适应限流从整体维度对应用入口流量进行控制，结合应用的 Load、CPU 使用率、总体平均 RT、入口 QPS 和并发线程数等几个维度的监控指标，通过自适应的流控策略，让系统的入口流量和系统的负载达到一个平衡，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。

  • 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 达到阈值即触发系统保护。

编写系统规则：

jemeter配置：

测试结果：

七、授权控制规则

很多时候，我们需要根据调用来源来判断该次请求是否允许放行，这时候可以使用 Sentinel 的来源访问控制（黑白名单控制）的功能。来源访问控制根据资源的请求来源（origin）限制资源是否通过，若配置白名单则只有请求来源位于白名单内时才可通过；若配置黑名单则请求来源位于黑名单时不通过，其余的请求通过。

来源访问控制规则（AuthorityRule）非常简单，主要有以下配置项：

  • resource：资源名，即限流规则的作用对象。
  • limitApp：对应的黑名单/白名单，不同 origin 用 , 分隔，如 appA,appB。
  • strategy：限制模式，AUTHORITY_WHITE 为白名单模式，AUTHORITY_BLACK 为黑名单模式，默认为白名单模式。

配置授权规则：

第一步：实现com.alibaba.csp.sentinel.adapter.spring.webmvc.callback.RequestOriginParser接口，在parseOrigin方法中区分来源，并交给spring管理注意：如果引入CommonFilter，此处会多出一个：

import com.alibaba.csp.sentinel.adapter.spring.webmvc.callback.RequestOriginParser;
import org.springframework.stereotype.Component;

import javax.servlet.http.HttpServletRequest;

/**
* @author Fox
*/
@Component
public class MyRequestOriginParser implements RequestOriginParser 
  /**
   * 通过request获取来源标识，交给授权规则进行匹配
   * @param request
   * @return
   */
  @Override
  public String parseOrigin(HttpServletRequest request) 
    // 标识字段名称可以自定义
    String origin = request.getParameter("serviceName");
    // if (StringUtil.isBlank(origin))
    // throw new IllegalArgumentException("serviceName参数未指定");
    // 
    return origin;

测试：origin是order的请求不通过。


八、集群规则

为什么要使用集群流控呢？假设我们希望给某个用户限制调用某个 API 的总 QPS 为 50，但机器数可能很多（比如有 100 台）。这时候我们很自然地就想到，找一个 server 来专门来统计总的调用量，其它的实例都与这台 server 通信来判断是否可以调用。这就是最基础的集群流控的方式。

另外集群流控还可以解决流量不均匀导致总体限流效果不佳的问题。假设集群中有 10 台机器，我们给每台机器设置单机限流阈值为 10 QPS，理想情况下整个集群的限流阈值就为 100 QPS。不过实际情况下流量到每台机器可能会不均匀，会导致总量没有到的情况下某些机器就开始限流。因此仅靠单机维度去限制的话会无法精确地限制总体流量。而集群流控可以精确地控制整个集群的调用总量，结合单机限流兜底，可以更好地发挥流量控制的效果。

https://github.com/alibaba/Sentinel/wiki/集群流控

集群流控中共有两种身份：

  • Token Client：集群流控客户端，用于向所属 Token Server 通信请求token。集群限流服务端会返回给客户端结果，决定是否限流。
  • Token Server：即集群流控服务端，处理来自 Token Client的请求，根据配置的集群规则判断是否应该发放token（是否允许通过）。

Sentinel 集群流控支持限流规则和热点规则两种规则，并支持两种形式的阈值计算方式：

  • 集群总体模式：即限制整个集群内的某个资源的总体 qps 不超过此阈值。
  • 单机均摊模式：单机均摊模式下配置的阈值等同于单机能够承受的限额，token server 会根据连接数来计算总的阈值（比如独立模式下有 3个 client 连接到了 token server，然后配的单机均摊阈值为 10，则计算出的集群总量就为30），按照计算出的总的阈值来进行限制。这种方式根据当前的连接数实时计算总的阈值，对于机器经常进行变更的环境非常适合。

Sentinel 集群限流服务端有两种启动方式：

  • 独立模式（Alone），即作为独立的 token server 进程启动，独立部署，隔离性好，但是需要额外的部署操作。独立模式适合作为Global Rate Limiter 给集群提供流控服务。

  • 嵌入模式（Embedded），即作为内置的 token server与服务在同一进程中启动。在此模式下，集群中各个实例都是对等的，token server 和 client可以随时进行转变，因此无需单独部署，灵活性比较好。但是隔离性不佳，需要限制 token server 的总QPS，防止影响应用本身。嵌入模式适合某个应用集群内部的流控。

云上版本 AHAS Sentinel 提供开箱即用的全自动托管集群流控能力，无需手动指定/分配 token server 以及管理连接状态，同时支持分钟小时级别流控、大流量低延时场景流控场景，同时支持 Istio/Envoy 场景的 Mesh 流控能力。

后记

👉Java全栈学习路线可参考：【Java全栈学习路线】最全的Java学习路线及知识清单，Java自学方向指引，内含最全Java全栈学习技术清单~
👉算法刷题路线可参考：算法刷题路线总结与相关资料分享，内含最详尽的算法刷题路线指南及相关资料分享~

Spring Cloud Alibaba全家桶——Spring Cloud Alibaba介绍

前言

本文为 Spring Cloud Alibaba介绍 相关知识，下边将对微服务介绍（包括：系统架构演变、微服务架构介绍、常见微服务架构），Spring Cloud Alibaba介绍（包括：Spring Cloud Alibaba 的定位、Spring Cloud 各套实现对比、Spring Cloud Alibaba 生态）及Spring Cloud Alibaba环境搭建等进行详尽介绍~

📌博主主页：小新要变强 的主页
👉Java全栈学习路线可参考：【Java全栈学习路线】最全的Java学习路线及知识清单，Java自学方向指引，内含最全Java全栈学习技术清单~
👉算法刷题路线可参考：算法刷题路线总结与相关资料分享，内含最详尽的算法刷题路线指南及相关资料分享~
👉Java微服务开源项目可参考：企业级Java微服务开源项目（开源框架，用于学习、毕设、公司项目、私活等，减少开发工作，让您只关注业务！）

目录

Spring Cloud Alibaba介绍

一、微服务介绍

1️⃣系统架构演变

随着互联网的发展，网站应用的规模也在不断的扩大，进而导致系统架构也在不断的进行变化。

从互联网早起到现在，系统架构大体经历了下面几个过程: 单体应用架构—>垂直应用架构—>分布
式架构—>SOA架构—>微服务架构，当然还有悄然兴起的Service Mesh(服务网格化)。

接下来我们就来了解一下每种系统架构是什么样子的， 以及各有什么优缺点。

🍀（1）单体应用架构

互联网早期，一般的网站应用流量较小，只需一个应用，将所有功能代码都部署在一起就可以，这样可以减少开发、部署和维护的成本。

比如说一个电商系统，里面会包含很多用户管理，商品管理，订单管理，物流管理等等很多模块，我们会把它们做成一个web项目，然后部署到一台tomcat服务器上。

优点：

  • 项目架构简单，小型项目的话， 开发成本低
  • 项目部署在一个节点上， 维护方便

缺点：

  • 全部功能集成在一个工程中，对于大型项目来讲不易开发和维护
  • 项目模块之间紧密耦合，单点容错率低
  • 无法针对不同模块进行针对性优化和水平扩展

🍀（2）垂直应用架构

随着访问量的逐渐增大，单一应用只能依靠增加节点来应对，但是这时候会发现并不是所有的模块都会有比较大的访问
量.

还是以上面的电商为例子， 用户访问量的增加可能影响的只是用户和订单模块， 但是对消息模块的影响就比较小. 那么此时我们希望只多增加几个订单模块， 而不增加消息模块. 此时单体应用就做不到了， 垂直应用就应运而生了.

所谓的垂直应用架构，就是将原来的一个应用拆成互不相干的几个应用，以提升效率。比如我们可以将上面电商的单体
应用拆分成:

  • 电商系统(用户管理 商品管理 订单管理)
  • 后台系统(用户管理 订单管理 客户管理)
  • CMS系统(广告管理 营销管理)

这样拆分完毕之后，一旦用户访问量变大，只需要增加电商系统的节点就可以了，而无需增加后台和CMS的节点。

优点：

  • 系统拆分实现了流量分担，解决了并发问题，而且可以针对不同模块进行优化和水扩展
  • 一个系统的问题不会影响到其他系统，提高容错率

缺点：

  • 系统之间相互独立， 无法进行相互调用
  • 系统之间相互独立， 会有重复的开发任务

🍀（3）分布式架构

当垂直应用越来越多，重复的业务代码就会越来越多。这时候，我们就思考可不可以将重复的代码抽取出来，做成统一的业务层作为独立的服务，然后由前端控制层调用不同的业务层服务呢？

这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分，服务层中包含业务逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。

优点：

  • 抽取公共的功能为服务层，提高代码复用性

缺点：

  • 系统间耦合度变高，调用关系错综复杂，难以维护

🍀（4）SOA架构

在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行实时管理。此时，用于资源调度和治理中心(SOA Service Oriented Architecture)是关键。

优点:

  • 使用治理中心（ESB\\dubbo）解决了服务间调用关系的自动调节

缺点:

  • 服务间会有依赖关系，一旦某个环节出错会影响较大( 服务雪崩 )
  • 服务关系复杂，运维、测试部署困难

🍀（5）微服务架构

微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步，它更加强调服务的"彻底拆分"。

微服务架构与SOA架构的不同

微服务架构比 SOA架构粒度会更加精细，让专业的人去做专业的事情（专注），目的提高效率，每个服务于服务之间互不影响，微服务架构中，每个服务必须独立部署，微服务架构更加轻巧，轻量级。

SOA 架构中可能数据库存储会发生共享，微服务强调独每个服务都是单独数据库，保证每个服务于服务之间互不影响。

项目体现特征微服务架构比 SOA 架构更加适合与互联网公司敏捷开发、快速迭代版本，因为粒度非常精细。

优点：

  • 服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展
  • 微服务之间采用Restful等轻量级http协议相互调用

缺点：

  • 分布式系统开发的技术成本高（容错、分布式事务等）
  • 复杂性更高。各个微服务进行分布式独立部署，当进行模块调用的时候，分布式将会变得更加麻烦。

2️⃣微服务架构介绍

作者：

Martin Fowler

论文原文:https://martinfowler.com/articles/microservices.html
论文翻译:http://blog.cuicc.com/blog/2015/07/22/microservices

他说微服务其实是一种架构风格，我们在开发一个应用的时候这个应用应该是由一组小型服务组成，每个小型服务都运行在自己的进程内；小服务之间通过HTTP的方式进行互联互通。

微服务架构的常见问题

一旦采用微服务系统架构，就势必会遇到这样几个问题：

  • 这么多小服务，如何管理他们？(服务治理 注册中心[服务注册 发现 剔除]) nacos
  • 这么多小服务，他们之间如何通讯？(restful rpc dubbo feign) httpclient(“url”,参数)， springBoot restTemplate(“url”,参数) , feign
  • 这么多小服务，客户端怎么访问他们？(网关) gateway
  • 这么多小服务，一旦出现问题了，应该如何自处理？(容错) sentinel
  • 这么多小服务，一旦出现问题了，应该如何排错? (链路追踪) skywalking

对于上面的问题，是任何一个微服务设计者都不能绕过去的，因此大部分的微服务产品都针对每一个问题提供了相应的组件来解决它们。

3️⃣常见微服务架构

🍀（1）dubbo: zookeeper +dubbo + SpringMVC/SpringBoot

  • 配套 通信方式：rpc
  • 注册中心：zookeeper / redis
  • 配置中心：diamond

🍀（2）SpringCloud：全家桶+轻松嵌入第三方组件(Netflix)

  • 配套 通信方式：http restful
  • 注册中心：eruka / consul
  • 配置中心：config
  • 断路器：hystrix
  • 网关：zuul
  • 分布式追踪系统：sleuth + zipkin

🍀（3）SpringCloud Alibaba

  • Spring Cloud 以微服务为核心的分布式系统构建标准

“分布式系统中的常见模式”给了 Spring Cloud 一个清晰的定位，即“模式”。也就是说 Spring Cloud 是针对分布式系统开发所做的通用抽象，是标准模式的实现。这个定义非常抽象，看完之后并不能知道 Spring Cloud 具体包含什么内容。再来看一下 Spring 官方给出的一个 High Light 的架构图，就可以对这套模式有更清晰的认识：

可以看到这个图中间就是各个 Microservice，也就是我们的这个微服务的实现，周边周围的话就是去围绕这个微服务来去做各种辅助的信息事情。例如分布式追踪、服务注册、配置服务等，都绕微服务运行时所依赖的必不可少的的支持性功能。我们可以得出这样一个结论：Spring Cloud 是以微服务为核心的分布式系统的一个构建标准。

二、Spring Cloud Alibaba介绍

Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发微服务架构的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发微服务架构。

依托 Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里分布式应用解决方案，通过阿里中间件来迅速搭建分布式应用系统。

根据 Jakarta 2019 年的调研报告，Spring Boot 拥有非常高的占比。熟悉 Java 语言的同学，应该对 Spring 框架都不会陌生。其倡导的依赖倒置、面向切面编程等特性已经形成了 Java 语言的事实标准，几乎所有三方框架都会提供对 Spring 框架的支持。

1️⃣Spring Cloud Alibaba 的定位

既然说 Spring Cloud 是标准，那么自然少不了针对标准的实现。这里，为大家介绍下 Spring Cloud Alibaba 这套实现。先给出下面这张图帮助大家理解 Spring Cloud Alibaba 的定位：

这里给大家这么一个公式，这个叫做：“3 加 2”。

3 指的就是图中深色的部分，其实它就是 Spring Cloud 标准，一共有 3 层。中间颜色最深的部分就是及整个微服务最核心的内容，包括了“ RPC调用”以及“服务注册与发现”。第二层，也就是围绕着核心的这一圈，是一些辅助微服务更好的工作功能，包括了负载均衡、路由、网关、断路器，还有就是追踪等等这些内容。再外层的话，主要是一些分布式云环境里通用能力。

2 指的就是上图中最外面这一圈。这一部分就是这个我们 Spring Cloud Alibaba 的一个定义，它其实包含两个部分的内容：右上部分是对于 Spring Cloud 标准的实现。例如，我们通过 Dubbo 实现了 RPC 调用功能，通过 Nacos 实现了“服务注册与发现”、“分布式配置”，通过 Sentinel 实现了断路器等等，这里就不一一列举了。

左下部分是我们 Spring Cloud Alibaba 对阿里云各种服务的集成。可能很多小伙伴会有这样的一个问题：为什么要加上这一部分呢？此时回头审视一下 Spring Cloud ，它仅仅是一个微服务的一个框架。但是在实际生产过程中，单独使用微服务框架其实并不足以支撑我们去构建一个完整的系统。所以这部分是用阿里帮助开发者完成微服务以外的云产品集成的功能。

这里可能会很多小伙伴会有这么一个担心：是不是使用了 Spring Cloud Alibaba，就会被阿里云平台绑定呢？这是不会的。为什么这么说呢？如上面说的，“3 加 2”中的 2 是被分为两个部分的。其中对 Spring Cloud 的实现是完全独立的，开发者可以只是用这部分实现运行在任何云平台中。当然，另一部分，由于天然是对阿里云服务的集成，这部分是和平台相关的。这里给开发者充分的自由，选择只是用其中的部分还是全部产品。当然，我们也非常欢迎开发者选择使用阿里云的全套服务，我们也会尽量保证使用整套产品时的连贯性与开发的便利性。

2️⃣Spring Cloud 各套实现对比

Spring Cloud 作为一套标准，它的实现肯定不止一套，那么各套实现都有什么区别呢？我们来一起看一下下面这张图：

可以发现 Spring Cloud Alibaba 是所有的实现方案中功能最齐全的。尤其是在 Netflix 停止更新了以后，Spring Cloud Alibaba 依然在持续更新和迭代。

从 18 年 7 月份 Spring Cloud Alibaba 正式提交代码开始，就得到了大家广泛的关注。截止今天，Spring Cloud Alibaba 一共获得了超过了 1.5 万的 star 数，已经的领先于所有其他实现的总和。

3️⃣Spring Cloud Alibaba 生态

可以看到除了围绕着 Spring Cloud 的标准实现以外，还有包括的数据、资源、消息、缓存等各种类型的服务。在不同类型的服务下，也有很多具体的产品可供用户选择。

这里罗列典型而非全部产品。更多的内容，可以参考阿里云官网。

三、Spring Cloud Alibaba环境搭建

SpringCloud Alibaba 依赖 Java 环境来运行。还需要为此配置 Maven环境，请确保是在以下版本环境中安装使用:

  • 64 bit JDK 1.8+；下载 & 配置。 1.8.0_131
  • Maven 3.2.x+；下载 & 配置。 3.6.1

（1）基于SpringBoot的父maven项目

（2）创建2个服务（订单服务和库存服务）

版本说明：https://github.com/alibaba/spring-cloud-alibaba/wiki/%E7%89%88%E6%9C%AC%E8%AF%B4%E6%98%8E

  • Spring Cloud Alibaba:2.2.5.RELEASE
  • Spring Boot :2.3.2.RELEASE
  • Spring Cloud:Hoxton.SR8

父pom如下：

<?xml version="1.0" encoding="UTF‐8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema‐instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven‐4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring‐boot‐starter‐parent</artifactId>
<version>2.3.2.RELEASE</version>
<relativePath/> <!‐‐ lookup parent from repository ‐‐>
</parent>
<groupId>com.tuling.mall</groupId>
<artifactId>vip‐spring‐cloud‐alibaba</artifactId>
<version>0.0.1‐SNAPSHOT</version>
<name>vip‐spring‐cloud‐alibaba</name>
<packaging>pom</packaging>
<description>Demo project for Spring Cloud Alibaba</description>

<properties>
<java.version>1.8</java.version>
<spring‐cloud.version>Hoxton.SR8</spring‐cloud.version>
<spring‐cloud‐alibaba.version>2.2.5.RELEASE</spring‐cloud‐alibaba.version>
</properties>

<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring‐cloud‐dependencies</artifactId>
<version>$spring‐cloud.version</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring‐cloud‐alibaba‐dependencies</artifactId>
<version>$spring‐cloud‐alibaba.version</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>

</project>

后记

👉Java全栈学习路线可参考：【Java全栈学习路线】最全的Java学习路线及知识清单，Java自学方向指引，内含最全Java全栈学习技术清单~
👉算法刷题路线可参考：算法刷题路线总结与相关资料分享，内含最详尽的算法刷题路线指南及相关资料分享~

以上是关于Spring Cloud Alibaba全家桶——Sentinel控制台规则配置的主要内容，如果未能解决你的问题，请参考以下文章

Spring Cloud Alibaba全家桶——微服务调用组件Feign

Spring Cloud Alibaba全家桶——微服务链路追踪SkyWalking

Spring Cloud Alibaba全家桶——微服务组件Nacos注册中心

Spring Cloud Alibaba全家桶——微服务组件Sentinel介绍与使用

Spring Cloud Alibaba全家桶——微服务组件Nacos配置中心

Spring Cloud Alibaba全家桶——Sentinel规则持久化