务场景，高并发调用
-
正常情况下，微服务A B C D 都是正常的。
-
随着时间推移，在某一个时间点 微服务A突然挂了，此时的微服务B 还在疯狂的调用微服务A，由于A已经挂了，所以B调用A必须等待服务调用超时。而我们知道每次B -> A 的适合B都会去创建线程(而线程由计算机的资源，比如cpu、内存等)。由于是高并发场景，B 就会阻塞大量的线程。那边B所在的机器就会去创建线程，但是计算机资源是有限的，最后B的服务器就会宕机。(说白了微服务B 活生生的被猪队友微服务A给拖死了)
-
由于微服务A这个猪队友活生生的把微服务B给拖死了，导致微服务B也宕机了，然后也会导致微服务 C D 出现类似的情况，最终我们的猪队友A成功的把微服务 B C D 都拖死了。这种情况也叫做服务雪崩。也有一个专业术语(cascading failures)级联故障。
二、容错三板斧
2.1 超时
简单来说就是超时机制，配置以下超时时间，假如1秒——每次请求在1秒内必须返回，否则到点就把线程掐死，释放资源!
思路：一旦超时，就释放资源。由于释放资源速度较快，应用就不会那么容易被拖死。
代码演示：(针对调用方处理)兴趣可以先了解一下船舱构造——一般来说，现代的轮船都会分很多舱室，舱室直接用钢板焊死，彼此隔离。这样即使有某个/某些船舱进水，也不会营销其它舱室，浮力够，船不会沉。
代码中的舱壁隔离(线程池隔离模式)
M类使用线程池1，N类使用线程池2，彼此的线程池不同，并且为每个类分配的线程池大小，例如 coreSIze=10。
举例子：M类调用B服务，N类调用C服务，如果M类和N类使用相同的线程池，那么如果B服务挂了，N类调用B服务的接口并发又很高，你又没有任何保护措施，你的服务就很可能被M类拖死。而如果M类有自己的线程池，N类也有自己的线程池，如果B服务挂了，M类顶多是将自己的线程池占满，不会影响N类的线程池——于是N类依然能正常工作。
-
思路：不把鸡蛋放在一个篮子里，你有你的线程池，我有我的线程池，你的线程池满类和我也没关系，你挂了也和我也没关系。
-
（编辑：桂林站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
