提高系统可用性调研

2017-10-14 本文已影响0人 onjianshu

遇到的问题

目前系统中，为了保证服务的可用性。充斥着大量的重试和降级相关的代码。遇到以下几个问题：

重试和降级的逻辑需要重复编写，容易产生错误。
重试和降级逻辑并没有很好的监控和管理。发现问题比较被动，发生问题后手动修数据比较麻烦。

如何解决问题

解决问题一要做的就是对通用的逻辑进行抽象。在需要使用重试的场景时，通过简单的配置声明就能解决问题。
解决问题二则需要对哪些服务调用失败了，重试过几次，采用的是什么降级策略进行记录。对一些关键的事件进行告警。例如调用失败，进行过降级等。对于需要人工参与处理的场景，则需要提供入口进行人工补偿。如果有必要还可以单独开发一个系统来维护和管理。

关于重试

适合通过重试来保证可用性的场景有：

只读操作或幂等写操作。例：假设调用服务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项目配合开关来实现。有损服务更多的是取舍的考虑。

总结

以上就是工作中对相关问题的思考记录，等以后有更多的理解了再补充完整。