随着微服务的流行,服务和服务之间的稳定性变得越来越重要。Sentinel 是面向分布式服务架构的流量控制组件,主要以流量为切入点,从流量控制、熔断降级、系统自适应保护等多个维度来帮助您保障微服务的稳定性。
今天给大家介绍一些在使用过程中会遇到的一些问题。
@SentinelResource 可以作用于方法上的熔断降级保护,跟 Hystrix 的@HystrixCommand 注解作用是一样的。
做监控的目的是为了在业务方法触发了熔断降级规则后,在对应的监控视图中可以看到这个操作触发了对应的规则。
@SentinelResource 的工作依赖于 SentinelResourceAspect 这个切面,需要监控的话对 SentinelResourceAspect 这个类进行改造就可以了。
在流量突然上升的时候,也就意味着随时都可能迎来请求量的高峰,就会触发限流。我们也需要有一定的监控手段来提前告警,这种场景可以扩展 Slot 来实现提前告警的方案,具体方式可以查询这篇文章:https://mp.weixin.qq.com/s/qhep2f9HgK7sZFcdKMAMVg
在 Sentinel 中,以资源的概念来进行对应的限流熔断操作。如果你们的 API 是 RestFul 风格,就会出现同一个接口变成 N 个资源的情况。
可以用@SentinelResource 为每个接口固定好资源名,这样比较繁琐。所以需要对这类的 API 进行格式化,变成一个资源。相关实现参考:https://blog.csdn.net/luanlouis/article/details/91633042还挺全的。
核心原理就是重写 UrlCleaner 的实现逻辑,利用正则进行匹配处理。
这类操作不仅仅是在 Sentinel 中会遇到,在其他的框架中也经常会遇到这种情况。比如在 Cat 中也会有类似场景,对 API 进行监控,如果不处理同样会出现 N 个监控项。
如果需要对某个调用方进行限流,我们可以利用 Origin 方式来实现。建议做成动态配置方式,比如支持 IP, 支持请求头中的参数等方式进行限制。
内部服务之间调用还可以将本服务的应用名存放在请求头中传递过去,这样就可以在 Sentinel 中基于 Origin 来实现内部服务调用的流量控制。
对于热点参数的流控,也可以做成动态配置的方式。
比如当前是商品 ID 为热点参数,后面是订单 ID 为热点参数。
比如当前是商品接口,后面是订单接口。
可以从 url 参数中获取热点参数,可以从 header 中获取热点参数,可以从 path 路径中获取热点参数。
增加一个配置信息,然后扩展 Sentinel 的 Filter 进行限流控制,根据配置获取对应的热点参数进行限流。
限流规则持久化是肯定要做的,默认规则是存储在内存中,这样一起动规则就丢失了,所以必须持久化。
持久化分为两种,首先是客户端,客户端持久化意思是说客户端需要加载对应的规则,这些规则会从一个地方进行获取,比如我们用 Apollo 配置中心来存储的话,客户端在启动时就会从 Apollo 中去拉取对应的规则信息。
对应的操作步骤和详细介绍可以查看下面这篇文章,虽然写了很久了,但是总体思路什么的都没变化。
Sentinel Client: 整合 Apollo 规则持久化:https://mp.weixin.qq.com/s/K9JtdGoLD1XALq5D67slPQ
然后是服务端也就是控制台的持久化,我们可以在控制台进行规则的添加和编辑,然后会把对应的配置信息推送给所有的客户端,这样规则就生效了。
同样存储重启即丢失的情况,所以控制台也需要进行持久化规则。如果客户端对接了 Apollo,那么控制也需要对接 Apollo 将规则信息存储到 Apollo 中,这样整个流程就连起来了。
可以参考这篇文章:阿里 Sentinel 控制台:-整合 Apollo 规则持久化:https://mp.weixin.qq.com/s/deigVXhEd9HycuLLm-oJzA
Sentinel 控制台的实时监控数据,默认仅存储 5 分钟以内的数据。如果需要持久化,需要实现框架提供的相关接口进行改造。
5 分钟确实很短,最起码要存储最近 3 天的数据,这样方便查看流量的趋势。
关于相关实现大家可以去看文档,比较简单,主要就是实现 MetricsRepository,将监控的数据存储到对应的数据库中。
相关改造源码可以参考:https://github.com/yinjihuan/kitty/tree/master/kitty-distributed/kitty-distributed-sentinel