网关之降级、熔断、限流、隔离、幂等性验证的相关知识简单整理

作者: admin 分类: 规则原理 发布时间: 2019-06-12 00:07  阅读: 161 views

假程序猿之前做了个网关项目,介绍地址如下:

WormHole是一个简单、易用的api管理平台,支持dubbo服务调用

做之前有整理了一些资料或信息。可能不太完全,这里记录回顾下。

 

制作网关项目的好处:

(1)网关层对外部和内部进行了隔离,保障了后台服务的安全性。
(2)对外访问控制由网络层面转换成了运维层面,减少变更的流程和错误成本
(3)减少客户端与服务的耦合,服务可以独立发展。通过网关层来做映射。
(4)通过网关层聚合,减少外部访问的频次,提升访问效率。
(5)节约后端服务开发成本,减少上线风险。
(6)为服务熔断,灰度发布,线上测试提供简单方案。
(7)便于扩展。

从接口安全方面说,它时属于微服务架构的基本功能。微服务架构的特点就是:“一解释就懂,一问就不知,一讨论就吵架”,对于我这个学艺不精的人来说,估计问什么都会吵架。

 

1. 应用场景

假设服务A依赖服务B和服务C,而B服务和C服务有可能继续依赖其他的服务,继续下去会使得调用链路过长,技术上称1->N扇出。如果在A的链路上某个或几个被调用的子服务不可用或延迟较高,则会导致调用A服务的请求被堵住,堵住的请求会消耗占用掉系统的线程、io等资源,当该类请求越来越多,占用的计算机资源越来越多的时候,会导致系统瓶颈出现,造成其他的请求同样不可用,最终导致业务系统崩溃,又称:雪崩效应。

 

2.处理方式

降级:在服务器压力剧增的情况下,根据实际业务情况和流量,对一些服务和页面不处理或简单处理,从而释放服务器资源保证核心交易正常运作。
熔断:熔断一般是指软件系统中,由于某些原因使得服务出现了过载现象,为防止造成整个系统故障,从而采用的一种保护措施,所以很多地方把熔断亦称为过载保护。
限流:限制服务/接口访问的流量。可以从总量+速率进行处理
隔离:保证其中某个服务坏掉,不会影响到其他服务。线程池/信号量隔离模式
幂等性验证: 可能因为网络抖动或其他位置原因,服务端在短时间内可能会受到多笔相同的交易
超时机制:一种是请求的等待超时,一种是请求运行超时。

其中,降级、熔断、隔离属于出现问题后的处理机制。限流属于预防。

 

a. 降级处理

服务降级模式:屏蔽降级【直接关闭相关服务】、容错降级【根据异常进行返回处理】、业务降级【业务调整】、非降级【其他】;
服务降级措施:返回NULL、抛出指定异常、调用本地MOCK服务、自定义降级策略。


容错处理:DUBBO的容错策略
相关连接:http://dubbo.apache.org/zh-cn/docs/user/demos/fault-tolerent-strategy.html

 

b.熔断处理

状态划分如下:

1. Closed:熔断器关闭状态,调用失败次数积累,到了阈值(或一定比例)则启动熔断机制;
2. Open:熔断器打开状态,此时对下游的调用都内部直接返回错误,不走网络,但设计了一个时钟选项,默认的时钟达到了一定时间(这个时间一般设置成平均故障处理时间,也就是MTTR),到了这个时间,进入半熔断状态;
3. Half-Open:半熔断状态,允许定量的服务请求,如果调用都成功(或一定比例)则认为恢复了,关闭熔断器,否则认为还没好,又回到熔断器打开状态;

示例场景:

引用Hystrix官方的一个例子,假设tomcat对外提供的一个application,其内部依赖了30个服务,每个服务的可用性都很高,为99.99%。那整个applicatiion的可用性就是:99.99%的30次方 = 99.7%,即0.3%的失败率。
这也就意味着,每1亿个请求,有30万个失败;按时间来算,就是每个月的故障时间超过2小时。
假设一个请求的调用链上面有10个服务,只要这10个服务中有1个超时,就会导致这个请求超时。 
更严重的,如果该请求的并发数很高,所有该请求在短时间内都被block(等待超时),tomcat的所有线程都block在此请求上,导致其他请求没办法及时响应。

熔断参考地址:https://opentalk.upyun.com/335.html

 

c. 限流处理

zuul组件默认是存储在内存中的,通过concurrentHashMap实现,也可以通过redis、consul【google开源go语言开发的服务】、spring Data JPA存储

 

限流过滤器是在请求被转发之前调用的,一般类型有三种包括

限流类型
粒度
说明
url
根据请求路径区分
origin
genuine客户端IP地址区分
user
根据用户授权区分

限流的算法可以有以下几种算法但是不限于

限流算法
说明
特点
令牌通限流
令牌桶是一个存放固定容量令牌的桶,按照固定速率往桶里添加令牌,填满了就丢弃令牌,请求是否被处理要看桶中令牌是否足够,当令牌数减为零时则拒绝新的请求。令牌桶允许一定程度突发流量,只要有令牌就可以处理,支持一次拿多个令牌。令牌桶中装的是令牌。semaphore实现
令牌桶算法针对的是限制“速率“
漏桶限流
漏桶一个固定容量的漏桶,按照固定常量速率流出请求,流入请求速率任意,当流入的请求数累积到漏桶容量时,则新流入的请求被拒绝。漏桶可以看做是一个具有固定容量、固定流出速率的队列,漏桶限制的是请求的流出速率。漏桶中装的是请求。
计数器限流
有时我们还会使用计数器来进行限流,主要用来限制一定时间内的总并发数,比如数据库连接池、线程池、秒杀的并发数;计数器限流只要一定时间内的总请求数超过设定的阀值则进行限流,是一种简单粗暴的总数量限流,而不是平均速率限流。
针对的是时间内的并发总数
漏桶算法

漏桶算法

 

令牌算法

令牌算法

漏桶算法+令牌算法参考

https://blog.csdn.net/charleslei/article/details/53152883

Google开源工具包Guava提供了限流工具类RateLimiter,该类基于令牌桶算法实现流量限制

计数器算法参考

http://www.360doc.com/content/18/0222/08/10346540_731371833.shtml

 

d.超时处理

1. 等待超时:在任务入队列时设置任务入队列时间,并判断队头的任务入队列时间是否大于超时时间,超过则丢弃任务。

2. 运行超时:直接可使用线程池提供的get方法

可以使用Future类判断运行时长等。

 

e.接口监控

针对于访问时间长、响应慢的接口进行监控
可以分析接口效率,压力值等

//
可以使用zabbix,skywalking等监控

1.Zabbix主要功能:
 CPU负荷,内存使用,磁盘使用, 网络状况, 端口监视, 日志监视

2.skywalking可以监控整个业务调用链路,对于开发、性能提升来说用处更大

 

 

搜索结果比较多的网关插件除了Hystrix,还有阿里开源的神器  sentinel也很好用,传送门【网关流量控制使用阿里流量哨兵神器sentinel控制台实践验证过程】

 

其他设计参考:

http://developer.51cto.com/art/201711/557049.htm 京东网关
https://tech.youzan.com/api-gateway-in-practice/ 有赞网关

 


   原创文章,转载请标明本文链接: 网关之降级、熔断、限流、隔离、幂等性验证的相关知识简单整理

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!

发表评论

电子邮件地址不会被公开。 必填项已用*标注

更多阅读