2、网关架构设计：单点网关架构、集群网关架构、网关与后端服务的拓扑关系

聊到网关架构，我脑子里第一个蹦出来的画面，就是当年那个让我通宵排查的线上事故。嗯，说起来都是泪。但正是那次经历，让我对网关架构的理解深了好几个层次。

说白了，网关就是游戏服务器的「大门」。所有玩家请求都得从这过。门设计得好，千军万马来相见；门设计得烂，几个玩家就能把服务器挤爆。

2.1 单点网关架构

单点网关，就是只部署一个网关实例。所有玩家都连到这一个节点上。

我在项目初期就踩过这个坑。当时觉得「一个网关够用了，玩家又不多」。结果上线第三天，同时在线冲到2000，网关CPU直接飙到95%。玩家开始疯狂掉线，群里骂声一片。

单点网关的优缺点很明显：

优点	缺点
架构简单，开发快	单点故障，挂了全完
连接管理方便	性能瓶颈，扩展难
调试排查容易	无法水平扩展
适合小规模项目	大并发扛不住

2.2 集群网关架构

集群网关，就是部署多个网关实例。玩家连接时，通过负载均衡分配到不同的网关节点上。

你想想看，一个网关扛1000连接，那10个网关就能扛10000。这就是集群的魅力。

我习惯把集群网关分成两种模式：

2.2.1 无状态集群

每个网关节点完全独立，不共享任何状态。玩家连到哪个节点，就在哪个节点上处理。

// 无状态网关的核心逻辑
public class StatelessGateway {
    // 玩家连接直接转发到后端
    public void onPlayerConnect(PlayerSession session) {
        // 选择一个后端服务
        BackendServer server = loadBalancer.select();
        // 建立转发通道
        session.bindTo(server);
    }
}

这种模式的好处是扩展简单。加节点就行，不用改代码。但有个问题——玩家断线重连后，可能会被分配到不同的网关节点。

2.2.2 有状态集群

网关节点之间共享玩家会话状态。通常用Redis或共享内存来实现。

// 有状态网关的会话共享
public class StatefulGateway {
    private RedisClient redis;
    
    public void onPlayerReconnect(PlayerSession session) {
        // 从Redis恢复会话状态
        SessionState state = redis.get("session:" + session.getPlayerId());
        // 恢复连接上下文
        session.restore(state);
    }
}

2.3 网关与后端服务的拓扑关系

这部分我当年理解得不够深，结果吃了大亏。网关和后端服务怎么连，直接决定了系统的稳定性和扩展性。

常见的拓扑关系有三种：

2.3.1 直连模式

网关直接连接后端服务。每个后端服务暴露一个端口，网关根据消息类型转发。

// 直连模式的转发逻辑
public class DirectRouter {
    public void route(Packet packet) {
        switch (packet.getType()) {
            case LOGIN:
                forwardTo("login-server", packet);
                break;
            case GAME:
                forwardTo("game-server", packet);
                break;
            case CHAT:
                forwardTo("chat-server", packet);
                break;
        }
    }
}

这种模式简单直接，但耦合度高。后端服务一多，网关的转发逻辑就变得臃肿。

2.3.2 代理模式

网关只做连接管理和数据透传。真正的路由逻辑由后端的「代理层」处理。

我曾经在一个项目中用过这种模式。网关只负责维持WebSocket连接，收到数据后直接扔给消息队列。后端服务从队列里取数据，处理完再通过队列返回。

// 代理模式的网关逻辑
public class ProxyGateway {
    private MessageQueue mq;
    
    public void onMessage(PlayerSession session, byte[] data) {
        // 封装成消息
        Message msg = new Message(session.getId(), data);
        // 扔到队列
        mq.publish("game-requests", msg);
    }
}

2.3.3 混合模式

这是目前大厂的主流做法。网关既做直连，也做代理。根据消息的重要程度和实时性要求，选择不同的转发方式。

消息类型	转发方式	原因
玩家移动	直连	延迟敏感，需要实时
聊天消息	代理	可以接受轻微延迟
战斗结算	直连	需要强一致性
日志上报	代理	异步处理即可

嗯，这里要注意。混合模式虽然灵活，但实现复杂度高。你得在网关里维护两套转发逻辑。我建议团队至少要有2-3年的后端经验，再考虑上混合模式。

2.4 架构选型建议

说了这么多，到底怎么选？我总结了几条经验：

• 初创项目：单点网关 + 直连模式。快速验证，别在架构上花太多时间。
• 成长型项目：无状态集群 + 代理模式。先解决扩展性问题。
• 成熟型项目：有状态集群 + 混合模式。追求极致性能和稳定性。

最后说一句。网关架构没有银弹。你看到的那些大厂方案，都是踩了无数坑之后迭代出来的。别盲目追求「高大上」，适合你当前阶段的，才是最好的。