您当前位置:资讯中心 >其他 >浏览文章

服务降级的设计与实践

来源:不详 日期:2021/5/10 14:41:36 阅读量:(0)

一、服务降级的目的

为什么服务降级?

当对业务的请求超过业务系统预设的上限阈值时,为了保证基本和重要的业务模块正常运行,

1.拒绝部分请求

2.不重要的业务模块暂停服务或延迟提供服务。


1.jpg


二、服务降级的实现手段

服务降级的手段有两大类:

第一类是关闭部分非核心服务。例如双12当天,京东暂时关闭退货服务。

第二类是拒绝部分请求。这里面又分成三个手段

(1)根据RPC队列方式,把旧的请求丢弃。我们还是想想双12买东西。在业务逻辑层pendding的旧的请求,或许客户端已经取消了,因此要舍弃请求,一定先舍弃最久的。但这种方式有个问题,旧的请求可能是核心请求,新的可能是非核心请求的。

(2)根据请求报文CMD的优先级。在CMD列表的请求保留,不在列表中的CMD舍弃。

实际应用中,需要前两种相结合,即(1)决定什么时候开启、关闭丢弃  (2)决定丢弃谁

(3)随机拒绝方式:这种不靠谱,实际环境没人用。

3.jpg


三、服务降级的设计

我们将服务降级设置在什么位置?网关还是全链路?

1.在网关层做服务降级:

   这样做不靠谱的地方是,因为一个网关后面可能有多个业务逻辑层。


4.jpg


2.全链路降级。也就是使用上上个图中两种方法结合的方式。让网关、业务逻辑层、数据访问层都有降级的机制。每一层能处理多少请求自己说了算。


5.jpg


和方案1比,方案2更靠谱。

那么,有一个小疑问,在方案2中,DB层是否需要做降级?

在上图的模型中,读同步写异步。读的时候,DAO层已经做了限流,就不用在DB层限流。在写请求时,会先写到MQ,所以只要是MQ没有超限,DB就不会出现问题。

四、熔断的实现

熔断的实现有两种方式:组件级、平台级:


6.jpg

1.组件级解决方案

Neflix的Hystrix熔断组件是个jar包。Hystrix的熔断机制是API颗粒度的。如下图所示:


7.jpg


前面说过,Hystrix是组件级的熔断,好处是使用的时候,直接引入Jar包就可以。坏处是,任何要做熔断的微服务,它的上上游都需要引入jar,而且Hystrix限制哪个API,是需要硬编码的。


8.jpg


2.平台级解决方案

如果上下游调用是RPC。我们能否把熔断的功能写入到RPC Client。这样上游引入RPC Client客户端就可以,而不需要引入单独的jar包。此外,哪些API需要熔断,最好写在配置中心。

如下图所示,我们在dashboard写入要限制API的名称以及参数,然后通过服务管理平台将配置规则推送给网关。网关上的RPC Client(RPC Over TCP)可以解析这些配置,并其下游的业务逻辑层对应的API进行熔断。


9.jpg


服务管理平台的本质如下图所示,即服务数据平台是控制面板。


10.jpg


服务治理平台实现熔断的逻辑图,图示比较清楚,不再赘述:


11.jpg


在构建服务治理平台时,可以参照现在市面上新型的熔断器框架,例如Resilience4j,会有服务器模式和嵌入模式。前者会有一个独立的 Resilience4j server,后者还是引入jar包。前者性能会好不少。




关键字:
声明:我公司网站部分信息和资讯来自于网络,若涉及版权相关问题请致电(63937922)或在线提交留言告知,我们会第一时间屏蔽删除。
有价值
0% (0)
无价值
0% (10)

分享转发:

发表评论请先登录后发表评论。愿您的每句评论,都能给大家的生活添色彩,带来共鸣,带来思索,带来快乐。