《阿里游戏高可用架构设计实践》读后感
在文章当中我印象最深刻的一句话是“高可用的系统是设计出来的，不是靠运维保障出来的！”游戏出现故障会有很多原因，并不是说除了程序Bug以外，可能其他都是运维背黑锅了。其实，这些问题背后真正的原因是系统设计方案有问题，也就是说，技术上是比较弱的。
1、 高可用目标-传统方法
高可用其实都是指几个9，5个9的话可能就是电信级或者金融级的，互联网大部分是3个9到4个9。
2、 高可用目标-面向业务
最终确定的目标跟几个9的目标有一个比较大的区别，几个9的目标主要是从系统的角度去考虑的，就是说这个系统的可靠性是几个9。而目标是面向整个业务，这个目标就是3分钟来定位问题，5分钟能恢复业务，而且问题的发生频率不能太高，2个月发生一次。
目标的优点：
1、聚焦业务。
2、容易分解。目标本身就是我们的工作方向，首先要定位问题，怎么定位问题？我们就可以想一个办法，其次是恢复业务，第三是故障的频率不能太高；
3、容易衡量。我们后来再做方案的时候，很多方案只要拿这个标准一套，基本上就能够判断这个方案是否可行。
3、高可用整体架构
（1）HTTP-DNS
在游戏接入阶段，游戏里会嵌入SDK，对于SDK内的产品来说，如果遇到后端故障，最快、对用户影响最小的解决方式是立刻去重试，服务器1有故障的话，重新发一个请求到服务器2，就能够正确处理业务。重试里面有一个关键点需要特别注意，重试的时候必须保证这个请求不要再发到原来有问题的服务器上面，否则这个重试只是浪费时间。
HTTP-DNS系统有三个优点：
一、灵活。因为这个走的是HTTP的协议，而且是私有的，可以基于自己的业务特点做很多个性化的东西。
二、快速。因为它不存在缓存这个问题，一旦运维人员甚至是测试同学把这个服务器下掉后，用户这个请求能够立刻拿到最新的结果，避免重复返回到原来有故障的机器。
三、方便。这个系统是我们自己维护的，想做什么样的操作都可以，如果是公共的DNS那就做不了。
（2）架构解耦
业务分离的做法就是把核心业务和非核心业务分拆到不同的系统中，把两个系统之间通过接口调用，互相访问。
（3）业务降级
整个系统拆分成核心业务系统和非核心业务系统，在一些紧急情况下，比如说非核心业务系统重启也没有办法，甚至说某个数据库搞挂了，它又影响业务核心系统。阿里做了一个专门的降级系统，降级系统可以去下发这些降级指令。一般情况下由降级系统给非核心业务系统下发降级指令，如果到了一些关键时刻，其实核心业务系统中有的接口也是可以进行降级的。也就是说，降级的时候并不是对整个系统或者整个功能进行降级，可以做到接口或者url这个级别的降级。通过牺牲非核心业务系统的功能，尽最大努力地去保证核心业务系统提供的业务。
（4）异地多活
原来的老架构中分两个集群：A集群、B集群。两个集群共用同一个数据库主库，部署在A集群，所有的写操作都放在A集群主库，由A集群主库同步到A集群从库、B集群从库，各集群的读操作都直接读集群本地的从库。它的缺点是存在全局单点的问题，假如说A集群主库挂了，两个集群的业务基本上全部不能提供了。第二个问题是跨机房同步时延的问题，从A集群同步到B集群，我们是直接通过MySQL底层的复制机制去同步的，在一些比较极端的情况下，它的时延可能达到半小时甚至一个小时，这么大的时延的情况下，提供的业务可能就有问题。为此，新架构产生了：业务层数据同步、二次读取、可重复生成全局唯一数据
（5）360度监控
自动化的监控方案是业界现在最常见的ELK解决方案，整个方案是实时采集和分析的，并不需要人工参与。并且，每一层的指标，都通过一个系统可视化展现出来。比如，今日的访问量、今日的正确率、最近一分钟的平均响应时间、错误率。
（6）设计哲学
面向业务。不单单关注某一个系统某一个模块的可靠性和高可用，而是站在整个业务流程的角度去分析一下，为了保证这个业务的高可用，每一个步骤、每一个环节、每一个系统应该怎么做，需要做哪些改进和优化。
技术驱动。我们并没有说制定完善的流程、提高人的素质或者采购更贵的硬件、更好的硬件，整体的方案都从技术的角度去考虑。
关注核心。非核心业务我们可以紧急的时候停掉或者关掉。
可量化。360度监控里的这些指标、分析都是可以量化的，整个项目目标也是可以量化的。