文章介绍了熔断机制在微服务架构中的作用，以Istio和Hystrix为例进行了对比。Istio作为服务网格提供无侵入的熔断和限流，而Hystrix是Java应用的熔断工具，需要在代码层面集成。Istio的熔断和限流配置在DestinationRule中，包括连接池和异常检测设置，用于防止服务级联故障和控制流量。
istio熔断
熔断主要是无感的处理服务异常并保证不会发生级联甚至雪崩的服务异常。在微服务方面体现是对异常的服务情况进行快速失败，它对已经调用失败的服务不再会继续调用，如果仍需要调用此异常服务，它将立刻返回失败。
与此同时，它一直监控服务的健康状况，一旦服务恢复正常，则立刻恢复对此服务的正常访问。这样的快速失败策略可以降低服务负载压力，很好地保护服务免受高负载的影响。
一个熔断器可以有三种状态：关闭、打开和半开，默认情况下处于关闭状态。在关闭状态下，无论请求成功或失败，到达预先设定的故障数量阈值前，都不会触发熔断。而当达到阈值时，熔断器就会打开。
当调用处于打开状态的服务时，熔断器将断开请求，这意味着它会直接返回一个错误，而不去执行调用。通过在客户端断开下游请求的方式，可以在生产环境中防止级联故障的发生。在经过事先配置的超时时长后，熔断器进入半开状态，这种状态下故障服务有时间从其中断的行为中恢复。如果请求在这种状态下继续失败，则熔断器将再次打开并继续阻断请求。否则熔断器将关闭，服务将被允许再次处理请求
熔断器对比 Hystrix vs Istio
Hystrix是Netflix OSS的一部分，是微服务领域的领先的熔断工具。Hystrix可以被视为白盒监控工具，而Istio可以被视为黑盒监控工具，主要是因为Istio从外部监控系统并且不知道系统内部如何工作。另一方面，每个服务中有Hystrix来获取所需的数据。
Istio是无缝衔接服务，istio可以在不更改应用程序代码的情况下配置和使用。Hystrix的使用需要更改每个服务来引入Hystrix libraries。
Istio提高了网格中服务的可靠性和可用性。但是，应用程序需要处理错误并有一定的fall back行为。例如当负载平衡池中的所有服务实例都出现异常时，Envoy将返回HTTP 503。当上游服务返回 HTTP 503 错误，则应用程序需要采取回退逻辑。与此同时，Hystrix也提供了可靠的fall back实现。它允许拥有所有不同类型的fall backs：单一的默认值、缓存或者去调用其他服务。
envoy对应用程序来说几乎完全无感和透明。Hystrix则必须在每个服务调用中嵌入Hystrix库。
Istio的熔断应用几乎无语言限制，但Hystrix主要针对的是Java应用程序。
Istio是使用了黑盒方式来作为一种代理管理工具。它实现起来很简单，不依赖于底层技术栈，而且可以在部署后也可以进行配置和修改。Hystrix需要在代码级别处理断路器，可以设置级联和一些附加功能，它需要在开发阶段时做出降级决策，后期优化配置成本高。
Istio限流
Istio无需对代码进行任何更改就可以为应用增加熔断和限流功能。Istio中熔断和限流在DestinationRule的CRD资源的TrafficPolicy中设置，一般设置连接池（ConnectionPool）限流方式和异常检测（outlierDetection）熔断方式。
两者ConnectionPool和outlierDetection各自配置部分参数，其中参数有可能存在对方的功能，并没有很严格的区分出来，如主要进行限流设置的ConnectionPool中的maxPendingRequests参数，最大等待请求数，如果超过则也会暂时的熔断。
连接池（ConnectionPool）设置：
ConnectionPool可以对上游服务的并发连接数和请求数进行限制，适用于TCP和HTTP。ConnectionPool又称之是限流。
官方定义的属性
设置在DestinationRule中的配置如下图：
连接池相关参数解析
连接池和异常处理就是配置熔断的一个用法了，
熔断就是我们生活当中所谓的跳闸，
有一天对于d服务来说，负载压力比较大，可能还有其他应用也会调用到d服务。d服务如果出现问题可能是会影响到其他服务的，影响面比较广。
为了防止某一个服务问题带来的使得整个架构都出现问题，那么可以将某个应用切断，那么这样就将d服务隔离开来了。
一些概念
熔断-连接池
熔断的定义是在DR里定义的，主要有2部分
- TCP连接
- http连接
连接池满了，但是可以有一个排队的，等待着处理。
一次性建立了5个连接，一共发送20个请求，
后端的某一个pod被熔断了，它不再对外提供服务了，希望在过一段时间是可以启动起来的。
这个时候就需要去配置异常处理，
937
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
