微服务中间件Sentinel流量防卫兵

熔断： 开 关 半开半关 qps tps

1.分布式服务遇到的问题

服务可用性问题

服务可用性场景

服务雪崩效应

因服务提供者的不可用导致服务调用者的不可用,并将不可用逐渐放大的过程，就叫服务雪崩效应导致服务不可用的原因：

在服务提供者不可用的时候，会出现大量重试的情况：用户重试、代码逻辑重试，这些重试最终导致：进一步加大请求流量。所以归根结底导致雪崩效应的最根本原因是：大量请求线程同步等待造成的资源耗尽。当服务调用者使用同步调用时, 会产生大量的等待线程占用系统资源。一旦线程资源被耗尽,服务调用者提供的服务也将处于不可用状态, 于是服务雪崩效应产生了。

解决方案

常见的容错机制

• 超时机制

在不做任何处理的情况下，服务提供者不可用会导致消费者请求线程强制等待，而造成系统资源耗尽。加入超时机制，一旦超时，就释放资源。由于释放资源速度较快，一定程度上可以抑制资源耗尽的问题。

• 服务限流

设置阈值，操作临界值不再进行向后端请求.

• 隔离

每当向服务发起一个请求时，就是会发起一个http请求,每一个http请求就要开启一个线程，然后等待服务返回信息，这容易导致线程的堆积，所以就可以用http的URI作为一个标识，然后相同的URI可以开启一个线程池，然后线程池中限定线程数，这样就可以设置拒绝策略，当线程池满了，就可以快速的抛出异常或者拒绝请求，用线程池做到线程隔离来达到限流。

• 服务熔断

熔断就是有一个阈值，向服务发起请求后，如果不成功，就会记录次数，然后当连续失败次数达到阈值时，下次请求的时候就会直接把这个服务停止。请求有三种状态，可以请求（开），不可请求（关），还有一个中间状态，相当于半开状态，半开状态是什么意思呢，就是可以尝试着去请求，就可以在关闭状态后一段时间，发一个请求尝试一下是否可以请求成功，如果不成功，继续保持关闭状态，如果请求成功，则变成开放状态。

• 服务降级（兜底）

降级其实就相当于，当我们向一个服务发起请求，当请求超时了，就会把这次请求记录到服务中，然后就会尝试向其他服务发请求，如果还没成功，就对这次请求进行处理（怎么处理取决于业务需求如）就相当于try catch一样的逻辑，当然Sentinel底层使用aop来实现的。

2.Sentinel: 分布式系统的流量防卫兵

home | Sentinel (sentinelguard.io)

2.1 Sentinel 介绍

Sentinel是阿里中间件团队研发面向分布式服务架构的轻量级高可用流量控制组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统负载保护、热点防护等多个维度来帮助开发者保障微服务的稳定性。于2012年诞生，后续在阿里巴巴集团内部迅速发展，成为基础技术模块，覆盖了所有的核心场景，Sentinel也因此积累了大量的流量归整场景及生产实践。最终在2018年7月宣布对外界开源。

Sentinel的基本概念：

资源： Sentinel 的关键概念，可以是Java应用程序中任何内容，通过Sentinel API定义的代码，能够被Sentinel保护起来，大部份情况下，可以使用方法签名，URL，甚至服务名称作为资源名

规则：围绕资源的实时状态设定的规则，可以包括流量控制规则、熔断降级规则以及系统保护规则。所有规则可以动态实时调整。

2. Sentinel功能特性

Sentinel具有以下特征:

• 丰富的应用场景： Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、实时熔断下游不可用应用等。

• 完备的实时监控： Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。

• 广泛的开源生态： Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。

• 完善的 SPI 扩展点： Sentinel 提供简单易用、完善的 SPI 扩展点。您可以通过实现扩展点，快速的定制逻辑。例如定制规则管理、适配数据源等

2.1Sentinel和Hystrix对比

Sentinel 与 Hystrix 的对比 · alibaba/Sentinel Wiki · GitHub

3.QPS & TPS

3.1 QPS (Queries Per Second)

QPS 指的是每秒钟系统能够处理的查询数量。查询可以是任何类型的请求，比如 HTTP 请求、数据库查询等。QPS 更侧重于衡量服务器处理请求的能力。

特点：

关注请求的数量：QPS 关注的是每秒能够处理多少个请求。

3.2 TPS (Transactions Per Second)

TPS 指的是每秒钟系统能够处理的事务数量。事务通常指的是一个完整的业务操作，例如完成一次订单购买过程、转账等，它通常涉及到多个步骤，包括数据的一致性检查、更新数据库等。

特点：

关注业务操作的数量：TPS 关注的是每秒能够完成多少个完整的业务操作。

涉及数据一致性：事务往往涉及到数据的一致性要求，比如 ACID 属性（原子性、一致性、隔离性、持久性）。

常用于后端服务：例如数据库服务、支付服务等。

3.3 区别总结

衡量的对象不同：

QPS 关注的是请求的数量，不区分请求的具体内容。

TPS 关注的是完整业务操作的数量，通常涉及到数据的一致性处理。

应用场景不同：

QPS 通常用于衡量接口服务的处理能力。

TPS 通常用于衡量后端服务或数据库的处理能力。

计算方法不同：

QPS 计算的是单位时间内处理的请求总数。

TPS 计算的是单位时间内完成的事务总数。

3.4 实际应用

在实际应用中，QPS 和 TPS 都是非常重要的性能指标。根据系统的具体需求，可能需要同时关注这两个指标，以确保系统的整体性能满足业务需求。例如，在设计一个电商平台时，可能需要同时监控前端 API 的 QPS 以及后端数据库的 TPS，以确保系统在高并发场景下仍然能够稳定运行。