我理解的高可用

最近因为一些私事暂停了之前计划的更新，拖了好久了，我会陆续全部写完，今天优先更新一篇小文吧。SDK相关的系列后续慢慢更新。好了不说废话了，进入下一段废话。

之前一直想写一篇关于高可用的内容，但一直没一个契机，最近被一个真实的案例坑的够惨，关键是发现对于高可用彼此竟然有比较大的理解差异，然后就总结一下自己想象中的高可用，也是自己对高可用的理解，算是分享和交流吧。

血淋淋的案例

首先必须承认这次客户端和后台都有不少问题，典型的坑中坑，一个bug接着一个bug。首先说一下问题的经过吧：

1. 一次游戏的超长时间停机以后，发现了一个后台的bug（不影响用户体，但是会影响第三方平台），这个bug已经存在半年之久。
2. 后台修复版本提测以后没配合客户端测试，单独测试后台版本没有问题以后直接发布了。
3. 发布后很快发现修复版本会触发客户端的bug（必现），导致大批游戏出现问题
4. 优先回退后台版本，解决线上问题。然后重新讨论方案
5. 方案一确认，客户端测试再次发现因为客户端的另一个bug，该方案有问题
6. 再次确定新的方案，然后后台和新版本的客户端同步修改才最终解决问题。

案例分析

后台接口是怎样的接口：

后台的接口是一个检查并刷新第三方token的接口。调用时会调用两个第三方平台的接口，只有调用第一个时第三方平台返回token过期才会调用第二个接口。

bug是怎样的bug：

后台的bug：

1. 在封装接口的时候并不是第一个接口返回token过期的时候调用第二个接口，而是只要第一个接口返回不是token有效，无论是过期还是接口调用失败都会调用第二个接口。
   • 后台在调用第一个接口的时候少了一个参数，导致第一次调用必然失败。
   • 后台接口只有当调用第二个接口失败或者异常才认为是失败，第一次调用失败连错误日志都不会打印。

客户端的bug：

在处理后台接口返回（后台调用第三方平台的第一个接口返回token有效的逻辑）存在问题。当后台调用第三方平台的第一个接口返回调用成功且token有效的时候，客户端却处理为登陆失败了。

bug中的bug：

后台的bug导致了客户端的bug肯定不会被测试出来。导致最终当后台bug被发现并修复以后，客户端的bug立即被触发，引起线上的问题。

bug怎么修复：

客户端调用接口新加一个字段，后台识别到该字段就先调用接口一，再根据第二个接口。后台无法识别到这个字段的请求就直接调用第二个接口。

设计的讨论：

客户端的是低级错误，连设计都谈不上，就不分析了，主要分析下后台的问题。

回合一：

跟后台交涉，认为设计不合理：如果是接口调用成功，返回token过期，可以调用第二个接口，但是第一个接口调用失败就不应该去调用第二个接口，导致问题无法即使发现。尤其这种调用错误的问题，测试期间就能百分百会发现的。

后台表示为了高可用，只要能成功就应该给成功，而不应该降低用户体验，给失败。

回合二：

跟后台再交涉，那这种调用失败有木有日志来记录呢？或者这种调用异常有告警，可以及时发现问题？

后台表示，接口最后是调用成功了，并不是失败，为什么要记录错误日志呢？

回合三：

继续交涉，如果按照上面的逻辑，后续在遇到这样的问题还是没法及时发现，等问题放大再处理会很麻烦。如果不做上面的工作，类似的问题怎么避免？

后台表示，此类问题纯属偶然，而且目前我们同时封多个接口的目前只有这一个。经过这次梳理不会再有问题。

我瞬间就蒙逼了！！！

何为高可用：

• 高可用不等于可以用就好，无论什么时候都可以用只是高可用最基本的要求
• 高可用绝对不是功能有问题，自己不知道，使用者不知道，绝不是仅仅通过简单的接口重试等隐藏和掩盖问题。这不是高可用，是隐藏bug的高级手段。
• 具体的，高可用对于功能的使用者来说，意味着平台的异常不影响或者尽可能小的影响使用者。
• 高可用对于功能的提供者来说，意味着平台有问题的时候不会影响使用者。而且即使功能提供者无法即使响应，平台自身有一些自动切换、故障隔离、进程重启、代码逻辑等策略自动完成故障屏蔽或者自愈，这个过程中几乎不影响正常的使用。
• 最重要的一点，高可用体现在平台有问题的时候，对于功能使用者来说是无感知的，但是对于功能的提供者来说是第一时间通过测试、告警等方式了解到问题的存在。同时，功能提供者对于故障的处理的时机并不重要。