游戏开发:全球服架构探索之网络质量优化

TIPS:

我们做的全球同服,需要解决的难点主要有:

  1. 客观物理距离造成的网络质量问题;
  2. 负载均衡支持跨地区监听;
  3. 部署分区支持热扩展。

一. 网络质量优化

物理距离造成的网络质量问题,可能体现在以下方面:

1)server端的不稳定以及响应延迟;

2)网络波动造成存盘数据丢失;

3)运维部署工具失效;

首先明确一个原则,如果对全球范围内的客户端提供服务,那么尽可能优化网络质量这个职责,应该由服务提供方来承担,而不应该完全依赖客户端的本地网络环境。

针对业务响应延迟问题:

优化思路是:在主机器群尽可能集中的前提下,将架构中与客户端直接交互的入口分散部署到就近地区去,弱化客户端网络环境对数据交互的影响,同时通过提高分区与主区之间的网络质量,来达到接管优化网络的职责。优化客户端TO服务端的网络是复杂的(因为客户端环境是复杂的),优化服务端TO服务端的网络是简单的(同集群内网络优化)。

优化方案是:从集群架构中独立出登录入口和网关入口,部署到全球多个主要地区,通过域名解析规则,将各地区客户端解析到就近的服务入口,通过各分区的入口连回主区,分区和主区之间使用专属网络加速专线提高网络质量(延迟和丢包率都有大幅减低)。

如何定位统计各地区网络情况?

client端在游戏内收集网络质量相关信息,上行到中央数据后台,数据后台根据地区等多维度统计分析网络情况,针对性做扩展部署分区等优化动作。

如何针对地区做网络质量优化?

在网络延迟本土新增部署入口分区,热更新接入服务器集群(通过更新DNS解析规则),使延迟区通过所在本土服务入口接入游戏服务。

针对数据库数据安全的容灾方案:

首先需要明确一个游戏项目中数据库的使用原则:职责单一化。对于游戏这类对实时交互性要求较高的项目,数据库应该承担的是数据备份容灾责任,而应该避免作为具体业务模块间的数据交换方案。即,数据存盘操作只是对内存数据的持久化保存,而不作为业务设计的一部分,业务模块的数据交互应该在内存层面统一体现,以避免高并发场景下的性能问题。

那么所有存盘数据都是覆盖更新,此时单次存盘操作失效从业务层面看是可接受的。

这里不谈数据库产品支持的集群方案(高可用),只给出当数据存盘失败时业务层的容灾方案:以数据库临时文件的方式暂存在本地机器(比如mongdb存盘失败时以bson文件保存),当数据库连接恢复的时候,再有序或触发式地写回到数据库里面去。

针对工具链稳定性的优化:

当生产环境分布在全球多地区,开发环境对外的资源同步操作,使用直连的方案,速率和稳定性受网络质量影响是大的。优化思路是使用中转层,将资源推送上云(各分区的云端,走专属网络加速),再由生产环境下载获取。工具链方案:https://www.cnblogs.com/linxx-/p/18107305

热门相关:性鬼:为性爱疯狂的鬼怪们   扑通扑通   追龙之罪与罚   神耆小子国语   仪式:我帮你成为男人