遇到的问题
目前系统中，为了保证服务的可用性。充斥着大量的重试和降级相关的代码。遇到以下几个问题：
- 重试和降级的逻辑需要重复编写，容易产生错误。
- 重试和降级逻辑并没有很好的监控和管理。发现问题比较被动，发生问题后手动修数据比较麻烦。
如何解决问题
- 解决问题一要做的就是对通用的逻辑进行抽象。在需要使用重试的场景时，通过简单的配置声明就能解决问题。
- 解决问题二则需要对哪些服务调用失败了，重试过几次，采用的是什么降级策略进行记录。对一些关键的事件进行告警。例如调用失败，进行过降级等。对于需要人工参与处理的场景，则需要提供入口进行人工补偿。如果有必要还可以单独开发一个系统来维护和管理。
关于重试
适合通过重试来保证可用性的场景有：
- 只读操作或幂等写操作。例：假设调用服务A的超时时间是2秒，服务A的执行时间是3秒。在A服务执行结束之前调用方超时重试。如果服务A不是幂等的就会出现问题。
- 不需要外部数据变更协助来完成的操作。例：如果调用服务A返回的是参数校验类的错误，则不管重试几次也不会成功。
重试的技术方案
- 固定的for循环
for (int i = 0; i < RETRY_TIMES; i++) {
try {
//服务调用
break;
} catch (Exception e) {
if (i == RETRY_TIMES - 1) {
throw e;
}
}
}
优点：简单直接
缺点：重复代码较多，容易产生错误，仅支持简单的重试策略。
- 利用Spring-retry或guava-retryer
优点：功能完整，对重试涉及的相关逻辑，进行了良好的抽象。
缺点：有一些学习和改造的成本。 - 完全异步的解决方案。将错误消息推送到另一个系统或记录到数据库中稍后重试。
优点：将重试逻辑与正常业务逻辑完全拆分开，可以分别维护互不影响。消息可以在故障的时候堆积起来，等故障恢复了再慢慢来处理，减少人工介入的成本。
缺点：引入了额外的复杂度。会增加调试和维护成本。只适合幂等写操作并且不需要同步返回结果的情况。
实际场景
只读服务
可采用方案2来解决，会增加响应时间。
幂等写需要同步返回结果的服务
可采用方案2来解决，会增加响应时间。
幂等写不需要同步返回结果的服务。
可采用方案2，3来解决。
关于降级
采用降级方案时，需考虑的主要问题是方案的合理性和可能会产生的影响。
使用降级的场景
- 通过远程服务读取操作降级为从本地缓存读取。牺牲的是数据一致性。
- 通过远程服务读取操作改为返回默认值。牺牲的是正确性。
- 买二等座降级为买一等座，类似的业务降级则要和相关的利益方进行沟通确认。
- 对于不重要的服务在发生问题时直接关闭开关，保证关键服务的正常使用。
牺牲的是非关键业务或数据的可用性。
技术方案
可以使用Spring-try项目配合开关来实现。有损服务更多的是取舍的考虑。
总结
以上就是工作中对相关问题的思考记录，等以后有更多的理解了再补充完整。
网友评论