本文来源:石杉的架构笔记(shishan100)


目录

一、概述

二、业务场景介绍

三、线上经验 _ 如何设置Hystrix线程池大小

四、线上经验 _ 如何设置请求超时时间

五、服务降级

六、总结

一、概述

上一篇文章讲了一个朋友公司使用Spring Cloud架构遇到问题的一个真实案例,虽然不是什么大的技术问题,但如果对一些东西理解的不深刻,还真会犯一些错误。

如果没看过上一篇文章的朋友,建议先看看:《微服务注册中心如何承载大型系统的千万级访问?》 因为本文的案例背景会基于上一篇文章。

这篇文章我们来聊聊在微服务架构中,到底如何保证整套系统的高可用?

排除掉一些基础设施的故障,比如说Redis集群挂了,Elasticsearch集群故障了,MySQL宕机。

微服务架构本身最最核心的保障高可用的措施,就是两点:

  1. 一个是基于Hystrix做资源隔离以及熔断;

  2. 另一个是做备用降级方案。

如果资源隔离和降级都做的很完善,那么在双11这种高并发场景下,也许可能会出现个别的服务故障,但是绝不会蔓延到整个系统全部宕机。

二、业务场景介绍

大家首先回顾一下下面这张图,这是上篇文章中说到的一个公司的系统。

如上图,核心服务A调用了核心服务B和C,在核心服务B响应过慢时,会导致核心服务A的某个线程池全部卡死。

但是此时因为你用了hystrix做了资源隔离,所以核心服务A是可以正常调用服务C的,那么就可以保证用户起码是可以使用APP的部分功能的,只不过跟服务B关联的页面刷不出来,功能无法使用罢了。

当然这种情况在生产系统中,是绝对不被允许的,所以大家不要让上述情况发生。

在上一篇文章中,我们最终把系统优化成了下图这样:

  • 要保证一个hystrix线程池可以轻松处理每秒钟的请求

  • 同时还有合理的超时时间设置,避免请求太慢卡死线程。

三、线上经验—如何设置Hystrix线程池大小

好,现在问题来了,在生产环境中,我们到底应该如何设置服务中每个hystrix线程池的大小?

下面是我们在线上经过了大量系统优化后的生产经验总结:

假设你的服务A,每秒钟会接收30个请求,同时会向服务B发起30个请求,然后每个请求的响应时长经验值大概在200ms,那么你的hystrix线程池需要多少个线程呢?

计算公式是:30(每秒请求数量) * 0.2(每个请求的处理秒数) + 4(给点缓冲buffer) = 10(线程数量)。

如果对上述公式存在疑问,不妨反过来推算一下,为什么10个线程可以轻松抗住每秒30个请求?

一个线程200毫秒可以执行完一个请求,那么一个线程1秒可以执行5个请求,理论上,只要6个线程,每秒就可以执行30个请求。

也就是说,线程里的10个线程中,就6个线程足以抗住每秒30个请求了。剩下4个线程都在玩儿,空闲着。

那为啥要多搞4个线程呢?很简单,因为你要留一点buffer空间。

万一在系统高峰期,系统性能略有下降,此时不少请求都耗费了300多毫秒才执行完,那么一个线程每秒只能处理3个请求了,10个线程刚刚好勉强可以hold住每秒30个请求。所以你必须多考虑留几个线程。

老规矩,给大家来一张图,直观的感受一下整个过程。

四、线上经验—如何设置请求超时时间

线程数量OK了,那么请求的超时时间设置为多少?答案是300毫秒。

为啥呢?很简单啊,如果你的超时时间设置成了500毫秒,想想可能会有什么后果?

考虑极端情况,如果服务B响应变慢,要500毫秒才响应,你一个线程每秒最多只能处理2个请求了,10个线程只能处理20个请求。

而每秒是30个请求过来,结局会如何?

咱们回看一下第一张图就知道了,大量的线程会全部卡死,来不及处理那么多请求,最后用户会刷不出来页面。

还是有点不理解?再给你一张图,让你感受一下这个不合理的超时时间导致的问题!

如果你的线程池大小和超时时间没有配合着设置好,很可能会导致服务B短暂的性能波动,瞬间导致服务A的线程池卡死,里面的线程要卡顿一段时间才能继续执行下一个请求。

