拥有复杂的分布式架构的应用程序有很多的依赖，都会不可避免地在某些时候失败。高并发的依赖失败时如果没有隔离措施，当前应用服务就有被拖垮的风险。
例如：一个依赖30个微服务的系统，每个服务99.99%可用。99.99%的30次方≈99.7%，0.3%意味着一亿次请求会有3 000 00次失败。如果换算成时间，大约每月有2个小时服务不稳定。而且随着服务依赖数量变多，服务不稳定的概率会成指数性升高。
解决这一问题的方案是对依赖做隔离，对依赖服务做出熔断。熔断这一概念来源于电子工程中的断路器。在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。这种牺牲局部保全整体的措施就称为熔断。
针对这些问题，Istio提供了一种非常实用且经过良好测试的熔断模式，实现了三个状态机：Closed、Half-Open、Open，如图6-3所示。
图6-3 Istio的熔断模式
·熔断关闭状态（Closed）：对应用程序的请求能够直接引起方法的调用。代理类维护了最近调用失败的次数，如果某次调用失败，则使失败次数加1。如果最近失败次数超过了在给定时间内允许失败的阈值，则代理类切换到断开（Open）状态。此时代理开启了一个超时时钟，当该时钟超过了该时间，则切换到半断开（Half-Open）。
·半熔断状态（Half-Open）：该超时时间的设定是给了系统一次机会来修正导致调用失败的错误。半熔断状态允许定量的服务请求，如果调用都成功（或一定比例成功）则认为恢复了，进入熔断关闭状态；否则认为还没好，又回到熔断开启状态。
·熔断开启状态（Open）：在该状态下，对应用程序的请求会立即返回错误响应。处于该状态时，对下游的调用都直接返回错误，但同时启用了一个时钟，默认的时钟达到了一定时间（这个时间一般设置成平均故障处理时间，也就是MTTR），就会进入半熔断状态。