近两日极为纠结——游戏服务器，选择何种技术方案？（Python + SWIG--RakNet + Lua）
需求是：一种移动或web游戏的服务器，要求是尽量保证维护简单，框架尽可能简洁，代码量不宜过多；考虑1人非全职进行服务器维护，不应对运维造成太大难度。
首先，必须使用RakNet，可用的游戏服务器框架很稀有，这是其中一个开源框架，底层提供完整的可靠UDP协议，上层有完整的封装，不得不用。
其次，客户端采用C++、Lua编写，其中逻辑部分完全使用Lua编写。服务器需要做一部分验证工作，所以应当部分复用相关逻辑。
技术试验结论如下：
1、利用HTTP服务器建立游戏服务器。非常简单粗暴的思路，做起来很快，但是在HTTP服务里服务器无法主动发出请求，所以某些交互方面的需求几乎不可实现。经讨论放弃。
2、RakNet完全采用C++编写，维护难度适中。RakNet的Patcher服务器官方建议采用PostgreSQL作为数据库，原因是MySQL的部分功能支持不正常。比如截取数据库里超长字符串其中的一段会非常的慢。
3、DB中间件（ORM），可选择范围：C++库可选ODB，Python库可选SQLAlchemy。
4、接口生成器SWIG。用于将C++的库（例如RakNet）全部半自动化注册到其他语言，经试验难度适中，可行。尚存在问题：回调函数的注册，远程过程调用RPC的注册还没有调查过。
5、Python的使用方式有两种：一是将C++的底层库完全注册给Python使用，另一种是让C++调用Python模块的接口。
6、Lua的技术实现上预计不存在太大问题。服务器端逻辑相关代码基本确定采用Lua编写。
7、早上的新发现：Lua与Python混合编程：Lunatic Python。 Being two-way means that it allows Lua inside Python, Python inside Lua, Lua inside Python inside Lua, Python inside Lua inside Python, and so on. 霸气侧漏。不知道你敢不敢用，我反正敢用。另外有Lunatic Python的Lua-jit优化版本：lupa。网址分别为：
http://labix.org/lunatic-python
http://pypi.python.org/pypi/lupa/0.9
8、早上的新发现：Cython。支持用一种特制的语法编写看起来是Python，实际是C的代码，之后可以将其编译为C语言级别的动态链接库。在数学运算、函数调用方面极大降低开销，加快速度。可以用在项目中后期优化的时候。特此记录。
重要优缺点介绍：
1、C++的ORM库ODB据百度说是最佳选择之一，但仔细研究了一整天帮助手册和实际试验，发现此库要求用户使用C++11的新特性，大量使用#pragma等编译器特殊语法，Table的关联是用多种不同类型的智能指针实现的。并且此库底层提供了类似boost的改装库，提供了比boost更丰富的智能指针例如lazy_shared_ptr。这些高级功能必然会被使用到。（我很想说：这货不是C++。）
此外，由于C++需要被编译，所以ODB在使用时不是完全自动化的，其使用分解为两大步：分析头文件生成胶水层、然后编译链接用户代码和胶水层。
2、SQLAlchemy使用上非常简单，可以通过简单设计实现数据库初始化、操作一体化。且本人对Python的了解程度远高于C++11、boost等。其致命缺点在于一旦采用Python相关技术，势必要在C++/Python接口上下很多功夫。
3、SWIG的致命问题在于——移植库的过程是一个考验C++/其他语言语法基本功的过程，非常有挑战。实现难度：4星半，但可以一试。
计划在上述条件下设计服务器框架，目前剩余问题是C++如何用简单的方式调用Python接口。预计今日（2012-5-10）晚得出结论。
——————————————————————————————————————————————————————
结论：完全使用 Python + Lua（Lunatic Python）编写服务器
其中，RakNet库用SWIG将重要接口全部注册给Python，直接用Python编写高性能服务器！移植时有一些高级特性需要仔细看SWIG的在线文档，已试验通过。欢迎交流。
这样一来，所有技术重点全部转移到Python上了。希望玩Python爱好者们都看到这篇文章。其实我最近很想学Ruby = =