哪怕一段时间后,服务B的接口性能恢复到200毫秒以内了,服务A的线程池里卡死的状况也要好一会儿才能恢复过来。

你的超时时间设置的越不合理,比如设置的越长,设置到了1秒、2秒,那么这种卡死的情况就需要越长的时间来恢复。

所以说,此时你的超时时间得设置成300毫秒,保证一个请求300毫秒内执行不完,立马超时返回。

这样线程池里的线程不会长时间卡死,可以有条不紊的处理多出来的请求,大不了就是300毫秒内处理不完立即超时返回,但是线程始终保持可以运行的状态。

这样当服务B的接口性能恢复到200毫秒以内后,服务A的线程池里的线程很快就可以恢复。

这就是生产系统上的hystrix参数设置优化经验,你需要考虑到各种参数应该如何设置。

否则的话,很可能会出现上文那样的情况,用了高大上的Spring Cloud架构,结果跟黑盒子一样,莫名其妙系统故障,各种卡死,宕机什么的。

好了,我们继续。如果现在这套系统每秒有6000请求,然后核心服务A一共部署了60台机器,每台机器就是每秒会收到100个请求,那么此时你的线程池需要多少个线程?

很简单,10个线程抗30个请求,30个线程抗100请求,差不多了吧。

这个时候,你应该知道服务A的线程池调用服务B的线程池分配多少线程了吧?超时时间如何设置应该也知道了!

其实这个东西不是固定死的,但是你要知道他的计算方法。

根据服务的响应时间、系统高峰QPS、有多少台机器,来计算出来,线程池的大小以及超时时间!

五、服务降级

设置完这些后,就应该要考虑服务降级的事了。

如果你的某个服务挂了,那么你的hystrix会走熔断器,然后就会降级,你需要考虑到各个服务的降级逻辑。

举一些常见的例子:

  • 如果查询数据的服务挂了,你可以查本地的缓存

  • 如果写入数据的服务挂了,你可以先把这个写入操作记录日志到比如mysql里,或者写入MQ里,后面再慢慢恢复

  • 如果redis挂了,你可以查mysql

  • 如果mysql挂了,你可以把操作日志记录到es里去,后面再慢慢恢复数据。

具体用什么降级策略,要根据业务来定,不是一成不变的。

六、总结

最后总结一下,排除那些基础设施的故障,你要玩儿微服务架构的话,需要保证两点:

  • 首先你的hystrix资源隔离以及超时这块,必须设置合理的参数,避免高峰期,频繁的hystrix线程卡死

  • 其次,针对个别的服务故障,要设置合理的降级策略,保证各个服务挂了,可以合理的降级,系统整体可用!

作者:中华石杉,十余年BAT架构经验倾囊相授。个人微信公众号:石杉的架构笔记(ID:shishan100)

-END-

 近期热文:

  • Spring Cloud Stream如何消费自己生产的消息?

  • 微服务注册中心如何承载大型系统的千万级访问?

  • Spring Cloud Stream如何处理消息重复消费?

  • 最近项目重构的一些感想

  • Logback中使用TurboFilter实现日志级别等内容的动态修改

  • 为什么前后端分离了,你比从前更痛苦?

  • 不改一行代码定位线上性能问题

关注我

点击“阅读原文”,看本号其他精彩内容

