3.2.4 游戏技术服务演进
3.2.3.3 原始架构时代
从典型互联网的BS架构向游戏CS架构转变
从游戏形态来看，客户端游戏早期以CS架构为主，而不用BS架构。CS框架的好 处是将游戏数据存储在本地，能够充分发挥主机性能，使得玩家能够获得流畅的游戏 体验， 个大型的网落游戏服务器应该包含几个模块： 网络通讯， 业务逻辑， 数据存 储，守护监控(不是必须)，其中业务逻辑可能根据具体需要，又划分为好几个子模 块，运维阶段面临的问题更多是游戏内多模块的调用，所以核心要做到Server端的细 化服务运维。
典型互联网的BS架构向游戏CS架构转变
3.2.3.4 石器架构时代
从传统IT “All in one”架构至云上稳定性架构转变
而在页游、手游形态阶段，架构较为通用，这阶段以弱交互游戏为主，这种服务 器架构和我们常用的web服务器架构差不多，也是采用nginx负载集群支持服务器的 水平扩展， 多以LNMP/LAMP架构为主， 且大部分未做高可用。客户端通过入口到 游戏大区列表，根据选服务访问对应系统，web层面多用Nginx或apache，结合 php-fpm或tomcat，数据层落单点mysql存储，这样单游戏在一台服务器上的架构 我们形象的称之为“All1in1one”架构。这个架构最大的问题无疑就是故障场景往往无 法快速恢复，在极端的硬件损坏场景影响往往很大，所以非常依赖运维工作，这也是 最早刀耕火种模式，运维需要建设数据库备份模式、异常快速拉起能力、服务进程稳定性等。
3.2.3.5 黄金架构时代
多游戏场景的精细架构演进
随着游戏业务场景多样化，云产品更加丰富，架构使用上更加精细化。就有了云 原生游戏架构，通过云产品能力等组合打出场景支撑组合拳，让运维更简单。当后期 国内游戏受到政策影响，及国产化游戏出海成为趋势，海外加速也不断的涌现，更加 剧了全球同服架构进化。同时，面对游戏运维、运营的各种业务需求，也派生了多场
景大规模数据存储、数据分析等架构，时至今日，架构还在不断精进。
某游戏云原生游戏架构
某游戏海外加速架构
