精华推荐 |【深入浅出Sentinel原理及实战】「原理探索专题」完整剖析Alibaba微服务架构体系之轻量级高可用流量控制组件Sentinel(1)

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 精华推荐 |【深入浅出Sentinel原理及实战】「原理探索专题」完整剖析Alibaba微服务架构体系之轻量级高可用流量控制组件Sentinel(1)

Sentinel是什么?不要概念混淆啊!


注意:本Sentinel与Redis服务Sentinel是两回事,压根不是一个概念,请大家不要混肴。


Alibaba的Sentinel


Sentinel是由阿里巴巴中间件团队开发的开源项目,是一种面向分布式微服务架构的轻量级高可用流量控制组件。



Redis中的Sentinel


Sentinel(哨兵)是 Redis 的高可用性解决方案:由一个或多个 Sentinel 实例组成的 Sentinel 系统可以监视任意多个主服务器,以及这些主服务器属下的所有从服务器,并在被监视的主服务器进入下线状态时,自动将下线主服务器属下的某个从服务器升级为新的主服务器。



所以加下来我们介绍的都是【Alibaba的Sentinel】,所以请大家不要理解错误哦!好 我们接下来进入正题。





Sentinel出现的意义


伴随微服务的的越来越成熟和稳定发展,服务和服务之间的稳定性变得越来越重要。Sentinel以流量为切入点,从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。




Sentinel的历史


首先针对于Sentinel进行梳理一下对应的发展史,看看Sentinel是如何一步一步的发展起来的,Sentinel是2012年创立出来的,距今已经成长了10个年头了,接下来我们看看每个它阶段的成长经历吧!如下图所示。image.png

根据上面介绍的对应的发展历程,我大概给Sentinel的发展经历划分为三个大阶段,如下所示。

image.png



基础功能的不断升级及开源化(初级成熟阶段)


  • 2012年:Sentinel诞生,主要功能为入口流量控制。


  • 2013 ~ 2017 年:Sentinel在阿里巴巴集团内部迅速发展,成为基础技术模块,覆盖了所有的核心场景,Sentinel 也因此积累了大量的流量归整场景以及生产实践。


  • 2018年:Sentinel开源化,并持续演进。



多语言化扩展及Mesh过度化(进阶升级阶段)


  • 2019年:Sentinel多语言扩展的方向不断探索,推出 C++ 原生版本,同时针对 Service Mesh场景也推出了Envoy集群流量控制支持,以解决Service Mesh架构下多语言限流的问题。


  • 2020年:推出Sentinel Go版本,继续朝着云原生方向演进。



云原生化演进及体系标准化(未来发展阶段)


  • 2021年:Sentinel正在朝着 2.0 云原生高可用决策中心组件进行演进;同时推出了 Sentinel Rust 原生版本。同时我们也在 Rust 社区进行了 Envoy WASM extension 及 eBPF extension 等场景探索。


  • 2022年:Sentinel品牌升级为流量治理,领域涵盖流量路由/调度、流量染色、流控降级、过载保护/实例摘除等;同时社区将流量治理相关标准抽出到OpenSergo标准中,Sentinel 作为流量治理标准实现。




为什么选择Sentinel


本节内容主要针对于Sentinel的优点和具有的较为不错的特性进行分析,如以下图所示。

image.png

丰富的应用场景

Sentinel承接了阿里巴巴近10年的"双十一”大促流量的核心场景,例如,秒杀(将突发流量控制在系统可以承受的范围)、消息削峰填谷、集群流量控制、实时熔断下游不可用服务等。



完备的实时监控

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



广泛的开源生态

Sentinel提供了开箱即用的与其它开源框架或库(例如:Spring Cloud、Apache Dubbo、gRPC、Quarkus)的整合模块。我们只要在项目中引入相应的依赖并进行简单的配置即可快速地接入Sentinel。此外,Sentinel还提供Java、Go 以及 C++ 等多语言的原生实现。