微服务架构如何保障双11狂欢下的99.99%高可用?相关推荐

  1. 微服务架构如何保障双11狂欢下的99.99%高可用

    一.概述 上一篇文章讲了一个朋友公司使用Spring Cloud架构遇到问题的一个真实案例,虽然不是什么大的技术问题,但如果对一些东西理解的不深刻,还真会犯一些错误. 如果没看过上一篇文章的朋友,建议 ...

  2. SpringCloud Alibaba 微服务架构(十五)- 一文详解 Nacos 高可用特性

    前言 服务注册发现是一个经久不衰的话题,Dubbo 早期开源时默认的注册中心 Zookeeper 最早进入人们的视线,并且在很长一段时间里,人们将注册中心和 Zookeeper 划上了等号,可能 Zo ...

  3. 技术分享:从双11看实时数仓Hologres高可用设计与实践

    简介:本文将会从阿里巴巴双11场景出发,分析实时数仓面临的高可用挑战以及针对性设计. 2021年阿里巴巴双11完美落下为帷幕,对消费者来说是一场购物盛宴,对背后的业务支撑技术人来说,更是一场年度大考. ...

  4. 从双11看实时数仓Hologres高可用设计与实践

    2021年阿里巴巴双11完美落下为帷幕,对消费者来说是一场购物盛宴,对背后的业务支撑技术人来说,更是一场年度大考.在这场大考中,一站式实时数仓Hologres以每秒11.2亿条的高速写入,和每秒1.1 ...

  5. 微服务架构-系统可靠性保障

    1.可靠性 可靠性(Reliability)是指微服务系统在面对异常情况时,如关键组件损坏.流量或数据量异常.延迟波动.级联故障传导.分布式集群雪崩.系统过载等等,能够持续保持稳定运行或快速恢复的能力 ...

  6. Spring Cloud Alibaba微服务架构实战教程—17分布式缓存下Redis设计

    前言 大多数的文章,开头就是告诉你使用redis做缓存,怎么怎么样,而本系列,不打算采用这样无趣的写法,这和直接搬运有什么区别?笔者力求读者能得到更大程度的系统学习,会从为什么使用缓存来给大家进行学习 ...

  7. Java生鲜电商平台-SpringCloud微服务架构高并发参数优化实战

    Java生鲜电商平台-SpringCloud微服务架构高并发参数优化实战 一.写在前面 在Java生鲜电商平台平台中相信不少朋友都在自己公司使用Spring Cloud框架来构建微服务架构,毕竟现在这 ...

  8. 微服务架构系列一:关键技术与原理研究

    导语:人不为己,天诛地灭这个成语中的"为"念作wéi,阳平二声,是"修养,修为"的意思.成语的意思是:如果人不修身,那么就会为天地所不容.本意并不是经常被很多人 ...

  9. 微服务架构深度解析与最佳实践

    微服务架构深度解析与最佳实践 微服务架构的概念,现在对于大家应该都不陌生,无论使用 Apache Dubbo.还是 Spring Cloud,都可以去尝试微服务,把复杂而庞大的业务系统拆分成一些更小粒 ...

最新文章

  1. ping 丢包 网络摄像头_视频监控系统的摄像头掉线看交换机连接注意事项
  2. [lua]判断nginx收到的是否json
  3. 控制工程matlab实验报告小结,控制工程MATLAB实验报告.doc
  4. FPGA 的I/O BANK介绍
  5. 企业网络推广方法浅析如何提高网站的点击率和访问量呢?
  6. uva 816(经典bfs例子)
  7. Spring Cloud Config git版
  8. 全世界关于数学家和科学家的电影
  9. 细分将成为2011手机市场的主旋律
  10. Android NFC开发-实践篇
  11. eclipse导入源码
  12. 技术沙龙 | 深度赋能AI全场景,揭秘你不知道的移动云
  13. android代码设置digits,android:digits属性
  14. 【科普】有趣“小学”数学题,做出一道即可成名(持续补充)
  15. git push或git pull等其他git命令 出现unable to access ‘https://gitee.com/你的git仓库地址)清除网络代理
  16. 高德API实现地理逆编码
  17. 囧囜囟囥圀圄圅圙圝圞
  18. 百度地图移动端https 问题解决记录,也许是这个问题
  19. 导出pdf文件时加图片水印
  20. Java算法_优先队列和PriorityQueue——HDU 1873:看病要排队

热门文章

  1. docker 逃逸 简介
  2. python3 异步错误 asyncio.Semaphore RuntimeError: Task got Future attached to a different loop
  3. python flask 跨域问题 解决方法
  4. 一个程序员的成长的六个阶段(转载)
  5. Linux 内核详解以及内核缓冲区技术
  6. golang-exec cmd data race
  7. python面向对象代码示例
  8. NeHe教程Qt实现——lesson03
  9. openstack代码解读之 neutron.agent.linux.iptables_manager模块
  10. 广东海洋大学微型计算机考试,广东海洋大学2007-2008微型计算机原理及应用