为什么需要分布式架构
单体架构在玩家规模超过1万时面临性能瓶颈。分布式架构通过水平扩展，理论上可以支撑无限规模的在线玩家。但分布式也带来了一致性、网络分区、运维复杂度等新挑战。
架构设计原则
有状态与无状态分离
游戏房间是有状态的（牌局进行中不能迁移），因此采用有状态服务+一致性哈希的方式。匹配、登录、支付等服务设计为无状态，方便水平扩展。
服务注册与发现
使用etcd作为服务注册中心，游戏服务器启动时注册自身地址和负载信息。网关层通过watch机制实时感知节点变化，动态调整路由。
消息中间件
使用NATS作为内部消息总线，替代传统的RPC调用。NATS的发布/订阅模式天然适合游戏内的广播场景（如牌桌内通知所有玩家）。
核心模块设计
网关服务
负责WebSocket连接管理、协议解析、路由转发。单个网关节点支撑5000连接，通过K8s HPA根据连接数自动扩缩容。
房间服务
每个房间服务进程管理200-500个游戏房间。使用Actor模型（如Go的goroutine）隔离房间状态，避免锁竞争。房间创建时通过一致性哈希选择节点。
匹配服务
基于Redis Sorted Set实现多维度匹配队列。支持ELO评分匹配、好友同桌、新手保护等多种匹配模式。
容灾与高可用
- 房间状态定期快照到Redis，节点宕机后可在其他节点恢复
- 网关层支持连接迁移，后端节点故障时客户端无感切换
- 数据库主从热备+自动故障转移
- 跨机房部署，支持同城双活
性能优化经验
实战中的关键优化点：协议使用protobuf减少序列化开销、内存池复用减少GC压力、批量合并网络包减少系统调用、热点数据本地缓存减少Redis访问。通过以上优化，单节点QPS从3000提升到12000。