2024年最新还在担心服务挂掉？Sentinel Go 让服务稳如磐石(2)，2024年最新Golang驱动工程师面试题

2401_84911504

于 2024-05-16 01:02:07 发布

阅读量300

点赞数 3

文章标签： go 学习面试

本文链接：https://blog.csdn.net/2401_84911504/article/details/138930119

版权

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

背景

======

微服务的稳定性一直是开发者非常关注的话题。随着业务从单体架构向分布式架构演进以及部署方式的变化，服务之间的依赖关系变得越来越复杂，业务系统也面临着巨大的高可用挑战。

还在担心服务挂掉？Sentinel Go 让服务稳如磐石

在生产环境中大家可能遇到过以下不稳定的情况：

大促时瞬间洪峰流量导致系统超出最大负载，load 飙高，系统崩溃导致用户无法下单
“黑马”热点商品击穿缓存，DB 被打垮，挤占正常流量
调用端被不稳定第三方服务拖垮，线程池被占满，调用堆积，导致整个调用链路卡死

这些不稳定的场景可能会导致严重后果，但很多时候我们又容易忽视这些与流量/依赖相关的高可用防护。大家可能想问：如何预防这些不稳定因素带来的影响？如何针对流量进行高可用的防护？如何保障服务“稳如磐石”？这时候我们就要请出服务高可用保障的利器 —— Sentinel。

Sentinel介绍

==============

Sentinel 是阿里巴巴开源的，面向分布式服务架构的流量控制组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统自适应保护等多个维度来帮助开发者保障微服务的稳定性。Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀、冷启动、消息削峰填谷、集群流量控制、实时熔断下游不可用服务等，是保障微服务高可用的利器，原生支持 Java/Go/C++ 等多种语言，并且提供 Istio/Envoy 全局流控支持来为 Service Mesh 提供高可用防护的能力。

还在担心服务挂掉？Sentinel Go 让服务稳如磐石

在今年年初，社区宣布了 Sentinel Go 版本的发布，为 Go 语言的微服务提供流控降级、系统自适应保护等特性的原生支持，标志着 Sentinel 朝着多元化与云原生迈出了重要的一步。在这半年的时间内，社区推出了近 10 个版本，逐步对齐了限流、熔断降级、系统自适应流控、热点防护等核心能力；同时社区也在不断扩充开源生态，目前已提供 go-micro、gRPC、Dubbo、Gin 等框架的适配模块，使用这些框架的开发者可以非常简单快速地接入 Sentinel。

Sentinel 里面有两个核心的抽象概念：资源和规则：

资源 (resource) 是 Sentinel 的关键概念，它代表某个逻辑块、函数或接口的调用。它可以是某个 Web API，或者是某个 RPC 服务，甚至是任意的代码块。使用 Sentinel 的 API 将业务逻辑封装起来（或引入 Sentinel 提供的插件），这一步称为“埋点”。每个埋点都有一个资源名称，代表触发了这个资源的调用或访问。
规则 (rule) 即定义到达怎样的条件后进行怎样的控制，针对某个资源或某些资源生效。所有规则都可以动态实时调整，社区提供了 etcd、Consul、Nacos 等动态数据源适配，可以方便地通过这些配置组件来管理规则。

还在担心服务挂掉？Sentinel Go 让服务稳如磐石

Sentinel 底层通过高性能的滑动窗口进行秒级调用指标统计，结合 token bucket, leaky bucket 和自适应流控算法来透出核心的高可用防护能力。

还在担心服务挂掉？Sentinel Go 让服务稳如磐石

那么我们如何利用 Sentinel Go 来保证我们微服务的稳定性？下面我们来看几个典型的场景。

高可用防护的核心场景

==============

1.流量控制

==========

流量是非常随机性的、不可预测的。前一秒可能还风平浪静，后一秒可能就出现流量洪峰了（例如双十一零点的场景）。然而我们系统的容量总是有限的，如果突然而来的流量超过了系统的承受能力，就可能会导致请求处理不过来，堆积的请求处理缓慢，CPU/Load 飙高，最后导致系统崩溃。因此，我们需要针对这种突发的流量来进行限制，在尽可能处理请求的同时来保障服务不被打垮，这就是流量控制。流量控制的场景是非常通用的，像脉冲流量类的场景都是适用的。

通常在 Web 入口或服务提供方（Service Provider）的场景下，我们需要保护服务提供方自身不被流量洪峰打垮。这时候通常根据服务提供方的服务能力进行流量控制，或针对特定的服务调用方进行限制。我们可以结合前期压测评估核心接口的承受能力，配置 QPS 模式的流控规则，当每秒的请求量超过设定的阈值时，会自动拒绝多余的请求。

下面是最简单的一个 Sentinel 限流规则的配置示例：

_, err = flow.LoadRules([]*flow.FlowRule{

{

Resource: “some-service”, // 埋点资源名

MetricType: flow.QPS, // QPS 模式

Count: 10, // QPS 阈值为 10，即该请求单机每秒不超过 10 次

ControlBehavior: flow.Reject, // 控制效果为直接拒绝，不排队

})

2.Warm-Up 预热流控

==================

近期发布的 Sentinel Go 0.6.0 版本带来了一种新的流控场景：Warm-Up 预热流控。当系统长期处于低水位的情况下，流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。比如刚启动的服务，数据库连接池可能还未初始化，缓存也处于空的状态，这时候激增的流量非常容易导致服务崩溃。如果采用传统的限流模式，不加以平滑/削峰限制，其实也是有被打挂的风险的（比如一瞬间并发很高）。针对这种场景，我们就可以利用 Sentinel 的 Warm-Up 流控模式，控制通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，而不是在一瞬间全部放行，同时结合请求间隔控制+排队的控制效果来防止大量请求都在同一时刻被处理。这样可以给冷系统一个预热的时间，避免冷系统被压垮。

还在担心服务挂掉？Sentinel Go 让服务稳如磐石