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

欢迎关注微信公众号：石杉的架构笔记（id：shishan100）

个人新课**《C2C 电商系统微服务架构120天实战训练营》在公众号儒猿技术窝**上线了，感兴趣的同窗，能够点击下方连接了解详情：

《C2C 电商系统微服务架构120天实战训练营》

目录

1、概述

2、业务场景

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

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

5、问题解决

6、总结

1、概述

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

若是没看过这篇的朋友，建议先看看：【双11狂欢的背后】微服务注册中心如何承载大型系统的千万级访问？ 由于本文的案例背景会基于上一篇文章。

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

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

微服务架构本身自己最最核心的保障高可用的措施，就是两个：

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

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

若是资源隔离和降级都作的很完善，那么在好比双11的这种高并发场景下，虽然可能会出现个别的服务故障，可是绝对是不会蔓延到整个系统所有宕机的。

这里你们若是忘了如何基于hystrix作资源隔离、熔断以及降级的话，能够回顾一下文章：《 拜托！面试请不要再问我Spring Cloud底层原理 》

2、业务场景

好的，那咱们这就来深刻的分析一下，在实际生产系统中，hystrix的线程池以及超时时间，这两个参数应该如何根据系统的负载设置到最佳的状态？

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

核心服务A调用了核心服务B和C，在核心服务B响应过慢时，会致使核心服务A的某个线程池所有卡死。

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

固然这种状况在生产系统中，是绝对不被容许的，因此你们千万让上述状况发生。

在上一篇文章中，咱们最终把系统优化成了下图这样，要保证一个hystrix线程池能够轻松处理每秒钟的请求，同时还有合理的超时时间设置，避免请求太慢卡死线程。

3、线上经验—如何设置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个请求。因此你必须多考虑留几个线程。

老规矩，给你们来一张图，直观的感觉一下。

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

接着来，那么请求的超时时间设置为多少？答案是300毫秒。

为啥呢？很简单啊，兄弟！若是你的超时时间设置成了500毫秒，想一想可能会有什么后果？

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

而每秒是30个请求过来，结局会如何？我们回看一下第一张图就知道了，大量的线程会所有卡死，来不及处理那么多请求，最后用户会刷不出来页面。

仍是有点不理解？再给你一张图，让你感觉一下这个不合理的超时时间致使的问题！

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

哪怕服务B的接口性能恢复到200毫秒之内了，服务A的线程池里卡死的情况也要好一下子才能恢复过来。你的超时时间不合理的设置的越长，好比设置1秒、2秒，那么这种卡死的状况就须要越长的时间来恢复。

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

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

这样当服务B的接口性能恢复到200毫秒之内了，服务A的线程池里的线程很快就能够恢复。

这就是生产系统上的hystrix参数设置优化经验，你必须考虑到各类参数应该如何设置。

不然的话，极可能会出现上文那样的状况，用了高大上的Spring Cloud，结果跟黑盒子同样，莫名其妙系统故障，各类卡死，宕机什么的。

5、问题解决

好了，咱们继续。若是如今这套系统每秒有6000请求，而后核心服务A一共部署了60台机器，每台机器就是每秒会收到100个请求，那么此时你的线程池须要多少个线程？

很简单了，10个线程抗30个请求，30个线程抗100请求，差很少了吧。

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

其实这个东西不是固定死的，可是你要知道他的计算方法，根据服务的响应时间、系统高峰QPS、有多少台机器，来计算出来，线程池的大小以及超时时间！

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

若是你的某个服务挂了，那么你的hystrix会走熔断器，而后就会降级，你须要考虑到各个服务的降级逻辑。

举一些常见的例子：

• 若是查询数据的服务挂了，你能够查本地的缓存

• 若是写入数据的服务挂了，你能够先把这个写入操做记录日志到好比mysql里，或者写入MQ里，后面再慢慢恢复

• 若是redis挂了，你能够查mysql

• 若是mysql挂了，你能够把操做日志记录到es里去，后面再慢慢恢复数据。

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

6、总结

总结一下，排除那些基础设施的故障，你要玩儿微服务架构的话，须要保证两点：

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

2. 其次，针对个别的服务故障，要设置合理的降级策略，保证各个服务挂了，能够合理的降级，系统总体可用！

若有收获，请帮忙转发，您的鼓励是做者最大的动力，谢谢！

一大波微服务、分布式、高并发、高可用的原创系列文章正在路上：

****《兄弟，用大白话告诉你小白都能看懂的Hadoop架构原理》**，**敬请期待

****《大规模集群下Hadoop的NameNode如何承载高并发访问》**，**敬请期待

欢迎扫描下方二维码，持续关注：


石杉的架构笔记（id:shishan100）

十余年BAT架构经验倾囊相授