完善的SPI扩展机制

Sentinel提供简单易、完善的SPI扩展接口,可以通过实现这些扩展接口快速地定制逻辑。

例如,定制规则管理适配动态数据源等。



什么是SPI


SPI ,全称为 Service Provider Interface,是一种服务发现机制。它可以在 ClassPath 路径下的 META-INF/services 文件夹查找文件,并自动加载文件中定义的类。




对标Spring Cloud Netflix-Hystrix的熔断器


功能上简单对比


Sentinel与Spring Cloud Netfilx—Hystrix类似,但Sentinel要比Hystrix更加强大。例如,Sentinel提供了流量控制功能、比Hystrix更加完善的实时监控功能等等。

服务框架功能点 Hystrix Sentinel
熔断能力
资源隔离 很好 不太好
服务限流 很好
实时监控 一般 很好




Sentinel基本组成概念


资源(Resource)


资源(Resource)是Sentinel的关键概念,它可以是Java应用程序中的任何内容,例如,由应用程序提供的服务,或由应用程序调用的其它应用提供的服务,甚至可以是一段代码



定义方式


通过Sentinel API定义的代码,就是资源,能够被Sentinel保护起来。大部分情况下,可以使用方法签名,URL,甚至服务名称作为资源名来标示资源。



规则


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

image.png

流量控制规则


流量控制在网络传输中是一个常用的概念,它用于调整网络包的发送数据,主要用于处理服务调用、接口调用及相关的调用流量速度控制和限制的规则。偏向于QPS维度的概念



功能和设计理念


  • 系统稳定性角度:对于客户端或者调用段在处理请求的速度上(TPS/QPS),也有非常多的限制和控制。


  • 在系统运行的过程中,任意时间到来的请求往往是随机不可控的,而系统的处理能力是有限,需要在不均衡的情况下进行控制服务的请求与速度和容错。


  • 根据系统的处理能力对流量进行动态调整和控制。


对于以上的三点流量控制的要求,Sentinel作为一个流量调配器,可以根据需要把随机的请求调整成合适的形状,如下图所示:image.png


流量控制的维度


Sentinel的设计理念是让您自由选择控制的角度,并进行灵活组合,从而达到想要的效果。


资源的调用关系


资源的调用链路,资源和资源之间的关系


运行指标
指标名称 备注
QPS 每秒的服务调用量
线程池 服务线程调用计数器/资源隔离
系统负载 在动态化调整容器化负载能力
控制的效果
指标名称 备注
直接限流 流量控制
冷启动 如何分配对应的规则给 ,调用了较少的服务或者接口
排队 请求排队机制



熔断降级规则


主要用于当服务宕机或者此接口一直处于调用失败后的,方式进行控制是否进行熔断降级规则的开关控制。


什么是熔断降级


流量控制以外,降低调用链路中的不稳定资源也是Sentinel的使命之一。由于调用关系的复杂性,如果调用链路中的某个资源出现了不稳定,最终会导致请求发生堆积。这个问题和Hystrix里面描述的问题是一样的。如下图所示


Hystrix的熔断问题图(雪崩图)

image.png

Sentinel的熔断问题图(雪崩图)

image.png

从上面的两个图可以看出来Sentinel和Hystrix的原则是一致的: 当调用链路中某个资源出现不稳定,例如,表现为 timeout,异常比例升高的时候,则对这个资源的调用进行限制,并让请求快速失败,避免影响到其它的资源,最终产生雪崩的效果。



熔断降级实现方案


为了实现资源的隔离以及服务的熔断控制,Sentinel和Hystrix采取了完全不一样的方法。


Hystrix采用的方案


