由灾备工作中引发的对“比例”的思考

发表于 |

前言

  • 关于文章的题目我想了很久，暂时没想到合适的题目，姑且先这样吧
  • 之前在做灾备工作的时候，经常涉及服务的强弱依赖，超时时间，降级，以及业务折中方面的思考，下面将通过一些例子简要进行描述

场景描述

  • 从服务所依赖的重要程度上来区分有“强依赖”和“弱依赖”。

    1. 通常上，针对“弱依赖”我们会设置较小的超时时间(比如100ms以内)，并且在失败率较高是进行降级；
    2. 而针对“强依赖”我们会设置一个较大的超时时间，当接口失败时返回“服务繁忙“，表示暂不可用(当然可以产品层面进行合适的引导)

  • 我们在灾备演练中，通过停其中一个机房，触发以下的问题

    1. 强依赖超时问题（停机房瞬间）
    2. 弱依赖多变长的问题（停机房期间）

  • 从而导致停机房瞬间接口失败率高，停机房期间接口时延上涨严重。由此引发我对“比例“问题的思考。

    1. 强依赖超时时间设长，可以减少失败率，但也有可能导致服务worker线程池被占满而拒绝请求。
    2. 弱依赖虽然每个都设置100ms以内，但是当依赖的服务超过10个时(真实业务真的有)，可能导致总时长超过一秒(弱依赖慢但都没熔断，所以没降级；可异步并发的弱依赖的另说)

解决方案

  1. 对强依赖，可设置超时时间的比例（比如只有20%的请求可以超过1s，其他的控制在100ms以内），解决停机房瞬间，线程池占满拒绝请求的问题
  2. 对弱依赖，可控制多个弱依赖的总超时时间，解决停机房期间跨机房调用导致时延一直上涨的问题
    • 单个调用超时时间可分级设置比例；多个调用（可熔断）可聚合在一起设置总超时时间比例
    • 降级优先级排序，控制总时间。熔断线程池，控制比例超时。允许一定的时间超时。流量控制。物理隔离。

扩展

  1. 针对使用回调机制提高接口安全性所讲的，某些网络场景可以考虑针对大金额的请求才回调，减少RPC次数，这其实也是一个“比例”问题。