终端开发

使用Android Studio开发可独立运行(runnable)混淆过的Jar程序 Android安装包精简系列之资源精简 Android安装包精简系列之图片优化 Android安装包精简系列之为什么要优化精简安装包 Android安装包精简系列(总纲) Android安装包精简系列之图标转字体 gradle相关资料汇总 Android编译常见错误解决 Android编译编译速度提升 终端基于gradle的开源项目运行环境配置指引 制作终端产品演示的gif 一个关于APK Signature Scheme v2签名的神奇bug定位经历 如何随apk一起打包并使用SQLite SDK热更之gradle插件(如何在SDK代码中自动插桩及如何生成补丁包) 关于Android的APK Signature Scheme v2签名相关的资料汇总 封装HttpURLConnection实现的简单的网络请求库 一款基于Java环境的读取应用包名、签名、是否V2签名等基本信息的工具 Android的APK Signature Scheme v2签名及一款基于Java环境的校验工具介绍 如何使用Eclipse开发可执行Jar程序,并生成混淆过的jar程序 Android 相关的学习资料整理(持续更新) macOS(Sierra 10.12)上Android源码(AOSP)的下载、编译与导入到Android Studio Google也看不下去被玩坏的悬浮窗了么? Android开发常用工具资源 SDK热更系列之概述(持续整理编辑中~) SDK热更系列之SDKHotfix待优化点 Android 终端开发相关的一些神图(持续更新) SDK热更系列之Demo项目介绍概述 SDK热更系列之Demo体验方法 SDK热更系列之如何获取应用在当前设备上的so对应的指令集 Gradle Android插件使用的中那些特别注意的点 Experimental Plugin User Guide(From Android Tools Project Site) 基于Android Studio使用gradle构建包含jni以及so的构建实例 基于Instrumentation框架的自动化测试 - Android自动化测试系列(四) Instrumentation框架介绍-Android自动化测试系列(三) 关于终端设备的设备唯一性的那些事之MAC地址 关于终端设备的设备唯一性的那些事之IMEI Android 检查应用是否有root权限 ant常见错误解决方案 Gradle介绍 iMac上Android Studio 相关设置及常见问题 再说adb 再看Android官方文档之分享 再看Android官方文档之Fragment&数据保存 再看Android官方文档之Activity&Intent 再看Android官方文档之ActionBar和兼容性 adb shell input(Android模拟输入)简单总结 再看Android官方文档之建立第一个APP Android开发调试常用工具 ANR(网络资料整理) Java参数引用传递引发的惨案(又一次Java的String的“非对象”特性的踩坑经历) android.view.WindowManager$BadTokenException,Unable to add window Android签名校验机制(数字证书) Robotium二三事-Android自动化测试系列(二) Robotium介绍-Android自动化测试系列(一) Android开发中遇到的那些坑 Eclipse使用中部分经验总结 Android中关于Nativa编译(NDK、JNI)的一些问题 Android简单实现的多线程下载模块 Android内存耗用之VSS/RSS/PSS/USS adb Advanced Command URL编码中的空格(编码以后变为+) Android MD5后 bye数组转化为Hex字符串的坑(记一次为女神排忧解难的经历) Android学习之路 adb Base Command Android Log的那些坑…………

标签

android 46

Android编译常见错误解决 一个关于APK Signature Scheme v2签名的神奇bug定位经历 关于Android的APK Signature Scheme v2签名相关的资料汇总 封装HttpURLConnection实现的简单的网络请求库 一款基于Java环境的读取应用包名、签名、是否V2签名等基本信息的工具 Android的APK Signature Scheme v2签名及一款基于Java环境的校验工具介绍 如何使用Eclipse开发可执行Jar程序,并生成混淆过的jar程序 Android 相关的学习资料整理(持续更新) macOS(Sierra 10.12)上Android源码(AOSP)的下载、编译与导入到Android Studio Android开发常用命令备忘 Google也看不下去被玩坏的悬浮窗了么? Android开发常用工具资源 Android 终端开发相关的一些神图(持续更新) Gradle Android插件使用的中那些特别注意的点 Experimental Plugin User Guide(From Android Tools Project Site) iMac(OS X)搭建私有maven仓库,提供Nexus Responsitory镜像 基于Android Studio使用gradle构建包含jni以及so的构建实例 基于Instrumentation框架的自动化测试 - Android自动化测试系列(四) Instrumentation框架介绍-Android自动化测试系列(三) 关于终端设备的设备唯一性的那些事之MAC地址 关于终端设备的设备唯一性的那些事之IMEI Android 检查应用是否有root权限 iMac(OS X)El Capitan 更新遇到的那些坑 ant常见错误解决方案 Gradle介绍 iMac上Android Studio 相关设置及常见问题 再说adb 再看Android官方文档之分享 再看Android官方文档之Fragment&数据保存 再看Android官方文档之Activity&Intent 再看Android官方文档之ActionBar和兼容性 adb shell input(Android模拟输入)简单总结 再看Android官方文档之建立第一个APP Android开发调试常用工具 ANR(网络资料整理) Java参数引用传递引发的惨案(又一次Java的String的“非对象”特性的踩坑经历) android.view.WindowManager$BadTokenException,Unable to add window Android签名校验机制(数字证书) Eclipse使用中部分经验总结 Android内存耗用之VSS/RSS/PSS/USS adb Advanced Command URL编码中的空格(编码以后变为+) Android MD5后 bye数组转化为Hex字符串的坑(记一次为女神排忧解难的经历) Android学习之路 adb Base Command Android Log的那些坑…………

我理解的高可用

2015年04月22日

最近因为一些私事暂停了之前计划的更新,拖了好久了,我会陆续全部写完,今天优先更新一篇小文吧。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的高级手段。

  • 具体的,高可用对于功能的使用者来说,意味着平台的异常不影响或者尽可能小的影响使用者。

  • 高可用对于功能的提供者来说,意味着平台有问题的时候不会影响使用者。而且即使功能提供者无法即使响应,平台自身有一些自动切换、故障隔离、进程重启、代码逻辑等策略自动完成故障屏蔽或者自愈,这个过程中几乎不影响正常的使用。

  • 最重要的一点,高可用体现在平台有问题的时候,对于功能使用者来说是无感知的,但是对于功能的提供者来说是第一时间通过测试、告警等方式了解到问题的存在。同时,功能提供者对于故障的处理的时机并不重要。



PS:我的博客即将搬运同步至腾讯云+社区,邀请大家一同入驻:https://cloud.tencent.com/developer/support-plan?invite_code=10zhijuy24v4f

赞赏

取消
微信扫一扫,赞赏子勰
扫码支持
屌丝程序猿,鸡血攻城狮!努力学技术,潜心做精品!