网游网络层简述

编号项按层从下到上。

网络

1.native api:socket, select, iocp, epoll

2.网络库:ACE, BOOST.ASIO, LIBEVENT

消息&序列化

有些方案是序列化和RPC一起提供的，比如FB的thrift。

3.消息中间件（以下为不同方案，非分层。）:

消息：一般来说都是异步的。

直接发消息：不是用中间件，接收消息的只做一个消息缓存队列。自己解析消息，调用对应的函数。返回值也通过发一个消息给客户端实现。

消息队列：使用通用的MQ协议如AMQP，或库如zeromq。个人感觉MQ的很多特性游戏用不到：确保信息传输并且是一次且仅一次(once-and-only-once)的传递，这个是指消费者挂了重启后还可以从MQ中读取消息，但是游戏的各个服是有状态的（各种玩家信息），挂了重启后这些信息没了，有消息也没用，这个特性只有无状态的或能保存状态的消费者才有用。MQ还可以加一层适配器，目前只了解到STOMP，还不知道有何用以及在MQ之上还是之下。

传统的MQ如RabbitMQ、ActiveMQ等都有消息中间件，启动第三方服务进程。而ZMQ就应用程序端点扮演了这个服务角色，原理和其它几种差别太大了。其实和上面的直接发消息也差不了多少，只是提供更多模式选择。

"对于网络游戏，我觉得基于 ZeroMQ 来架构服务器非常合适。对于玩家 Client - Server 部分倒不必使用 ZeroMQ ，而可以写一个前端程序，比如前些年写过的一篇 blog 中提到的连接服务器依然适用。这个连接服务器对内的服务集群则可以用 ZeroMQ 的协议通讯"ZeroMQ 的模式

RPC：（调研还不是很仔细）本地调用远程函数的方式，而非发消息了。每个RPC本质上还是一个消息，所以个人感觉可以基于MQ实现，也就是可以在MQ层之上。但是MQNewer  把RPC和MQ做为两种并列的消息中间件。

同步RPC：初接触的RPC都是这种，效率低，游戏服务端应该不会用的。

不需要返回值的异步RPC：就等于直接发消息了。

异步RPC：配合coroutin可以实现异步RPC，这种应该是最完美的。

4.序列化: protobuf, amf  这个算不上分层，最上的应用是将发送的包先经过序列化后才放入mq中。