当用户在大厅登陆成功之后，大厅会分配一个网关的地址给客户端。客户端与这个网关建立长连接，负责与服务器的通信。网关的主要功能有：
消息解析
消息合法性验证
转发消息到业务服务
流量限制
版本验证等。
一般的功能都可以随便添加。这里主要说一下消息转发。对于客户端和业务服务来说，网关是一个承上启下的作用。首先客户端与网关建立连接，第二，网关收到客户端的一请求请，得知道把这条请求发送到哪个业务服务上面，第三，业务服务处理完一个请求，如何把消息返回给网关，网关再如何把消息发给客户端。
一，客户端与网关建立连接
网关作为一个单独的对外服务，而且是长连接，一般使用Netty作为服务的网络通信框架。它的异步高性能是公认的，这没什么可说的。在游戏服务器的网关中，建立连接一般分为两个步骤：
1，客户端通过socket连接到服务器
2，连接的认证
连接到服务器之后，客户端和服务器就会建立起一个socket通信通道，但是一个服务器的socket连接数量是有限的，如果客户端与服务器大量建立socket连接，而不通信，就会造成大量的socket资源被占用，增加服务器的压力，影响正常用户的使用，所以要有连接的认证，当连接建立成功之后，要在一段时间之内进行认证，如何认证呢？就是让用户请求token验证，如果一段时间内没有认证，则服务器主动断开连接。这样也可以保证之后用户的通信是有效的，不用每次都验证token.用户验证成功之后，保证用户id与连接的映射，方便根据用户id给此用户的客户端返回消息。
二，网关与业务服务间的通信
一个网关后面可能有n个业务服务，所以是一个一对多的关系。所以增加一个业务服务都需要与网关建立一条连接。如果直接建立连接，管理起来比较麻烦。既然是一对多的关系，我们自然想到一种模式：发布-订阅。这种模式可以解耦发布者和订阅者。而目前很多消息队列框架都支持这种模式。比如rabbitmq,rocketmq,kafka等。推荐使用rocketmq。这里阿里的消息中间件。
要实现网关和业务服务的数据交互，大消息传输中需要几个公共参数：
fromServerId 消息的发送服务器id，即消息的来源服务id
toServerId 消息要到害的服务Id
在网关与业务服务交互的消息中必须带有这两个参数
1，网关收到的消息如何转发到业务服务器
既然是使用发布-订阅模式，那网关就是发布者，业务服务就是订阅者，即消息消费者。在网关处，首先是根据用户id选择用户到过的业务服务id，可以根据用户id和业务服务数量求余，这样同一个用户id都会被分配到同一台业务服务器上面。为了可以保证动态添加新的服务，每次给用户分配好到达的业务服务id之后，可以缓存起来，有缓存的话就使用缓存中的，这样动态添加一台新的业务服务之后，已分配的用户不用重新分配，当网关重启之后清空缓存，再重新分配。获得的业务服务id即toServerId，网关收到消息之后，发送消息的topic可以使用toServerId组合，例如：“GameGate” + toServerId ，这样同一个业务服务的消息都会发送到同一个消息主题里面。而在业务服务端，则需要监听网关的消息，监听topic就是“GameGate” + 本业务服务的id，这样就可以收到网关发送过来的消息了。
2，业务服务如何返回消息给网关
同样的道理，业务服务要发消息给网关，那么业务服务就是发送者，发送的消息topic可以是“GameServer” + 网关服务的id，即从接收消息中获取的fromServerId。而网关那边则需要监听topic:"GameServer" + 本网关的服务Id.
这样就完成了网关和业务服务之间的消息交互。网关的其它职能可以根据需要增加。