标签：系统 假设 体验 服务层 相同 接口调用 读后感 chat 游戏架构
这篇文章文章主要是对游戏架构的设计，因为作为一名游戏玩家，都是非常注重游戏体验的，如果在游戏过程中出现不能登录，或者掉线的情况，很多人可能会投诉。初始可能人们都会认为是运维的原因，可能是硬件太差，或者是运维的经验不足等问题。但是人们往往忽略了研发方面的问题，没有从根本的设计方案上去思考解决问题。根本原因还是系统设计方案有问题，也就是说，技术上是比较弱的。
作为一个好的游戏，高可用性是必要条件，那为了提高可用性，就要有一个良好的架构。在阿里游戏的高可用架构上来看，总体架构分为了四层。包括用户层，网络层，服务层和运维层。
在用户层的设计方案是错误重试的方案，如果向服务器1的请求错误，那就重新请求服务器2，首先使用传统的DNS，如果出错则改用HTTP-DNS。还有就是要做业务分离，因为游戏中有些业务是不被玩家重视，所以分为重视业务和非重视业务，这样做的好处，假设非核心业务系统出现故障，它并不影响核心业务系统，因为它们之间是通过接口调用的，并不共享相同的资源。
为了解决全局单点、跨机房同步时延的问题，设计了异地多活体架构，这个新架构和老架构相比。最大的特点：1、业务层数据同步。2、二次读取。3、可重复生成全局唯一数据。
运维层，主要实现的是360度监控，整体方案从上到下分为五层：业务层、应用服务层、接口调用层、基础组件层、基础设施层。
1业务层：就是我们业务上的打点，根据这些打点进行机型统计或者分析；
2、应用服务层：简单来说就是我们url的一个访问情况；
3、接口调用层：就是我们自己系统对外部依赖的那些接口的访问情况，比如A系统调用B系统的一个接口，在A系统里统计或者监控调用B系统接口的情况，包括时延、错误次数之类；
4、基础组件层：其实就是我们使用的一些组件，包括MySQL等；
5、基础设施层：就是最底层的，包括操作系统、网络、磁盘、IO这些设备。
整个监控是分层的，在我们出现问题的时候，定位问题需要的关键信息全部包括在这里面的。
自动化的监控方案，是实时采集分析而来，整个流程非常低效，从生产网到办公网的网速很慢为了能够快速处理这个故障，我们进行了详细的分析，把真正出故障的时候要关注哪些信息、关注哪些指标，都通过预先的日志采集、计算、分析完成，放在那里等我们要处理故障或者问题的时候，直接看就可以了。
每一层的指标，都通过一个系统可视化展现出来。比如，今日的访问量、今日的正确率、最近一分钟的平均响应时间、错误率。整个系统的状态一目了然，基本上识字就能够看懂整个系统的状态。
标签：系统 假设 体验 服务层 相同 接口调用 读后感 chat 游戏架构
原文地址：https://www.cnblogs.com/wys-373/p/10647279.html
