阅读文章：阿里游戏高可用架构设计实践
文章网址：https://mp.weixin.qq.com/s?__biz=MzA4Nzg5Nzc5OA==&mid=2651660980&idx=1&sn=640c3d2280d7657f236434ff6ba0b22b&scene=21#wechat_redirect
整个演讲的内容给我印象最深的就是：把运维的锅让研发去背，即高可用的系统是设计出来的，不是靠运维保障出来的。
系统设计方案有问题，从技术方面来解决这个问题。
高可用目标——传统方法
确定这个方向之后我们就需要定一个目标，首先确定一个目标。高可用其实都是指几个9，5个9的话可能就是电信级或者金融级的，互联网大部分是3个9到4个9。这个目标的优点是业界通用，高技术的大家都接受了这个目标。缺点是除了技术人员，其他同学不是很好理解，他们没有办法将4个9或者5个9转换成直观的理解。所以，在定项目目标的时候并没有这样去定。
高可用目标——面向业务
最终确定的目标跟几个9的目标有一个比较大的区别，几个9的目标主要是从系统的角度去考虑的，就是说这个系统的可靠性是几个9。而我们的目标是面向整个业务，这个目标就是3分钟来定位问题，5分钟能恢复业务，而且问题的发生频率不能太高，2个月发生一次。
这个目标的优点：
（1）聚焦业务
（2）容易分解。目标本身就是我们的工作方向，首先要定位问题，其次是恢复业务，第三是故障的频率不能太高。
（3）容易衡量。后来再做方案的时候，很多方案只要拿这个标准一套，基本上就能够判断这个方案是否可行。
整个目标最终折算下来，对应的差不多是4个9左右，比4个9高一点点。
高可用整体架构，整体架构一共分为四层：用户层、网络层、服务层、运维层。
客户端重试，在游戏接入阶段，游戏里会嵌入SDK，对于SDK内的产品来说，如果遇到后端故障，最快、对用户影响最小的解决方式是立刻去重试，服务器1有故障的话，重新发一个请求到服务器2，就能够正确处理业务。重试里面有一个关键点需要特别注意，重试的时候必须保证这个请求不要再发到原来有问题的服务器上面，否则这个重试只是浪费时间。
传统DNS问题，在重试的时候，要尽量保证重试的服务器跟原来的服务器不一样，但是传统的DNS正好在这方面存在天然的缺陷，DNS存在三个方面的问题：（1）DNS劫持（2）DNS污染（3）DNS缓存。
HTTP-DNS系统有三个优点：
（1）灵活。因为这个走的是HTTP的协议，而且是私有的，可以基于自己的业务特点做很多个性化的东西。
（2）快速。因为它不存在缓存这个问题，一旦运维人员甚至是测试同学把这个服务器下掉后，用户这个请求能够立刻拿到最新的结果，避免重复返回到原来有故障的机器。
（3）方便。这个系统是我们自己维护的，想做什么样的操作都可以，如果是公共的DNS那就做不了。
架构解耦，业务分离的做法就是把核心业务和非核心业务分拆到不同的系统中，把两个系统之间通过接口调用，互相访问。
业务降级，整个系统拆分成核心业务系统和非核心业务系统，在一些紧急情况下，比如说非核心业务系统重启也没有办法，甚至说某个数据库搞挂了，它又影响业务核心系统。在这种比较极端的情况下，我们可以通过人工的方式下发降级指令，把这个非核心业务系统的功能给停掉，这个停掉并不是把程序停掉，而是说把其中的一个接口或者url停掉，核心系统去访问的时候就得到一个500或者503错误。降级的时候并不是对整个系统或者整个功能进行降级，我们可以做到接口或者url这个级别的降级。通过牺牲非核心业务系统的功能，我们尽最大努力地去保证核心业务系统提供的业务。
异地多活，为了解决全局单点、跨机房同步时延的问题，提出了一套新架构。
新架构与旧架构相比。最大的特点是：
（1）业务层数据同步。
（2）二次读取。
（3）可重复生成全局唯一数据。
360度监控，整体方案从上到下分为五层：业务层、应用服务层、接口调用层、基础组件层、基础设施层。