概述本篇我们来聊聊在微服务架构下如何保证整个系统的高可用？消除一些基础设施故障，例如Redis集群故障、Elasticsearch集群故障和MySQL宕机。微服务架构本身保证高可用最核心的措施有两点：一是基于Hystrix做资源隔离熔断；另一种是做备份降级方案。如果资源隔离和降级做的好，那么在双十一这样的高并发场景下，可能会出现个别服务故障，但绝不会波及到整个系统宕机。业务场景介绍我们先来回顾下这张图，就是上篇文章提到的某公司的系统。如上图，核心服务A调用核心服务B和C，当核心服务B响应太慢时，核心服务A的某个线程池就会全部卡住。但是此时，因为你已经使用hystrix做了资源隔离，所以核心服务A可以正常调用服务C，那么你就可以保证用户至少可以使用APP的部分功能，但是不能刷到服务B关联的页面。出来了，功能不能用了。当然，这种情况在生产系统中是绝对不允许的，所以请不要让上述情况发生。在上一篇文章中，我们最终优化了如下图所示的系统：我们必须保证一个hystrix线程池能够轻松处理每秒的请求。同时有合理的超时设置，防止请求过慢时线程卡死。线上经验——如何设置Hystrix线程池的大小就好了，现在的问题是，在生产环境中，我们应该如何设置服务中每个Hystrix线程池的大小呢？下面是我们在线大量系统优化后的生产经验总结：假设你的服务A每秒会收到30个请求，同时会向服务B发起30个请求，然后每个请求的响应时间经验值request大概200ms，那么你的hystrix线程池需要多少个线程呢？计算公式为：30（每秒请求数）*0.2（每个请求处理秒数）+4（给定点缓冲区）=10（线程数）。如果你对上面的公式有疑惑，不妨反过来算一下。为什么10个线程可以轻松抵抗每秒30个请求？一个线程可以在200毫秒内执行一个请求，那么一个线程可以在1秒内执行5个请求。理论上只需要6个线程就可以每秒执行30个请求。也就是说，线程中的10个线程中，只需要6个线程就足以抵抗每秒30个请求。剩下的4个线程正在播放和空闲。那为什么还要多搞4个线程呢？很简单，因为需要留一点缓冲空间。如果在系统高峰期系统性能略有下降，很多请求需要300多毫秒才能执行，那么1个线程每秒只能处理3个请求，10个线程每秒只能勉强扛下30个请求。因此，您必须多考虑一些线程。老规矩，这里放一张图让大家直观感受整个过程。线上经验——如何设置请求超时时间线程数没问题，那么请求超时时间是多少？答案是300毫秒。为什么？很简单，如果你的超时设置为500毫秒，想想可能的后果？考虑极端情况，如果服务B响应慢，需要500毫秒才能响应，那么你每个线程每秒最多只能处理2个请求，10个线程只能处理20个请求。而每秒有30个请求，会发生什么？我们回过头来看第一张图，大量的线程都会被卡住，来不及处理这么多请求，最终用户无法浏览页面。还是不明白？再给大家一张图，让大家感受下这种不合理的超时带来的问题！如果你的线程池大小和超时时间设置不当，很可能会引起服务B的短期性能波动，导致服务A的线程池瞬间卡死，里面的线程会卡住一段时间在继续执行下一个之前的时间。问。即使一段时间后服务B的接口性能恢复到200毫秒以内，服务A的线程池中的卡死状态也需要一段时间才能恢复。你的超时设置越不合理，比如，设置为1秒或2秒的时间越长，从这种卡住情况中恢复所需的时间就越长。所以这个时候你的超时时间必须设置为300毫秒，保证一个请求不能在300毫秒内执行，超时后马上返回。这样线程池中的线程就不会长时间卡住，多出的请求也可以有序的处理。大不了的是如果不能在300毫秒内完成处理，超时后会立即返回，但线程会一直保持运行状态。这样，当服务B的接口性能恢复到200毫秒以内时，服务A的线程池中的线程就可以快速恢复。这是生产系统上的hystrix参数设置优化经验。您需要考虑应如何设置各种参数。否则，很有可能会出现上述情况。使用高端的SpringCloud架构，结果和黑盒子一样，莫名其妙的系统故障，各种卡顿，宕机等等。好的，让我们继续。如果系统现在每秒有6000个请求，核心服务A一共部署了60台机器，每台机器每秒会收到100个请求，此时你的线程池需要多少个线程？很简单，10个线程抗30个请求，30个线程抗100个请求，差不多。这时候你应该知道服务A的线程池调用服务B的线程池分配了多少个线程吧？您还应该知道如何设置超时时间！其实这个东西不是固定的，只是你需要知道它的计算方法。根据服务的响应时间，系统的峰值QPS，还有多少台机器，计算出线程池的大小和超时时间！服务降级设置完这些之后，你就要考虑服务降级了。如果你的某个服务挂掉了，你的hystrix就会过熔断，然后就降级了。您需要考虑每个服务的降级逻辑。举几个常见的例子：如果查询数据的服务宕机了，可以查看本地缓存。如果写数据的服务挂了，可以先把写操作记录到mysql之类的日志里，或者写到MQ里面，以后慢慢恢复。如果redis挂了，可以查看mysql。如果mysql挂了，可以把操作日志记录在es中，以后慢慢恢复数据。具体采用何种降级策略取决于业务，并不是一成不变的。总结最后总结一下，要消除那些基础设施故障，如果你想玩转微服务架构，你需要保证两点：第一，你必须为你的hystrix资源隔离和超时设置合理的参数，避免高峰期和频繁hystrix线程卡住了。其次，针对个别服务故障，需要设置合理的降级策略，保证每一个服务都能合理降级，系统整体可用！
