现在做的一个项目的服务器是一个单服务器。由于底层已经封装，所以有些东西并看不到，但是差不多还是可以的能够推测出来底层的架构模式。语言C++,IDE：XE5
数据库是一个很简单的文件读写，但是通过推测以及配置文件的和映射出来的函数来看，应该并不是简单的文件I/O操作bin文件，应该是深层的利用了内存映射的方式来对文件进行处理，是的内存映射文件处理大数据量的文件更加的高效。之所以这么猜测，数据库设置存储上显示20W，然而就现在的测试而言，仅仅是40个用户左右，数据文件已经高达20MB，那么1G的容量也顶多2000来个用户，那么上万的用户数据文件的增长肯定GB级别的，那么采用win32或者MFC中提供的文件处理函数，显然行不通了。不符合现有的服务器框架的的整体限制。并且也没有发现申请文件读取缓存的地方。
关于命令的解析还是很混，但是处理起来应该并不复杂，也并没有一个很好的认识。虽然简单的解析命令并不复杂童颜是二进制的精准操作来进行通讯，一则不容易被解析，另外一则也是进一步压缩网络流量。但是由于Socket是长连接，因此C/S的任意一方在接收到另一方发来的命令的时候，都会出现接包不完整或者多接的情况。因此命令要有开始标示和结束标示来隔断区域。
数据抽象上，因为C++具有C的特性，也有面向对象的特点。但是我这里并没有使用过多的对象，而是使用面向结构的形式来处理的数据抽象。结构体能很好的确定实际使用内存的容量以及存储容量，然而用对象的话可能会造成内存溢出的风险。由于是面向结构的，自己的一个体会，采用面向过程的方式来构建代码较易于维护一些，分清楚代码区块，跨大模块的函数复用要小心。面向对象只不过是为了用来惊醒大的功能模块的脱离而是用而并不是主要解决手段。指针的使用大都是临时变量，所以不必担心溢出和释放问题。
服务器脚本没有涉及。可能下一个项目如果用cocos2d就会涉及到了。
工作协调上，服务器为主导这是公司老人给的一个意见。我也觉的很有道理，服务器的通讯协议的制定，和策划接轨，并且还得能与客户端联调提供一些测试方案，这些的沟通基本上都有服务器的参与。所以写的代码是面向策划的，提供的通讯协议（借口）是面向客户端的。因此在可扩展上要有一定的取舍。功能逻辑上一定得清晰，要有明确的联调测试方案也要对前端有一个考量（仅仅了解就够了）。
服务器是定内存的，也就是所有的涉及方案上都应该有一个理论上限，一要考虑效率问题，也要考虑到策划的扩展留出余地。这样可以保证服务器在一个稳定的环境中运行。
关于广播和通讯，由于自身在的项目并没有涉及到广播域等的问题，所以自己也只是通过看另一个delphi的服务器来理解的。说简单一点，就是通讯分两种，一种是服务器主动派发（广播），另一种是客户端请求服务器响应。然而在MMORPG当中，广播和同步密切相关，什么时候同步，广播给谁都需要计算，当然客户端可以参与一部分的计算。这些网上有一些解决方案可以参考着，但是需要解决的问题都是一个样，什么时候广播，广播范围（广播给谁）这两个问题。