在使用了微服务架构以后，整体的业务流程被拆分成小的微服务，并组合在一起对外提供服务，微服务之间使用轻量级的网络协议通信，通常是RESTful风格的远程调用。由于服务与服务的调用不再是进程内的调用，而是通过网络进行的远程调用，众所周知，网络通信是不稳定、不可靠的，一个服务依赖的服务可能出错、超时或者宕机，如果没有及时发现和隔离问题，或者在设计中没有考虑如何应对这样的问题，那么很可能在短时间内服务的线程池中的线程被用满、资源耗尽，导致出现雪崩效应。本节针对微服务架构中可能遇到的这些问题，讲解应该采取哪些措施和方案来解决。
1. 舱壁隔离模式
这里用航船的设计比喻舱壁隔离模式，若一艘航船遇到了意外事故，其中一个船舱进了水，则我们希望这个船舱和其他船舱是隔离的，希望其他船舱可以不进水，不受影响。在微服务架构中，这主要体现在如下两个方面。
1）微服务容器分组
笔者所在的支付平台应用了微服务，将微服务的每个节点的服务池分为三组：准生产环境、灰度环境和生产环境。准生产环境供内侧使用；灰度环境会跑一些普通商户的流量；大部分生产流量和VIP商户的流量则跑在生产环境中。这样，在一次比较大的重构过程中，我们就可以充分利用灰度环境的隔离性进行预验证，用普通商户的流量验证重构没有问题后，再上生产环境。
另外一个案例是一些社交平台将名人的自媒体流量全部路由到服务的核心池子中，而将普通用户的流量路由到另外一个服务池子中，有效隔离了普通用户和重要用户的负载。
其服务分组如下图所示。
2）线程池隔离
在微服务架构实施的过程中，我们不一定将每个服务拆分到微小的力度，这取决于职能团队和财务的状况，我们一般会将同一类功能划分在一个微服务中，尽量避免微服务过细而导致成本增加，适可而止。
这样就会导致多个功能混合部署在一个微服务实例中，这些微服务的不同功能通常使用同一个线程池，导致一个功能流量增加时耗尽线程池的线程，而阻塞其他功能的服务。
线程池隔离如下图所示。
2. 熔断模式
可以用家里的电路保险开关来比喻熔断模式，如果家里的用电量过大，则电路保险开关就会自动跳闸，这时需要人工找到用电量过大的电器来解决问题，然后打开电路保险开关。在这个过程中，电路保险开关起到保护整个家庭电路系统的作用。
对于微服务系统也一样，当服务的输入负载迅速增加时，如果没有有效的措施对负载进行熔断，则会使服务迅速被压垮，服务被压垮会导致依赖的服务都被压垮，出现雪崩效应，因此，可通过模拟家庭的电路保险开关，在微服务架构中实现熔断模式。
微服务化的熔断模式的状态流转如下图所示。
转载博客：https://blog.csdn.net/kwame211/article/details/78015601