TIPS：
我们做的全球同服，需要解决的难点主要有：
- 客观物理距离造成的网络质量问题；
- 负载均衡支持跨地区监听；
- 部署分区支持热扩展。
一. 网络质量优化
物理距离造成的网络质量问题，可能体现在以下方面：
1）server端的不稳定以及响应延迟；
2）网络波动造成存盘数据丢失；
3）运维部署工具失效；
首先明确一个原则，如果对全球范围内的客户端提供服务，那么尽可能优化网络质量这个职责，应该由服务提供方来承担，而不应该完全依赖客户端的本地网络环境。
针对业务响应延迟问题：
优化思路是：在主机器群尽可能集中的前提下，将架构中与客户端直接交互的入口分散部署到就近地区去，弱化客户端网络环境对数据交互的影响，同时通过提高分区与主区之间的网络质量，来达到接管优化网络的职责。优化客户端TO服务端的网络是复杂的（因为客户端环境是复杂的），优化服务端TO服务端的网络是简单的（同集群内网络优化）。
优化方案是：从集群架构中独立出登录入口和网关入口，部署到全球多个主要地区，通过域名解析规则，将各地区客户端解析到就近的服务入口，通过各分区的入口连回主区，分区和主区之间使用专属网络加速专线提高网络质量（延迟和丢包率都有大幅减低）。
如何定位统计各地区网络情况？
client端在游戏内收集网络质量相关信息，上行到中央数据后台，数据后台根据地区等多维度统计分析网络情况，针对性做扩展部署分区等优化动作。
如何针对地区做网络质量优化？
在网络延迟本土新增部署入口分区，热更新接入服务器集群（通过更新DNS解析规则），使延迟区通过所在本土服务入口接入游戏服务。
针对数据库数据安全的容灾方案：
首先需要明确一个游戏项目中数据库的使用原则：职责单一化。对于游戏这类对实时交互性要求较高的项目，数据库应该承担的是数据备份容灾责任，而应该避免作为具体业务模块间的数据交换方案。即，数据存盘操作只是对内存数据的持久化保存，而不作为业务设计的一部分，业务模块的数据交互应该在内存层面统一体现，以避免高并发场景下的性能问题。
那么所有存盘数据都是覆盖更新，此时单次存盘操作失效从业务层面看是可接受的。
这里不谈数据库产品支持的集群方案（高可用），只给出当数据存盘失败时业务层的容灾方案：以数据库临时文件的方式暂存在本地机器（比如mongdb存盘失败时以bson文件保存），当数据库连接恢复的时候，再有序或触发式地写回到数据库里面去。
针对工具链稳定性的优化：
当生产环境分布在全球多地区，开发环境对外的资源同步操作，使用直连的方案，速率和稳定性受网络质量影响是大的。优化思路是使用中转层，将资源推送上云（各分区的云端，走专属网络加速），再由生产环境下载获取。工具链方案：https://www.cnblogs.com/linxx-/p/18107305
标签：架构,游戏,探索,数据库,网络,存盘,质量,优化,客户端 From： https://www.cnblogs.com/linxx-/p/18202829