Hystrix采用的是线程池(默认)和信号量两种方案去实现。


  • 如果通过线程池的方式,来对依赖(资源之间的依赖或者资源服务之间的调用链路)进行了隔离。


  • 好处


  • 资源和资源之间做到了最彻底的隔离,并且还可以支持超时时间的控制
  • 缺点
  • 是除了增加了线程切换的成本,还需要预先给各个资源做线程池大小的分配。



  • 如果通过信号量方式进行资源隔离,则只能运行控制调用资源的总量,这与【通过并发线程数进行限制】有点类似。


Sentinel采用的方案


Sentinel采取了两种手段去实现。


  • 通过并发线程数进行限制


资源池隔离的方法不同,Sentinel通过限制资源并发线程的数量,来减少不稳定资源对其它资源的影响。这样不但没有线程切换的损耗,也不需要您预先分配线程池的大小

当某个资源出现不稳定的情况下,例如,响应时间变长,对资源的直接影响就是会造成线程数的逐步积。当线程数在特定资源上堆积到一定的数量之后,对该资源的新请求就会被拒绝。堆积的线程完成任务后才开始继续接收请求。

image.png

  • 通过响应时间对资源进行降级


对并发线程数进行控制以外,Sentinel还可以通过响应时间来快速降级不稳定的资源。当依赖的资源出现响应时间过长后,所有对该资源的访问都会被直接拒绝,直到过了指定的时间窗口之后才重新恢复。

image.png



系统保护规则


主要用于当服务系统的保护规则能力,觉得是否接收该服务的请求的处理模式机制。



系统负载保护


Sentinel 同时提供系统维度的自适应保护能力。防止雪崩,是系统防护中重要的一环。当系统负载较高的时候,如果还持续让请求进入,可能会导致系统崩溃,无法响应。在集群环境下,网络负载均衡会把本应这台机器承载的流量转发到其它的机器上去。如果这个时候其它的机器也处在一个边缘状态的时候,这个增加的流量就会导致这台机器也崩溃,最后导致整个集群不可用。


针对这个情况,Sentinel 提供了对应的保护机制,让系统的入口流量和系统的负载达到一个平衡,保证系统在能力范围之内处理最多的请求。


具体细节功能会在后面的专题文章讲述,谢谢大家多指正






