软件架构阅读笔记6
高可用的系统是设计出来的，不是靠运维保障出来的
这篇是阿里游戏，阿里游戏。。。还是关注高可用的系统吧。
真正的问题：系统设计方案
分析目标：
传统:几个9（没有发现问题本质）
面向整个业务：3分钟来定位问题，5分钟能恢复业务，而且问题的发生频率不能太高，2个月发生一次。(这样的目标聚焦了业务，容易分解，容易衡量)
高可用架构：每一层都需要做一些应对的方案，才能达到目标。
一共分为四层：用户层、网络层、服务层、运维层。
游戏接入阶段：
在游戏接入阶段，游戏里会嵌入SDK，对于SDK内的产品来说，如果遇到后端故障，最快、对用户影响最小的解决方式是立刻去重试，服务器1有故障的话，重新发一个请求到服务器2，就能够正确处理业务。
问题：还是发到了问题服务器上
DNS缓存，包括操作系统，为了提高性能，都把DNS解析的结果缓存在本地，这样就会带来一个问题，在重试的时候，有可能第二次重试还是发到原来有问题的机器上。
解决：HTTP-DNS
用户可以向HTTP-DNS系统请求，其实也是域名和服务器的对应关系，但是它走的是HTPP私有的协议，而不是走传统的DNS协议。
优点：
- 灵活。因为这个走的是HTTP的协议，而且是私有的，可以基于自己的业务特点做很多个性化的东西。
- 快速。因为它不存在缓存这个问题，一旦运维人员甚至是测试同学把这个服务器下掉后，用户这个请求能够立刻拿到最新的结果，避免重复返回到原来有故障的机器。
- 方便。这个系统是我们自己维护的，想做什么样的操作都可以，如果是公共的DNS那就做不了。
但存在问题：没有缓存性能低。
解决：客户端重试+HTTP-DNS，正常情况下走传统DNS有利于保证业务服务的性能。
架构解耦
其实对于玩家来玩游戏来说，真正强相关的只有登录注册和参数下发，消息和日志、更新其实并不是玩家玩游戏必须具备或者强相关的。所以，业务分离的做法就是把核心业务和非核心业务分拆到不同的系统中，把两个系统之间通过接口调用，互相访问。
这样做的好处，假设非核心业务系统出现故障，它并不影响核心业务系统，因为它们之间是通过接口调用的，并不共享相同的资源。
服务中心
服务中心类似于DNS，是实现整个内部系统之间服务调用时候的调度功能，服务中心是一个类似于服务的名字系统。
业务降级
问题：
整个系统拆分成核心业务系统和非核心业务系统，在一些紧急情况下，比如说非核心业务系统重启也没有办法，甚至说某个数据库搞挂了，它又影响业务核心系统。
解决：在这种比较极端的情况下，可以通过人工的方式下发降级指令，把这个非核心业务系统的功能给停掉，
异地多活：
优点：
业务层数据同步：通过程序去保证同步的有效性和及时性，而不依赖于底层，用程序可以做多种动作。
二次读取：有的数据在A集群还没有同步到B集群，B集群此时是读取不到的，这时B集群的系统会通过程序的接口再去访问A集群的系统。
可重复生成全局唯一数据：为了能够解决两个集群互相接管对方的业务，就做了可重复生成全局唯一数据方案。
监控：
360度监控
整体方案从上到下分为五层：业务层、应用服务层、接口调用层、基础组件层、基础设施层。
- 自动化：自动化的监控方案是业界现在最常见的ELK解决方案，整个方案是实时采集和分析的，并不需要人工参与。
- 可视化：每一层的指标，都通过一个系统可视化展现出来。比如，今日的访问量、今日的正确率、最近一分钟的平均响应时间、错误率。
游戏高可用设计总结：
面向业务。不单单关注某一个系统某一个模块的可靠性和高可用，而是站在整个业务流程的角度去分析一下，为了保证这个业务的高可用，每一个步骤、每一个环节、每一个系统应该怎么做，需要做哪些改进和优化。
- 技术驱动。我们并没有说制定完善的流程、提高人的素质或者采购更贵的硬件、更好的硬件，整体的方案都从技术的角度去考虑。
- 关注核心。非核心业务我们可以紧急的时候停掉或者关掉。
- 可量化。360度监控里的这些指标、分析都是可以量化的，整个项目目标也是可以量化的。
