关于服务的降级和熔断
来源：15-1 服务降级与服务熔断思路-1
qq_loneliness_0
2018-09-04
老师我想问一下，学生没有遇到过真正的高并发场景所以有些疑问，首先有可能我的理解就有问题。tomcat的默认并发量是150，在默认的前提下，是不是说如果有10000个并发过来剩下的就会堵塞等这150个处理完了才能处理剩下的，我在网上学习了用ratelimited进行降级的方案，但是按照这个理解，如果并发一万个线程，那么9000多个线程会堵塞住压根进不来，而用ratelimited去降级的实际是那150个进来的，这样处理的时间还是很长呀？对用户的反馈还是不好。并且我mysql同时接受150个并发是没问题的，java处理150个线程也是没问题的，降级的意义何在？
1回答
-
Jimin
2018-09-04
你好，这个理解确实有点问题，把服务降级想的稍微有点狭隘了。先说你这个场景，假设你只能处理同时处理150个线程，你可以让一部分线程阻塞在哪里，却不能让10000-150个线程阻塞在哪里，首先是用户体验肯定不好，而且很多等待都是白等，因为我们请求接口时本身也有超时时间的，一直等下去是没意义的，还有，线程本身等待也是对cpu和内存有消耗，本来就处理不来的，这样就更不好了。
服务降级和熔断除了能让某些接口尽快返回，更多的保护系统。跳出你这个场景来举例子说说
比如系统需要请求的第三方接口很明显挂了，我们请求已经没任何意义了，这样完全可以不再去调用了，不去浪费宝贵的连接，不去浪费宝贵的连接-处理-返回这段时间，取而代之降级返回一个默认的返回，提前和调用者沟通好，某些返回代表第三方出现问题了，这样一来就可以很平滑的绕过去了，而不是悲观的等待第三方接口恢复。
再比如我们系统数据库都有主从之分，很多请求都可以访问从库获取数据，这样对数据库压力会很小。但是可能会遇到主从延迟同步的时候，这时临时降级为查主库就可以很容易的绕过这个问题了，在开发时注意一下就可以提前预防这个问题了，否则就只能改代码发布处理了。
再举个例子，某个处理总出异常，但又不是特别核心。比如地图上计算距离，有时曲线计算时间太长，导致超时了，这时就可以简单点计算个直线距离乘以个比例进行返回（许多系统实际就是这样做的）。
服务降级和熔断本质上是给系统提供了多种选择，当系统核心希望的处理流程出现问题时，可以换一种可以接受的方式去处理，不至于明知道是错的，还一直继续做。对我们而言，也是预防系统出现特殊问题时，对系统尽可能的保护好。
152018-09-05
相似问题