服务降级设计与实践
服务降级定义
当服务整体负载超出预设的上限阈值或即将到来的流量顶,即将会超过预设阈值时,为了保证重要或基本的服务能正常运行,拒绝部分请求或者将一些不重要,[断句]不紧急的服务或任务,[断句]进行服务的延迟使用或暂停使用;
--理解了好长时间才,发现是断句的--
服务降级的目的
当流量高峰期时,在短时间请求量逐渐增大,因为服务的能力有限,导致性能下降,最终出现服务的宕机或者雪崩,所以需要服务降级
--就是要对一些请求拒绝--
服务降级案例
在案例中可以看到,应该是在类似双十一,618等节日,网络流量瞬间上涨,超越预设的阈值,为了保证支付服务等其他重要服务,一些其他不是很重要的服务就都出现了降级,提示拥挤,人多请重试,这就是服务降级,当然不建议提示网络不好用,会被投诉的[捂脸]
服务降级目标
保证核心服务可用;非核心服务弱可用,甚至不可用
- 核心服务:直接和钱沾边,或者间接和钱沾边
- 比如搜索列表,在去支付的路上
- 加入购物车,代表要买了
- 支付,已经准备掏钱了
- 非核心服务:和钱不沾边,或者影响支付
- 我的订单:已经下完单了,不用看
- 退货服务:取消是不可能的
服务降级手段
- 拒绝部分请求
- 拒绝部分老请求
- 减轻微服务请求处理数量
- 确保"新"请求正常响应
- RPC队列方式(请求入队,出队时间处理请求时,检查请求在队列请求时间超过一定时间[比如1秒],直接丢弃)
- --感觉就是消息队列,在队列中超过1秒,还没被消费,直接丢弃--
- 优先级请求方式
- 非核心请求直接丢弃
- 业务紧密
- 随机拒绝方式
- 随机丢弃一定比例的请求
- 网站一会可用,一会不可用
- 关闭部分业务(业务相关)
第一种拒绝部分老的请求是开启机制,第二种优先级是丢弃策略,可以现在网关直接丢弃不是核心请求的请求,然后通过队列记录写入和处理时间获取,在队列中停留的时间,判断是否超出设置的阈值,如果超出直接丢弃
服务层降级架构层次
- 集中式
- 网关层
- 自治式
- 网关层
- 业务逻辑层
- 数据访问层
水平分层架构
因为不同的层次的同样设备的处理能力是不一样的,假设网关层能处理200请求,业务逻辑层只能处理100请求,数据访问层,只能处理50请求
集中式:
直接在网关层砍掉150请求才能符合数据访问层的请求能力,并且是中间隔着业务逻辑层的,并不好知道
自治式:
层层降级,最终砍到数据访问层能处理的请求数量,因为每层都是挨着的所以,容易一些
数据层降级
- 更新请求
- 持久到消息队列
- 只更新缓存
- 读请求
- 读缓存
- 数据补齐
- 消息队列->数据库
新浪微博,在数据流量的高峰期,比如网红发段子,或者一些事件,那么更新的消息数据会写到队列中并写入缓存,其他人拉取的时候,都是读取的缓存,等到流量陷入低峰期时,读取消息队列,并写入到数据库,实现数据补齐
**一般不是用**
服务降级可用策略
自动打开:不依赖人工
演练:保证线上生效
睡觉觉了...
posted on 2021-03-30 11:51 彼岸舞 阅读(126) 评论(0) 编辑 收藏标签：降级,服务,请求,丢弃,队列,实践,--,设计 来源： https://blog.51cto.com/u_15196075/2765583
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。