本文给大家讲解的内容是微服务容错与隔离：熔断保护、超时与重试；
熔断保护
断路器（Circuit Breaker）就像保险丝，在电路系统中，一般在所有的家电系统连接外部供电的线路中间都会加一个保险丝，当外部电压过高，达到保险丝的熔点时，保险丝就会被熔断，从而可以切断家电系统与外部电路的联通，进而保障家电系统不会因为电压过高而损坏。
Hystrix提供的熔断器就有类似功能，在一定时间内调用的服务次数达到设定的阈值，并且出错的次数也达到设置的出错阈值时，就会进行服务熔断，让服务调用方执行本地设置的降级策略。但是Hystrix提供的熔断器具有自我反馈、自我恢复的功能，Hystrix会根据调用接口的情况，让熔断器在关闭（closed）、打开（open）、半打开（half-open）三种状态之间自动切换。
● closed→open：正常情况下熔断器为closed状态，当访问同一个接口的次数超过设定阈值并且错误比例超过设置的错误阈值时，就会打开熔断机制，这时候熔断器的状态从closed变为open。
● open→half-open：当服务接口对应的熔断器状态为open时，所有服务调用方调用该服务接口时都执行本地降级方法，Hystrix提供了一种测试策略，也就是设置了一个时间窗口，从熔断器的状态变为open开始的一个时间窗口内，调用该服务接口时都委托服务降级方法执行。如果时间超过了时间窗口，则熔断器的状态从open变为half-open，这个时候熔断器允许定量服务请求。
● half-open→closed：当熔断器的状态为half-open时，如果调用成功达到一定比例，则关闭熔断器，否则熔断器的状态再次变为closed。
超时与重试
在服务容错模式中，超时模式是最常见的容错模式。在实际开发中，有太多的故障是没有设置超时时间导致的服务“Hang住”或者OOM异常，或者是超时时间设置不合理导致的资源无法回收问题，最终导致系统崩溃。这些故障都是因为没有意识到超时设置的重要性而造成的。
超时场景
● 代理层超时与重试：Haproxy、Nginx、Twemproxy组件可实现代理功能，如Haproxy和Nginx可以实现请求的负载均衡，Twemproxy可以实现Redis的分片代理。我们需要设置代理与后端真实服务器之间的网络连接和读写超时时间。
● Web容器超时：Tomcat、Jetty等提供HTTP服务运行环境，我们需要设置客户端与容器之间的网络连接和读写超时时间，以及在此容器中默认的Socket网络连接和读写超时时间。
● 中间件客户端超时与重试：如消息中间件、CXF、Httpclient等，我们需要设置客户的网络连接和读写超时时间，以及失败重试机制。
● 数据库客户端超时：如MySQL、Oracle，需要分别设置JDBCConnection、Statement的网络连接和读写超时时间、事务超时时间、获取连接池连接等待时间。
● 业务超时：如超时订单取消任务、超时活动关闭，以及通过Future＃get（timeout，unit）限制某个接口的超时时间。
● 前端Ajax超时：浏览器通过Ajax访问网络时的网络连接和读写超时时间。
重试机制
重试是伴随着超时的，常见于因网络不稳定导致的服务调用超时场景。重试策略的参数设定一般需要与超时时间设置结合，要考虑接口的响应时间。立刻重试可能不是太好的策略，因为这样会导致在网络抖动的情况下对依赖服务的大量重试请求风暴；太长时间后再重试，会占用资源，失去重试机制的容错价值。在集群下，需要考虑对下游服务集群的同一个服务实例的重试次数与切换其他服务实例进行重试次数的比例，通常建议原有机器负载过高而响应延迟时，可以切换到集群中的其他服务实例，这样更快返回响应的概率会更大一点。
幂等
所谓幂等就是多次执行操作所产生的影响与一次执行的影响相同。
在允许重试的场景中，我们需要保证服务提供方能够实现业务逻辑的幂等，因为重试机制可能导致服务提供方被多次调用。幂等设计需要解决的是“写重试”的问题。
本文给大家讲解的内容是微服务容错与隔离：熔断保护、超时与重试
-
下篇文章给大家讲解的内容是微服务容错与隔离：SpringCloudHystrix容错框架
-
觉得文章不错的朋友可以转发此文关注小编；
-
感谢大家的支持！
