规模化C2C一对一网页聊天应用架构选型咨询

一、协议层选型 #

优先推荐：WebSocket（Gorilla Go实现 + 前端MDN WebSocket API） #

• 成熟稳定的双向通信标准，前后端集成成本极低，实际延迟通常在毫秒级，完全满足延迟≤20秒的硬性要求。
• Go的Gorilla WebSocket实现是工业级方案，支持心跳检测、连接管理，应对日300万条消息的峰值压力毫无压力（单WebSocket连接开销远低于HTTP短连接）。
• 适配C2C场景：服务端可维护用户连接映射表，直接将消息路由到目标用户的连接，无需额外中间层。

不推荐/按需选择的方案 #

• HTTP/3（WebTransport）：性能优异但生态不成熟，现有应用迁移成本高，仅当你需要针对弱网环境做极致优化时才考虑，否则WebSocket的性价比更高。
• Google PubSub API：本质是异步消息队列，适合服务间解耦，但不适合作为实时聊天的核心通信协议——需要额外搭建推送机制才能触达用户，增加复杂度。
• 原生TCP套接字：过于底层，需自行实现粘包处理、心跳重连、连接池等逻辑，开发维护成本极高，完全没必要。
• gRPC：主打服务间高效RPC调用，虽然支持流式通信，但前端集成繁琐，不适合面向客户端的实时聊天场景。

二、持久化层选型 #

优先推荐：MongoDB #

• 文档型模型天然适配聊天消息存储：每条消息可作为独立文档，包含sender_id、receiver_id、content、timestamp等字段，查询灵活。
• 支持复合索引（如{sender_id:1, receiver_id:1, timestamp:-1}），可高效查询单用户的历史对话记录。
• 横向扩展能力强，应对日300万条消息的写入压力完全没问题，且团队学习成本低于Cassandra。

备选方案 #

• Cassandra：适合超大规模分布式场景，写性能极强，但查询灵活性弱于MongoDB，若你的业务未来会爆发式增长到千万级日活，可考虑作为长期选型。
• Firebase Realtime Database/Firestore：托管式服务，开发速度快，但存在厂商锁定风险，且自定义优化空间有限，适合快速原型验证，不适合大规模自建应用。

三、第三方方案（go-random-chat）建议 #

• 单人维护的项目存在较高的后续维护风险（bug修复、功能迭代无保障），不建议直接上线使用。
• 可参考其架构思路（如WebSocket连接管理、消息路由逻辑），提取核心模块进行二次开发，既节省时间又避免依赖风险。

四、核心架构简化思路 #

1. 通信层：用Gorilla WebSocket搭建服务端，维护用户ID与连接的映射（用sync.Map保证并发安全），消息直接通过连接推送给目标用户。
2. 持久化：异步将消息写入MongoDB，避免阻塞实时推送流程。
3. 可靠性优化：若需防止服务重启丢失未持久化的消息，可引入轻量消息队列（如Redis Pub/Sub）做暂存，落地后再删除。

内容的提问来源于stack exchange，提问作者Big_Boulard