最近因为一些私事暂停了之前计划的更新,拖了好久了,我会陆续全部写完,今天优先更新一篇小文吧。SDK相关的系列后续慢慢更新。好了不说废话了,进入下一段废话。
之前一直想写一篇关于高可用的内容,但一直没一个契机,最近被一个真实的案例坑的够惨,关键是发现对于高可用彼此竟然有比较大的理解差异,然后就总结一下自己想象中的高可用,也是自己对高可用的理解,算是分享和交流吧。
首先必须承认这次客户端和后台都有不少问题,典型的坑中坑,一个bug接着一个bug。首先说一下问题的经过吧:
后台的接口是一个检查并刷新第三方token的接口。调用时会调用两个第三方平台的接口,只有调用第一个时第三方平台返回token过期才会调用第二个接口。
在处理后台接口返回(后台调用第三方平台的第一个接口返回token有效的逻辑)存在问题。当后台调用第三方平台的第一个接口返回调用成功且token有效的时候,客户端却处理为登陆失败了。
后台的bug导致了客户端的bug肯定不会被测试出来。导致最终当后台bug被发现并修复以后,客户端的bug立即被触发,引起线上的问题。
客户端调用接口新加一个字段,后台识别到该字段就先调用接口一,再根据第二个接口。后台无法识别到这个字段的请求就直接调用第二个接口。
客户端的是低级错误,连设计都谈不上,就不分析了,主要分析下后台的问题。
跟后台交涉,认为设计不合理:如果是接口调用成功,返回token过期,可以调用第二个接口,但是第一个接口调用失败就不应该去调用第二个接口,导致问题无法即使发现。尤其这种调用错误的问题,测试期间就能百分百会发现的。
后台表示为了高可用,只要能成功就应该给成功,而不应该降低用户体验,给失败。
跟后台再交涉,那这种调用失败有木有日志来记录呢?或者这种调用异常有告警,可以及时发现问题?
后台表示,接口最后是调用成功了,并不是失败,为什么要记录错误日志呢?
继续交涉,如果按照上面的逻辑,后续在遇到这样的问题还是没法及时发现,等问题放大再处理会很麻烦。如果不做上面的工作,类似的问题怎么避免?
后台表示,此类问题纯属偶然,而且目前我们同时封多个接口的目前只有这一个。经过这次梳理不会再有问题。
我瞬间就蒙逼了!!!
高可用不等于可以用就好,无论什么时候都可以用只是高可用最基本的要求
高可用绝对不是功能有问题,自己不知道,使用者不知道,绝不是仅仅通过简单的接口重试等隐藏和掩盖问题。这不是高可用,是隐藏bug的高级手段。
具体的,高可用对于功能的使用者来说,意味着平台的异常不影响或者尽可能小的影响使用者。
高可用对于功能的提供者来说,意味着平台有问题的时候不会影响使用者。而且即使功能提供者无法即使响应,平台自身有一些自动切换、故障隔离、进程重启、代码逻辑等策略自动完成故障屏蔽或者自愈,这个过程中几乎不影响正常的使用。
最重要的一点,高可用体现在平台有问题的时候,对于功能使用者来说是无感知的,但是对于功能的提供者来说是第一时间通过测试、告警等方式了解到问题的存在。同时,功能提供者对于故障的处理的时机并不重要。