一、网络游戏架构的前世今生（1）

本文中的部分资料内容源于前aws的同事。

第一章将按下述顺序进行展开

1. 网络游戏架构的基本理解
2. 网络演进
3. 计算演进
4. 数据库演进
5. 存储演进
6. 实际案例
7. 总结

1. 网络游戏架构与游戏引擎

网络游戏架构（简称游戏架构）是一个听上去既高大上又“原始”的话题，业内其实谈及的场景非常非常非常有限。之所以说它高大上，是因为大家谈论的很少，思考的也相对较少；说它“原始”是因为，大部分谈论的架构、解决方案、场景，通常都是Web应用，与前沿且成熟的Web架构相对比，会产生游戏架构“原始”的感觉。我一直认为这里的“原始”是一定要加上引号的，因为我并不认为游戏架构真的粗糙而简陋，因为技术方向的差异，游戏更多的关注点在于一致且高效的性能——同样一个人能忍受不到半秒的下单延迟，却很难忍受哪怕稍微一停顿的切换装备（专业点这里的例子应该用存档来表述）。玩家希望游戏是极度流畅（这里的极度相比于一般Web应用）、稳定且能提供7*24小时不间断服务的，而游戏架构正是设计为这样的用户需求服务。

这里有必要区分一下“游戏引擎”和“游戏架构”这两个概念。在单机游戏中这两者没有太大区别，但在网络游戏中，我所认为的游戏架构的概念是一个更广的概念。提及游戏架构，往往会想到——客户端使用xxx游戏引擎，网络通信使用xxx网络连接，服务器使用xxx架构；游戏引擎一般指游戏客户端的可视化开发工具和可重用组件，与开发环境高度集成。我接触过白鹭、cocos2dx、Unit