超时

在接口调用的过程中，乙方调用甲方的接口时，provider在响应的时候，可能会慢，如果provider在10秒之内没有反应，consumer就会至少10秒才响应。假如说这种情况发生的非常频繁，就会整体降低乙方端的性能。而且在这过程中，是一个又一个的响应来构成，造成的是整体链路的超时。所以乙方那边，可能不能一直等着甲方这边的响应接口的返回，总不能在一棵树上吊死啊是不是，这个时候就会需要一个时间阈值，设定最大等待时间，之后就不继续等待了。这个时间的的选取，一般根据正常的provider的响应时间来看,追加Buffer即可。

重试

超时时间的配置是为了保护服务，为了避免consumer因为provider响应慢而导致整体的响应速度很慢，这样就能使consumer尽可能的保持原有的性能。

有时也可能是provider偶尔抖动，皮一下，那么超时之后就直接放弃了，会导致当前的请求错误，可能也会带来业务方面的损失。对于这种偶尔的抖动呢，我们也是可以在超时后重试一下，假如说这次重试正常返回了，就当这次请求挽救了，能够正常的给前端发送数据，只不过肯定在速率上慢了一些。

重试时呢，最好还是换一台机器来进行调用，因为原来的机器可能因为临时的负载高而性能下降，重试会加剧性能问题，换一台机器，得到更快返回的概率也相对大一些。

幂等

幂等指的是，假如consumer多次调用了同一个请求，对provider所产生的影响也是一致的。如果允许consumer重试，provider就要做到能够幂等。而且这个幂等应该是服务级别的，而不是某台服务级别，足够调用任何一台其他机器，并且都要做到幂等。

熔断

重试是为了应对偶尔出现的抖动情况，挽回更多的损失

但是如果provider持续响应时间超长呢？

如果provider是核心路径的服务，宕掉就基本没办法再提供服务了。那也就实在没办法。如果是一个不太重要的服务，却因为持续响应时间过长导致consumer中的核心服务也被拖慢节奏，这样就有些得不偿失了。

单纯的超时也解决不了这种情况，因为一般超时时间，肯定比平均响应时间是要长一些的。导致现在所有的打到provider的请求都超时了，那么consumer请求provider的平均响应时间就等于超时时间了，负载也被拉下来了。

而重试则会加重这种情况，使得consumer的可用性变得更差。
因此就出现了熔断的逻辑，也就是，如果检查出来频繁超时，就把consumer调用provider的请求都直接短路掉，不直接调用，而是直接返回一个mock的值，等provider重新恢复稳定时，再重新调用。同时，provider是有可能自主或者人为的在一定时间恢复的，所以之前被短路掉的服务，需要有能力去试探服务是否已经恢复。

限流

上述几个策略都是consumer针对provider出现各种情况而设计的，而provider有时候也需要防范来自consumer的流量突变问题。

想象这样一个场景，provider是一个核心服务，需要向很多个consumer提供服务，但是有一天某个consumer出了些问题，流量飙升，占用了provider大部分机器的时间，导致可能一些其他的重要的consumer不能被正常服务。所以，provider端也需要根据consumer的重要程度，以及平时的QPS大小（每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准），这样来给每一个consumer设置一个流量上限，同一时间只会给某个consumer提供N个线程支持，超过限制则等待或者直接拒绝。

资源隔离

provider可以对consumer来的流量进行限流，防止provider被拖垮。同样，consumer也需要对调用provider的线程资源进行隔离。这样可以确保某个provider出了问题不会耗光整个consumer的线程池资源。

服务降级

降级讲的是指provider这边因为某些问题提供不了真实服务，从而只能由伪装者提供伪装服务给consumer，这样看就是自己的待遇下降了。从RPC调用环节来讲，去访问本地的一个伪装服务而不是真实的服务，这对调用端来说是没有区别的。拿电商展示某个产品的详细页来说

·当加载评论时，由于评论服务不可用，此时可以返回一些默认的评论。

·当加载产品库存，由于库存服务不可用，此时可以固定的显示一个库存数

上面提供返回的默认评论，固定库存的服务就是伪装服务，这类服务一般不依赖其他的服务，稳定性最高。有伪装者提供服务给consumer的现象就是服务降级

以上就是上海非凡学院培训学校小编为您整理RPC服务难治理现在就教你如何RPC服务治理解决尴尬境地的全部内容，更多精彩请进入IT培训栏目查看。