相关文章
|
2天前
|
存储 监控 API
构建高效微服务架构:后端开发的现代实践
【5月更文挑战第9天】 在本文中,我们将深入探讨如何在后端开发中构建一个高效的微服务架构。通过分析不同的设计模式和最佳实践,我们将展示如何提升系统的可扩展性、弹性和维护性。我们还将讨论微服务架构在处理复杂业务逻辑和高并发场景下的优势。最后,我们将分享一些实用的工具和技术,以帮助开发者实现这一目标。
|
19小时前
|
存储 NoSQL MongoDB
【MongoDB 专栏】MongoDB 与微服务架构的结合
【5月更文挑战第11天】微服务架构流行趋势下,选择合适的数据库至关重要。MongoDB作为非关系型数据库,与微服务有天然契合度。其灵活的文档模型、水平扩展性、高性能及局部事务支持,满足微服务对数据模型多样性、高可用性、快速读写的需求。实践中,需注意数据划分、索引优化、监控调优和版本控制。未来,MongoDB在微服务中的应用将更广泛,新技术将提升其在微服务架构中的价值。
【MongoDB 专栏】MongoDB 与微服务架构的结合
|
1天前
|
监控 数据库 开发者
构建高效可靠的微服务架构:策略与实践
【5月更文挑战第11天】在当今软件开发的世界中,微服务架构已经成为构建可扩展、灵活且容错的系统的首选方法。本文深入探讨了设计、部署和维护微服务系统时面临的挑战,并提出了一系列实用的策略和最佳实践。我们将从服务的划分原则出发,讨论如何确保每个微服务的自治性,以及如何通过容器化和编排技术实现服务的高效运行。文章还将涉及监控、日志记录和故障恢复的策略,旨在帮助开发人员构建一个既高效又可靠的微服务环境。
|
1天前
|
Kubernetes API 开发者
构建高效微服务架构:后端开发的新范式
【5月更文挑战第11天】 在现代软件开发的快速演变中,微服务架构已成为企业追求敏捷性、可扩展性和技术多样性的关键解决方案。本文旨在探讨如何构建高效的微服务架构,并分析其对后端开发的影响。我们将通过一系列最佳实践和策略,展示如何优化服务的独立性、弹性和性能,同时确保系统的整体稳定性和安全性。文章还将介绍容器化、API网关、服务发现和分布式追踪等关键技术的应用,为后端开发者提供一份全面的微服务实施指南。
|
1天前
|
设计模式 监控 API
构建高效的微服务架构:后端开发的新范式
【5月更文挑战第11天】 在当今的软件开发领域,微服务架构已经成为一种流行的设计模式。它通过将应用程序分解为一组小型、松散耦合的服务来提供高度可扩展和灵活的解决方案。本文将探讨如何构建一个高效的微服务架构,包括选择合适的技术栈、设计原则以及应对常见挑战的策略。我们将深入讨论如何确保系统的可维护性、可靠性和性能,同时考虑到安全性和监控的需求。
|
2天前
|
监控 持续交付 Docker
使用Docker进行微服务架构的最佳实践
【5月更文挑战第10天】本文探讨了使用Docker实施微服务架构的最佳实践。首先,理解微服务架构是拆分小型独立服务的模式,借助Docker实现快速部署、高可移植性和环境一致性。Docker的优势在于服务扩展、容器编排、自动化构建与部署。最佳实践包括:定义清晰服务边界,使用Dockerfile和Docker Compose自动化构建,利用Docker Swarm或Kubernetes编排,实施服务发现和负载均衡,监控与日志记录,以及持续集成和持续部署。Docker虽重要,但需与其他技术结合以确保系统整体稳定性。
|
2天前
|
缓存 负载均衡 API
微服务架构下的API网关性能优化实践
【5月更文挑战第10天】在微服务架构中,API网关作为前端和后端服务之间的关键枢纽,其性能直接影响到整个系统的响应速度和稳定性。本文将探讨在高并发场景下,如何通过缓存策略、负载均衡、异步处理等技术手段对API网关进行性能优化,以确保用户体验和服务的可靠性。
|
2天前
|
监控 持续交付 开发者
构建高效微服务架构:后端开发的新范式
【5月更文挑战第10天】在现代软件开发领域,微服务架构已经成为一种流行的设计模式,它通过将大型应用程序拆分为一组小型、独立和松散耦合的服务来提供更高的可伸缩性和灵活性。本文深入探讨了微服务架构的设计理念、实施步骤以及面临的挑战,并提出了一套实用的策略和最佳实践,帮助后端开发者构建和维护高效的微服务系统。
|
3天前
|
负载均衡 算法 NoSQL
探索微服务架构下的服务发现与治理
【5月更文挑战第9天】 在当今的软件开发领域,微服务架构已成为构建可伸缩、灵活且容错的系统的首选模式。随着服务的增多,如何有效地进行服务发现与治理成为了关键的挑战。本文将深入探讨微服务环境中服务发现的机制和治理策略,分析不同服务发现工具的优缺点,并提出一种基于一致性哈希和健康检查相结合的服务治理方案,旨在提高系统的可用性和性能。
|
3天前
|
监控 API 持续交付
构建高效可靠的微服务架构:策略与实践
【5月更文挑战第8天】在当今快速演进的软件开发领域,微服务架构已经成为实现敏捷开发、持续交付和系统弹性的关键模式。本文将探讨构建一个高效且可靠的微服务系统所必须的策略和最佳实践。我们将从服务的划分与设计原则出发,讨论如何通过容器化、服务发现、API网关以及断路器模式来优化系统的可伸缩性和鲁棒性。此外,我们还将涉及监控、日志管理以及CI/CD流程在确保微服务架构稳定运行中的作用。